How do you design authorization for an agent that acts on behalf of users across systems (email, CRM, drive)?

Principles

1. Identity comes from the session, not the prompt. The tool gateway attaches user_id and tenant; the model can't impersonate another user by writing a different ID.
2. Delegated, least-privilege credentials: per-user OAuth tokens with minimal scopes (gmail.readonly unless sending is needed), stored in a vault, never placed in the model context.
3. Policy engine (e.g. OPA/Cedar-style rules) evaluates who may do what to which resource, plus agent-specific rules: "the agent may draft but not send to external domains."
4. Separate agent identity: record actions as "Agent X on behalf of User Y" for auditing and revocation.
5. Step-up / HITL for high-impact actions: sending externally, deleting, sharing files publicly, payments.
6. Short-lived, revocable tokens, and an emergency kill switch per agent.
7. Data-level controls: the agent sees only documents the user can see (permission-aware retrieval). This is critical for enterprise RAG.
8. Audit: every tool call logged with the trace ID, inputs, outputs and approval.

Common mistakes

• Giving the agent a single service account with admin access "for simplicity." That creates a confused-deputy problem: any user, or any injected text, can make the agent act with admin rights.

Related

• Previous: Q38. Design a "deep research" agent that produces a cited report on any topic.
• Next: Q40. An email-assistant agent was tricked by a malicious email into forwarding confidential documents to an attacker. Explain the attack and design defences.
• Model Context Protocol