TL;DR
Authenticating an AI agent isn’t the same as authenticating a user. Three rules:
- Issue per-agent service accounts with scoped, short-lived (≤ 1 hour) tokens.
- Add
agent_idandcorrelation_idheaders on every outbound request so logs are auditable. - Require human-in-the-loop authorization for any destructive or high-cost action — the agent’s token alone should never be enough.
Why user auth doesn’t work for agents
When you give an agent a user’s OAuth token, two things go wrong:
- The agent gains every permission the user has — including ones the workflow doesn’t need.
- Audit logs say the user did it, even when the agent took the action.
Both are GDPR / SOC 2 problems waiting to happen. The fix is per-agent identity.
Pattern 1: service account per agent
Create one service-account credential per agent role (not per agent instance). The credential is stored in your secret manager. At cold start, the agent exchanges that credential for a short-lived access token.
Token lifetime: 15–60 minutes. The shorter the better. Refresh in the background; don’t let the agent loop on a long-lived token.
Pattern 2: scoped tokens
The token’s scope should be the smallest set of resources the agent needs to do its job. A support-triage agent only needs read on tickets and write on tags — not full ticket admin.
For OAuth providers, this maps to scopes; for your own APIs, this maps to RBAC roles.
Pattern 3: agent_id and correlation_id
Every outbound request must include:
X-Agent-Id— which agent role made the callX-Agent-Instance-Id— which running invocationX-Correlation-Id— propagate from the user’s original request, end-to-end
Without these headers, audit logs are useless when something goes wrong. With them, you can replay any incident.
Pattern 4: human-in-the-loop for destructive actions
For any action that:
- Spends > $X
- Sends an email outside the org
- Modifies > N records
- Triggers a payment
…the agent’s token alone is insufficient. Issue an approval request to a human (Slack DM, in-app, email), and only execute on explicit confirmation. Yes, this slows the agent down. It also keeps it out of the news.
Common mistake: storing the user’s session token in the agent’s memory
The agent serializes its memory to disk between turns. If you put the user’s session token in memory, it’s now persisted somewhere and probably backed up. Don’t. The agent’s token (its own scoped service-account token) is the only credential that should ever live in agent memory.