OAuth for AI: Delegation, Scopes, and On-Behalf-Of

The last lesson said a user's permissions should flow through the AI — the AI acting for a person must not exceed what that person could do themselves. This lesson is about the mechanism that makes that true: OAuth, applied to AI. You know OAuth2/OIDC from the identity and API modules; the AI twist is that there is now a non-human component in the middle that needs an identity of its own, and the whole game is making sure it borrows the user's authority narrowly rather than holding its own broad authority permanently.

Two identities the AI can act under

• Service identity (the AI as itself). The AI holds its own credentials and calls downstream systems as "the assistant." Simple, but dangerous when broad: a service token that can read every customer's data means any request routed through the AI can reach any customer's data. This is the standing-privilege trap.
• Delegated identity (the AI on behalf of a user). The AI carries a token that represents this specific user, scoped to what that user may do. Downstream systems see the user's permissions, not the AI's. A request for another user's data fails at the data layer, because the token doesn't carry that right.

The rule of thumb: prefer delegated identity for anything user-facing. Reserve service identity for genuine background jobs, and scope those to the single job. An AI that always acts on behalf of the current user can't be tricked into cross-user access, because it never held cross-user authority to begin with.

On-behalf-of, scopes, and short-lived tokens

• On-behalf-of (OBO) flow. When a user calls the AI and the AI must call a downstream API, OBO exchanges the user's token for a downstream token that still represents the user. The user's identity and permissions propagate through every hop instead of being replaced by the AI's.
• Scoped tokens. A token should grant the narrowest set of scopes the task needs — orders:read:own, not orders:*. Scope is where least privilege becomes concrete and auditable.
• Short-lived + refreshable. Tokens the AI holds should expire quickly. A leaked or injection-abused token that dies in minutes is a far smaller incident than a standing token that works forever.

The confused-deputy connection

Recall the confused deputy from the prompt-injection module: an attacker without authority tricks a system that has authority into misusing it. Standing, broadly-scoped tokens are what make an AI a dangerous deputy. If the AI holds a powerful token all the time, a successful injection borrows that full power. If the AI instead carries only the current user's narrowly-scoped, short-lived token, an injection can only reach what that user could already reach — the deputy has little authority to confuse. Access control and injection defense are the same fight from two sides.

SERVICE TOKEN (AI as itself)      DELEGATED / OBO (AI as the user)
                      ------------------------------    --------------------------------
Represents              the AI application                the specific calling user
Downstream sees         "assistant" — broad rights         the user's own permissions
Cross-user data         reachable (one token, all data)    blocked at the data layer
If injected / leaked     attacker gets the AI's full scope  attacker gets only this user's scope
Right use               genuine background jobs, pinned     anything user-facing
Scope discipline        one narrow job only                 narrowest scopes, short-lived

Tool and MCP authorization

Agentic AI reaches systems through tools (increasingly via MCP, the Model Context Protocol). Each tool is a door, and each door needs its own lock:

• Every tool carries a scoped identity. A tool that reads orders should authenticate with an orders:read:own token tied to the current user — not a shared admin credential the whole agent holds.
• Least privilege per tool, deny by default. The agent's effective authority is the union of its tools' scopes, so keep the set minimal and each scope tight. Don't hand an agent a "do anything" tool because it's convenient.
• High-risk tools gate on a human. Refunds, deletes, external sends: the tool exists, but invoking it requires approval (the action layer from the last module).

The GRC throughline

This is all evidence a GRC engineer can collect: the token model (delegated vs service) for each AI integration, the scope list per tool, token lifetimes, and the OBO configuration showing user identity propagates downstream. "The AI uses appropriate authentication and least-privilege access" stops being a checkbox and becomes a specific, reviewable design. Next you will put it to work: design the access matrix for six personas, deciding exactly which models, data, and actions each one gets.