Credential provider is never deleted, despite remove credential saying the deploy will apply it
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- aws, typescript
Línea de trabajo
Traza las rutas de eliminación de credenciales y de deploy en la TypeScript CLI y compáralas con la llamada existente de eliminación del proveedor de pagos descrita en el issue. Añade cobertura para una credencial de API-key eliminada antes de un deploy y verifica que el proveedor y el secret subyacente se eliminen, en lugar de omitirse simplemente durante la creación posterior; los comandos de reproducción proporcionan la comprobación end-to-end.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
agentcore remove credential --name <n> --yes returns a note saying the removal will be applied to AWS on the next deploy:
{"success":true,"resourceType":"credential","resourceName":"retiretest-fake-token",
"message":"Removed credential 'retiretest-fake-token'",
"note":"Your agent app source code has not been modified. Deploy with `agentcore deploy` to apply your removal changes to AWS."}
That does not happen. The API-key credential provider is never deleted from AWS. It survives the removal, the following deploy, and a full stack teardown. There appears to be no CLI path that deletes one at all, so the only way to remove it is a manual aws bedrock-agentcore-control delete-api-key-credential-provider call.
The misleading note is the reason I am filing this as a bug rather than a feature request. An operator who follows the CLI's own guidance will reasonably believe the credential is gone. It is not, and neither is its backing secret, which is a security-relevant leak whenever the credential holds a real token.
Two details suggest the missing deletion is an oversight rather than a deliberate design decision:
- The CLI does implement provider deletion for payment credential providers, via a direct
POST /identities/DeletePaymentCredentialProvidercall. There is no equivalent call for API-key providers anywhere in the CLI. - The credential provider is not a CloudFormation resource, so
cdk destroycannot remove it even in principle. On a two-runtime Container project the stack contained 24 resources (Runtime, ECR, KMS, Lambda, Logs, IAM, CodeBuild, CustomResource, CDK Metadata) and no credential-provider resource of any type. Only an explicit API call can delete it.
Steps to Reproduce
1. Scaffold a project with one runtime and one API-key credential.
agentcore create --no-agent --project-name RetireTest
agentcore add agent --type byo --name alpha_amp --language TypeScript \
--framework Strands --model-provider Bedrock --code-location app/alpha_amp \
--entrypoint dist/main.js --build Container --protocol HTTP
agentcore add credential --name retiretest-fake-token --type api-key --api-key not-a-real-token
2. Deploy. The output includes a Creating credentials... step.
agentcore deploy --target <target>
3. Confirm the provider now exists in AWS.
aws bedrock-agentcore-control list-api-key-credential-providers --region us-east-1
retiretest-fake-token is present. Correct so far.
4. Remove the credential. Note the message it returns about deploying to apply the change.
agentcore remove credential --name retiretest-fake-token --yes
5. Deploy again, exactly as that message instructs.
agentcore deploy --target <target>
6. Check AWS again.
aws bedrock-agentcore-control list-api-key-credential-providers --region us-east-1
retiretest-fake-token is still present. This is the bug.
7. Optionally, confirm it also survives a full teardown.
agentcore remove agent --name alpha_amp --yes
agentcore deploy --target <target> --yes # output shows a "Tear down stack" step
aws cloudformation describe-stacks --stack-name AgentCore-RetireTest-<target> --region us-east-1
# ValidationError: Stack ... does not exist -- the stack is correctly gone
aws bedrock-agentcore-control list-api-key-credential-providers --region us-east-1
# retiretest-fake-token is STILL present
Expected Behavior
One of the following:
- The deploy after
remove credentialdeletes the credential provider from AWS, as the returned note says it will. Or, remove credentialstates that the AWS-side provider must be deleted separately, and prints the command to do it.
Either way, an operator following the CLI's output should end up with no orphaned provider and no orphaned backing secret.
Actual Behavior
The credential provider is never deleted. It remains in the account after remove credential, after the deploy that the CLI said would apply the removal, and after a full stack teardown that reported success.
The deploy in step 5 does correctly omit the Creating credentials... step that appeared in step 2, so the CLI clearly notices the credential is no longer declared in agentcore.json. It simply has no concept of deleting one that already exists in AWS, while telling the operator the opposite.
Deleting it requires dropping out of the CLI entirely:
aws bedrock-agentcore-control delete-api-key-credential-provider \
--name retiretest-fake-token --region us-east-1
CLI Version
0.27.0
Operating System
macOS
Additional Context
Environment: @aws/agentcore 0.27.0 installed via mise (npm:@aws/agentcore), @aws/agentcore-cdk ^0.1.0-alpha.19, aws-cdk-lib ^2.248.0, aws-cdk CLI 2.1126.0, Node v22.22.1, aws-cli 2.35.24, macOS 15 arm64. Project managedBy: CDK, Container build, single deploy target. No modifications to the CLI or to the generated agentcore/cdk/ sources.
This was found while building tooling to retire AgentCore projects in an internal sandbox, and reproduced on a throwaway project created solely to confirm it. We had previously orphaned a provider on a real retirement without noticing, because the CLI reported success.
A related but separate gap, filed as #2023: a teardown also orphans one Lambda log group per Container runtime, because those log groups carry DeletionPolicy: Retain. cdk diff shows this as orphan, but the CLI's own teardown output never mentions that anything was retained.
For reference, the complete teardown procedure we ended up needing, where steps 3 and 4 have no CLI equivalent:
1. agentcore remove agent --name <each> --yes # local config only
2. agentcore deploy --target <target> --yes # destroys the stack
3. aws bedrock-agentcore-control delete-api-key-credential-provider --name <n> --region <region>
4. aws logs delete-log-group --log-group-name <n> --region <region>
- Lenguaje dominante
- TypeScript
- Estrellas
- 291
- Forks
- 96
- Merge medio
- 20 h 50 min
- PR fusionados (30 d)
- 214
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de aws/agentcore-cli
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
aws/agentcore-cli#2395 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
aws/agentcore-cli#2392 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
aws/agentcore-cli#2267 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
aws/agentcore-cli#2258 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
aws/agentcore-cli#2176 ·
Los mantenedores suelen responder en 1 día
Todos los issues de aws/agentcore-cli
Issues similares
-
module-request
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
ports get and web print 'Port N already in use, trying next...' for every busy port they skipAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
appandflow/stim#1604 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
lingdojo/kana-dojo#31060 · 1 comentario · 5 reacciones ·
Los mantenedores suelen responder en 1 día
-
SSH workspace restore rewrites relative symlinks into the deleted sync-back staging directoryAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
paperclipai/paperclip#14173 ·
Los mantenedores suelen responder en 1 día
-
needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día