In a multi-agent system, Agent A (an orchestrator) needs to invoke Agent B (a specialized executor) via an internal API. A developer proposes that Agent B should accept requests from Agent A by checking a shared API key stored in both agents' environment. A security architect objects. Which authentication approach is more secure for agent-to-agent communication?
Select an answer to reveal the explanation.
Short Explanation
Shared API keys are secrets anyone can copy and reuse forever. A short-lived signed JWT issued by the orchestrator and verified against its public key cannot be forged, expires quickly, and carries claims that explicitly state who is calling whom and why. You should use that approach.
Full Explanation
Short-lived signed JWTs are the recommended approach for agent-to-agent authentication because they combine several security properties simultaneously. The orchestrator generates a JWT signed with its private key, including claims: iss (issuer, identifying the orchestrator), aud (audience, specifying the specialized executor as the intended recipient), exp (expiration, e.g., 5 minutes from now), and optionally a task_id or correlation_id for traceability. The specialized executor holds the orchestrator's public key and validates the JWT's signature, expiry, issuer, and audience before processing the request.
Key security properties: the JWT is short-lived (automatic expiry prevents replay attacks), non-forgeable (only the orchestrator can produce a valid signature with its private key), and self-describing (the claims explicitly state the intended recipient and context).
The shared API key stored in a centralized secrets manager is wrong because the shared API key, even retrieved from a secrets manager, is still a secret that both agents know. If either agent is compromised, the attacker obtains the shared key and can impersonate either agent. The shared key also provides no expiry, no audience binding, and no built-in replay prevention.
The mutual TLS approach is wrong for this scenario because, although mutual TLS provides strong transport-level mutual authentication and encryption, it authenticates the connection rather than the application request itself. It does not carry application-level claims such as issuer, audience, expiry, task context, or correlation context, and it requires certificate distribution, rotation, and revocation. In this exam context, the short-lived signed JWT approach is the most directly correct answer because it gives the specialized executor request-level validation of who is calling, whom the request is for, and when it expires.
Allowing the specialized executor to accept any request from the orchestrator's IP address without additional authentication is wrong because IP address is not a reliable authentication mechanism. IP addresses can be spoofed, shared between multiple services, or change when agents are redeployed to different infrastructure. IP-based trust is not authentication — it is network-level access control at best.