fix(invoke): add bearer-token support to the A2A invoke path for CUSTOM_JWT (#815)

[aidandaly24]

Description

#815 — A2A invoke does not support CUSTOM_JWT authentication

An A2A-protocol agent configured with CUSTOM_JWT authorization cannot be invoked. The CLI auto-fetches a bearer token but silently drops it on the A2A path, falling back to SigV4, so every invoke fails with a confusing "Authorization method mismatch" service error. There is no workaround other than a code change, and no add-time warning. Affects CLI invoke, the TUI, and the dev web-UI.

Fix

Add bearer-token support to the A2A invoke path, mirroring HTTP. (1) Add bearerToken?: string; to A2AInvokeOptions (agentcore.ts:926-934). (2) In invokeA2ARuntime (agentcore.ts:942), when options.bearerToken is set, send a raw HTTP POST of the JSON-RPC body with Authorization: Bearer via buildInvokeUrl/buildBearerInvokeHeaders (agentcore.ts:201-233) instead of the SigV4 createAgentCoreClient + InvokeAgentRuntimeCommand, then parse the response through the existing parseA2AResponse. A2A uses the same InvokeAgentRuntime data plane and /runtimes/{arn}/invocations endpoint as HTTP, which already supports bearer auth, so this is sound. (3) Pass the token at the three call sites: bearerToken: options.bearerToken at action.ts:592-601, bearerToken: bearerToken || undefined at useInvokeFlow.ts:782-792, and thread bearerToken through DeployedInvokeParams to the A2A dispatch and handler at invocations.ts:456-463 / 552-560. Minimal-effort fallback only if the service truly rejects CUSTOM_JWT for A2A: add a fail-loud guard at the top of invokeA2ARuntime like AGUI's (agentcore.ts:1080-1082), or reject A2A+CUSTOM_JWT in validate.ts:319-335 — but the full fix is preferred.

This fix was produced by an automated triage+fix run and validated locally (build + unit suite + symptom reproduction). It is being opened as a draft for CI and human review.

Related Issue

Closes #815

Documentation PR

N/A — bug fix; no devguide change required.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots — N/A, no src/assets/ changes

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Package Tarball

aws-agentcore-0.21.0.tgz

How to install

gh release download pr-1647-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.21.0.tgz

[agentcore-devx-automation]

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

[agentcore-devx-automation]

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

[agentcore-cli-automation]

Looks good to merge.

The fix mirrors the existing invokeWithBearerTokenStreaming pattern correctly:

• buildInvokeUrl + buildBearerInvokeHeaders are reused — no logic duplication.
• The bearer branch is gated on options.bearerToken and the SigV4 path is left untouched as a fallback.
• All three call sites (action.ts, invocations.ts, useInvokeFlow.ts) are updated, and resolveInvokeTarget already auto-fetches the token upstream for the CLI/TUI paths, so existing CUSTOM_JWT users get the fix transparently.

Tests are appropriately scoped — mocking only at the true I/O boundaries (@aws-sdk/client-bedrock-agentcore and globalThis.fetch) and asserting both the bearer path and the SigV4 fallback. No excessive mocking.

No new telemetry is needed since InvokeAttrs already captures auth_type (src/cli/telemetry/schemas/command-run.ts:138).

[agentcore-devx-automation]

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

[agentcore-cli-automation]

Looks good to merge.

The fix is correct and minimal:

• The bearer branch is properly gated on options.bearerToken in invokeA2ARuntime (agentcore.ts:960-977) and the SigV4 path is left intact as the fallback. The bearer code reuses buildInvokeUrl and buildBearerInvokeHeaders, mirroring invokeWithBearerTokenStreaming and mcpRpcCallWithBearer — this also resolves the TODO at agentcore.ts:708.
• All three A2A call sites are threaded: action.ts:596, useInvokeFlow.ts:786, and invocations.ts:463/559 (via the new bearerToken field on DeployedInvokeParams). resolveInvokeTarget auto-fetches the token for CUSTOM_JWT agents upstream, so existing users get the fix transparently.
• Response handling stays symmetric with the SigV4 path: a single res.text() fed through parseA2AResponse and wrapped in singleValueStream. The bearer path additionally surfaces the runtime session id from the response headers, which is a small bonus.
• Tests mock only at true I/O boundaries (the @aws-sdk/client-bedrock-agentcore SDK client and globalThis.fetch) and assert both the bearer path (Authorization header, JSON-RPC body shape, no SDK call) and the SigV4 fallback (no fetch call, SDK invoked). No excessive mocking, and the pattern matches agentcore-mcp-bearer.test.ts.
• No new telemetry is needed: InvokeAttrs.auth_type (command-run.ts:138) is already derived from options.bearerToken in buildInvokeAttrs (invoke/utils.ts:29), so the A2A+JWT path will be reported as bearer_token automatically.