A multi-agent expense system must call a line-of-business API that authorizes actions based on the signed-in employee's identity and group memberships. The orchestrator and tools currently use a single long-lived application secret with broad application permissions, so every agent acts with the same superuser power. Which authentication design best aligns with least privilege for user-scoped actions?
Select an answer to reveal the explanation.
Short Explanation
When the API cares who the employee is, you should call it with that employee's delegated token via an OAuth 2.0 on-behalf-of style flow, not a shared superuser app secret. That keeps scopes and group checks real. Stuffing passwords into prompts, publishing keys, or turning off auth are non-starters.
Full Explanation
The correct design is to implement OAuth 2.0 on-behalf-of (or equivalent delegated) flows so tool calls execute with the user's delegated token and scopes, not a shared superuser app secret. Multi-agent security design includes authentication flows such as on-behalf-of, OAuth 2.0, and user impersonation patterns so tools enforce the real user's permissions. Delegated tokens restore least privilege and auditability compared with a single high-privilege application secret used by every agent. Embedding each employee's password in agent instructions for direct basic authentication is incorrect because storing or prompting user passwords in agent instructions is insecure, non-compliant, and incompatible with modern identity platforms. Sharing one API key in a public Git repository README for simplicity is incorrect because publishing API keys in public repositories exposes the system to abuse and still lacks per-user authorization. Disabling API authentication in production to reduce token complexity is incorrect because disabling authentication removes access control entirely and is unacceptable for line-of-business expense actions.