test(e2e): fix harness CUSTOM_JWT auth to validate allowedClients

[aidandaly24]

Description

The harness-custom-jwt E2E test (added in #1609) fails on the full-suite run (shard 2/5) at rejects SigV4 invocation (auth method mismatch).

Root cause — a test fixture bug, surfaced by the main+preview merge (#1598, #1611):

1. The harness was deployed with --allowed-audience <clientId>, so the service validates the token's aud claim.
2. But the test authenticates via Cognito client_credentials (M2M), whose tokens carry a client_id claim and no aud.
3. The fixture also registers a managed OAuth credential (--client-id/--client-secret), so the post-merge auto-fetch path kicks in: a default invoke (no --bearer-token) now auto-fetches a JWT instead of doing SigV4 (canFetchHarnessToken() → true).
4. The service rejects the fetched token with 403 "*** missing required audience claim.", which doesn't match the test's expected client-side customJWTRejectMsgRegex → assertion fails.

The sibling byo-custom-jwt.test.ts passes only because it patches agentcore.json with no credential, so it hits the client-side SigV4 fast-fail the regex expects. The same aud misconfiguration is latent there, hidden by a weak not.toMatch assertion.

Fix (test-only — no shippable CLI behavior changes):

• Deploy the authorizer with --allowed-clients (the claim Cognito M2M tokens actually carry) instead of --allowed-audience.
• Assert AllowedClients in the CFN template check.
• Reframe the invoke tests to the real post-merge behavior: a default invoke auto-fetches a JWT and is accepted (renamed auto-fetches a JWT for a default (non-bearer) invocation), and the bearer-token invoke now asserts exitCode === 0 (a real positive, replacing the weak not.toMatch). Both also assert no missing required audience claim 403, so a future allowedClients regression is caught.

Related Issue

Closes #1623

Documentation PR

N/A — test-only change.

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 (tsc --noEmit — clean)
• I ran npm run lint (eslint + prettier --check — clean)
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Also confirmed vitest list --project e2e collects all 5 cases including the renamed test. The E2E itself runs against real AWS (Cognito deploy) and will execute in CI on this PR.

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.

[agentcore-devx-automation]

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

[github-actions]

Package Tarball

aws-agentcore-0.20.2.tgz

How to install

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

[agentcore-cli-automation]

This is a well-scoped, well-explained test-only fix. The root-cause analysis in the description matches the code: canFetchHarnessToken() returns true when the managed OAuth credential is registered, so a default invoke auto-fetches a JWT — which means the old "rejects SigV4" expectation was no longer valid for this fixture. Switching to --allowed-clients (matching the client_id claim that Cognito M2M tokens actually carry) is the right fix, and asserting exitCode === 0 on the bearer-token path is a meaningful strengthening of the test.

A couple of small observations (not blocking, just noting for awareness):

• The new auto-fetches a JWT for a default (non-bearer) invocation test only asserts negative conditions (not.toMatch) and does not assert exitCode === 0, while its sibling bearer-token test was strengthened to do so. If the auto-fetch path silently regressed (e.g. fell back to SigV4 without producing a recognizable error string), this test could still pass. Consider adding an exitCode === 0 assertion here too for symmetry — but I see why you may have left it off (the test name implies the auto-fetch is exercised, and the fetch access --type harness test below provides a direct positive on token minting).
• As noted in the description, byo-custom-jwt.test.ts carries the same latent allowedAudience misconfiguration hidden behind a weak not.toMatch. Scoping that to a follow-up seems fine.

Nothing here that needs to change before merging.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	37.04%	13553 / 36590
🔵	Statements	36.3%	14409 / 39685
🔵	Functions	31.68%	2326 / 7342
🔵	Branches	30.79%	8923 / 28977

Generated in workflow #3783 for commit c84171e by the Vitest Coverage Report Action