Instead of giving an agent a long-lived API key or OAuth token at startup, issue short-lived credentials per task — valid for the duration of one tool invocation or one session, then automatically revoked.

Bind each credential to a specific user session, a specific tool, and a specific scope. A credential issued to invoke the refund API can only invoke the refund API — not the shipping API, not the admin API — and only during this session.

Revoke immediately on: task completion, session end, anomaly detection, or budget exceeded.

JIT access limits the window of abuse, but within that window, a misuse can still occur. A just-in-time token for the refund API still allows an unauthorized refund if the tool is called with injected parameters during its valid period. JIT is a damage-limitation strategy, not a prevention strategy for intent-based attacks.

Setting up dynamic credential issuance is engineering work. Most teams take the shortcut of giving the agent a long-lived API key in a config file. That key then persists in the agent's environment, in logs, and in any memory system the agent uses — and it remains valid long after the task is complete.

The Amazon Q secrets-via-DNS attack specifically targeted long-lived credentials in the agent's environment. JIT access would have dramatically limited the blast radius.

Any scenario where an attacker exfiltrates credentials for future use. Directly addresses the Amazon Q DNS exfil pattern. Also limits the blast radius of S04 (CRM + Email chain) — a per-session token for the email tool can only be used during this session.