feat: create credential providers before synthesizing a deploy by notgitika · Pull Request #2123 · aws/agentcore-cli

notgitika · 2026-08-27T00:23:31Z

Creates a project's credential providers before synthesis, so the synthesized CDK app can read their ARNs out of deployed-state.json and wire them into the stack. Without this, deploying a project that declares any credential fails inside cdk synth.

What it does

Between the account preflight and synth, CdkBackend.deploy provisions each declared credential provider: reuse-if-present, create-if-absent, never update (so a redeploy neither mints a new secret version nor overwrites one rotated outside the CLI), then records the ARNs via updateTargetState.
Secrets come from the same place project add credentials writes them — .env.local (AGENTCORE_CREDENTIAL_<NAME>) or a Secrets Manager secretRef. The env-var name is now derived from one shared function in envLocal.ts so add and deploy agree.
Payment credentials are rejected up front (agentcore.json can't express their vendor config).

Note

Pre-synth by necessity: the vended app reads the ARNs at synth time.

Tested e2e

Ran the full flow against a real account (us-west-2): project add credentials api-key → project deploy. Confirmed deploy creates the API-key credential provider imperatively before synth, writes it to agentcore/.cli/deployed-state.json, then deploys the stack and merges the stackArn into the same target entry (no clobbering). Resulting file held both resources.credentials.e2ekey and stackArn.

agentcore-devx-automation

AgentCore Harness Review

Verdict: Looks good

Nice PR. The design of running credential provisioning before cdk synth and threading the ARNs through deployed-state.json is well-motivated and the comments do a great job of capturing why. The seam boundary (IdentityProviderClient) is drawn at the SDK client rather than at fs/process boundaries, so the tests avoid excessive mocking while still exercising the real spec + .env.local parsing paths. Sharing credentialEnvVarName/CLIENT_SECRET_SUFFIX between add and deploy via envLocal.ts (with a re-export from shared.ts) removes a latent format-drift bug.

A couple of small things that aren't blockers but worth confirming intentional:

Stale credential entries when the spec goes to zero credentials. In src/core/project/backends/cdk.ts (~L115) updateTargetState is only called when Object.keys(provisioned).length > 0. If a user deletes their last credential from agentcore.json and re-deploys, provisioned is {}, the state write is skipped, and the previous resources.credentials map is left on disk. The doc-comment on updateTargetState promises "A resource map provided in the patch replaces the previous map for that kind wholesale, so a credential dropped from the spec stops being advertised" — that guarantee is only actually delivered when at least one credential remains. Since the synthesized CDK app looks up credentials by name, this is likely inert in practice, but if you want the drop-to-zero case to behave the same as drop-one-of-many, you'd either always call updateTargetState({ resources: { credentials: provisioned } }) or explicitly write {} when declared is non-empty on the spec side but you provisioned nothing.
parseEnv cast in EnvLocalFile.read (src/core/project/envLocal.ts L90): parseEnv's declared return type is Record<string, string | undefined> (last-write-wins across duplicate keys), but you cast to Record<string, string>. All callers happen to use if (!value) so undefined is handled safely today; just be aware the type is a small lie and a future caller doing env[k].trim() would compile but crash.

Neither of these needs to block the merge.

The synthesized CDK app reads credential provider ARNs out of deployed-state.json and fails to synth a project that declares credentials until they exist. Provision them between the account preflight and the build, then record their ARNs via updateTargetState so the assembly is synthesized against a state file that already describes them. Providers are created when absent and reused when present, never updated, so a redeploy neither mints a new secret version nor overwrites one rotated outside the CLI. Payment credentials are rejected up front (agentcore.json can't express the vendor config they need). Secrets come from the same place 'project add credentials' writes them, so the env-var name is now derived from one function in envLocal.ts that both sides share.

codecov-commenter · 2026-08-27T16:32:07Z

Codecov Report

❌ Patch coverage is 98.09886% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.38%. Comparing base (794ddbf) to head (903abbc).
⚠️ Report is 8 commits behind head on refactor.

Files with missing lines	Patch %	Lines
src/core/project/backends/cdk/credentials.ts	97.70%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           refactor    #2123    +/-   ##
==========================================
  Coverage     97.37%   97.38%            
==========================================
  Files           455      456     +1     
  Lines         27741    27991   +250     
==========================================
+ Hits          27014    27259   +245     
- Misses          727      732     +5

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

agentcore-devx-automation · 2026-08-27T16:32:16Z

Claude Security Review: no high-confidence findings. (run)

…v type - Add SDK-mocked coverage for createIdentityProviderClient (the real Identity factory the provisioner tests bypass): ~55% -> ~95% on credentials.ts. - Always record the provisioned credential set, so removing the last credential from the spec clears the stale entry instead of leaving it advertised. - EnvLocalFile.read returns Record<string, string | undefined> (parseEnv's real type) rather than casting it away. - Tighten a few verbose comments.

agentcore-devx-automation · 2026-08-27T16:53:37Z

Claude Security Review: no high-confidence findings. (run)

agentcore-devx-automation · 2026-08-27T17:00:14Z

Claude Security Review: no high-confidence findings. (run)

agentcore-devx-automation · 2026-08-27T19:06:16Z

Claude Security Review: no high-confidence findings. (run)

aidandaly24

Mostly looks good to me just a few comments

aidandaly24 · 2026-08-27T19:25:40Z

        : [
            {
-              key: credentialEnvVarName(flags.name, "_CLIENT_SECRET"),
+              key: credentialEnvVarName(flags.name, CLIENT_SECRET_SUFFIX),


I think collision detection needs to compare the final per-type environment keys, including this suffix. I added an API key named foo_client_secret and OAuth credential named foo. Both additions succeeded, and provisioning sent the API-key value as both the API key and OAuth clientSecret because both resolve to AGENTCORE_CREDENTIAL_FOO_CLIENT_SECRET. Could the shared validation derive the actual secret key for each credential type and reject collisions before writing or touching AWS?

good catch. I'll make the collision check derive each credential's actual secret key by type (api-key -> base, oauth -> base + _CLIENT_SECRET) and reject on the final key, before writing or touching AWS

aidandaly24 · 2026-08-27T19:27:34Z


+    // Credential providers aren't stack resources; the synthesized app reads their
+    // ARNs from deployed-state.json, so they must exist and be recorded before synth.
+    const provisioned = yield* this.provisionCredentials(project, {


Could the local CDK prerequisite checks stay ahead of credential provisioning? I ran this with agentcore/cdk/node_modules missing: the provisioner ran and deployed-state.json was written, then deploy failed with the npm install guidance. Synthesis still has to happen after provisioning, but checking npm and dependencies separately first would avoid mutating AWS for a local setup error. Probably just good to have like for ux but not a blocker.

Agreed, a local setup error shouldn't mutate AWS. I'll hoist the npm/node_modules prerequisite check ahead of credential provisioning so we fail fast before creating anything. Synth still runs after provisioning, but the local-only checks don't need to.

aidandaly24 · 2026-08-27T19:32:48Z

+      // Provider names are account-global, so a name already taken by another
+      // project in this account is adopted rather than recreated.
+      yield { message: `Preparing credential provider '${credential.name}'` };
+      provisioned[credential.name] = await provisionOne(client, credential, env, project.rootPath);


I think this can leave partial AWS state when provisioning fails midway.

For example:

The first credential provider is created successfully.

Creating the second provider fails.

provisionCredentials() throws, so updateTargetState() is never reached.

The first provider now exists in AWS but is not recorded locally. Retrying with the same spec recovers it, but abandoning the deploy or removing that credential leaves the provider orphaned.

Could we validate all credential inputs before creating anything and roll back providers created by this invocation if a later creation fails?

right, there's an orphan window. I'll validate all credential inputs up front (resolve every .env.local/secretRef before creating anything), which removes the most likely mid-loop failure before any AWS call. It's also self-healing on retry via reuse-by-name. I'm inclined to skip automatic rollback of already-created providers for now (extra delete calls + failure modes for an edge case retry already recovers), let me know if you'd rather I add it.

aidandaly24 · 2026-08-27T19:38:18Z

+ * keeps provider configs secret-free, so the one vendor key it carries is the
+ * only place the secret can go.
+ */
+function vendorConfigWithSecret(


I really like the breakdown of functionality in this file.

tejaskash · 2026-08-27T19:41:10Z

+        new CreateApiKeyCredentialProviderCommand({
+          name,
+          ...(apiKey !== undefined && { apiKey }),
+          ...(secretRef && { apiKeySecretConfig: secretRef, apiKeySecretSource: "EXTERNAL" }),


When this points to an external secret, the generated Gateway role cannot actually read it. We save the returned ARN as clientSecretArn, but @aws/agentcore-cdk 0.1.0-alpha.45 only uses that ARN for OAuth targets. Its API-key path grants secretsmanager:GetSecretValue only for the managed bedrock-agentcore-identity!* secrets. That means a Gateway target using an API-key credential with secretRef can deploy successfully and then fail when it tries to retrieve the key. Could we grant the recorded external ARN for API-key targets as well, either here or by updating the pinned construct?

I think the change is on the refactor branch tho right @notgitika ?

I checked the l3 cdk constructs repo, it's not fixed on its refactor branch either. Gateway.ts there (same as main/alpha.45) grants the recorded external secret ARN for OAuth targets, but the API-key path grants GetSecretValue only on bedrock-agentcore-identity!* — so an API-key secretRef isn't covered.

That's a construct fix (broaden the api-key Gateway grant to include the recorded external ARN, like the OAuth path), not something the CLI can do, it already records the ARN.

Also worth noting the credential-provider CDK construct on that refactor branch is the "credentials via CDK" approach we're not going ahead with. I can file a follow-up on agentcore-l3-cdk-constructs and keep it out of scope for this PR

…ovisioning - Collision detection now compares each credential's actual per-type .env.local variable (API key uses the base name, OAuth appends _CLIENT_SECRET), so cross-type clashes like api-key 'foo_client_secret' vs oauth 'foo' are rejected before writing the spec. - Check local CDK prerequisites (npm + node_modules) before provisioning credentials, so a local setup error no longer mutates AWS. - Resolve every credential (look up existing, validate the secret) before creating any, so a missing secret fails before the first provider is created rather than leaving a half-provisioned state.

agentcore-devx-automation · 2026-08-27T21:16:01Z

Claude Security Review: no high-confidence findings. (run)

… lint - Keep the 'same environment variable' wording so the existing add-credentials collision test still asserts it, and add an integration test for the cross-type case (oauth 'foo' vs api-key 'foo_client_secret'). - Silence require-yield on a deploy-prereq spy generator that never runs.

agentcore-devx-automation · 2026-08-27T21:35:11Z

Claude Security Review: no high-confidence findings. (run)

aidandaly24 · 2026-08-28T02:02:17Z

+  return {
+    customOauth2ProviderConfig: {
+      oauthDiscovery: { discoveryUrl: credential.discoveryUrl },
+      ...(credential.clientId !== undefined && { clientId: credential.clientId }),


I think older OAuth projects need a compatibility fallback here. v0.28.0 stored the client ID only in AGENTCORE_CREDENTIAL_<NAME>_CLIENT_ID, not in agentcore.json. If the provider needs to be recreated in another target/account or after deletion, this sends the discovery URL and secret without the client ID. Would it make sense to prefer credential.clientId and fall back to the legacy environment variable, with an upgrade test?

notgitika had a problem deploying to e2e-testing August 27, 2026 00:23 — with GitHub Actions Failure

github-actions Bot added the size/l PR size: L label Aug 27, 2026

agentcore-devx-automation Bot added the agentcore-harness-reviewing AgentCore Harness review in progress label Aug 27, 2026

agentcore-devx-automation Bot reviewed Aug 27, 2026

View reviewed changes

agentcore-devx-automation Bot removed the agentcore-harness-reviewing AgentCore Harness review in progress label Aug 27, 2026

notgitika force-pushed the feat/deploy-credential-providers branch from 4b787a8 to 0db4266 Compare August 27, 2026 15:43

github-actions Bot added size/l PR size: L and removed size/l PR size: L labels Aug 27, 2026

notgitika had a problem deploying to e2e-testing August 27, 2026 15:44 — with GitHub Actions Failure

Base automatically changed from feat/deployed-state-top-level to refactor August 27, 2026 16:15

github-actions Bot added size/xl PR size: XL and removed size/l PR size: L labels Aug 27, 2026

notgitika force-pushed the feat/deploy-credential-providers branch from 0db4266 to 3c09c23 Compare August 27, 2026 16:28

github-actions Bot added size/l PR size: L and removed size/xl PR size: XL size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

notgitika marked this pull request as ready for review August 27, 2026 16:38

github-actions Bot added size/l PR size: L and removed size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

github-actions Bot added size/l PR size: L and removed size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

github-actions Bot added size/l PR size: L and removed size/l PR size: L labels Aug 27, 2026

fix: use a valid Oauth2ProviderConfigInput in the no-secret-ARN test

0e76e9f

github-actions Bot added size/l PR size: L and removed size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

aidandaly24 requested changes Aug 27, 2026

View reviewed changes

tejaskash reviewed Aug 27, 2026

View reviewed changes

github-actions Bot added size/xl PR size: XL and removed size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

github-actions Bot added size/xl PR size: XL and removed size/xl PR size: XL labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

notgitika requested review from aidandaly24 and tejaskash August 27, 2026 21:35

aidandaly24 reviewed Aug 28, 2026

View reviewed changes

Uh oh!

Conversation

notgitika commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What it does

Note

Tested e2e

Uh oh!

agentcore-devx-automation Bot left a comment

Choose a reason for hiding this comment

AgentCore Harness Review

Uh oh!

codecov-commenter commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

aidandaly24 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

notgitika commented Aug 27, 2026 •

edited

Loading

codecov-commenter commented Aug 27, 2026 •

edited

Loading