What is Delegated Access for AI Agents?

Definition

Delegated access for AI agents is the pattern where an AI agent acts on behalf of a user (or another agent), inheriting some subset of that principal's authority for a specific purpose.

It is the foundation for agents like:

• "Schedule my meetings" — agent acts on user's calendar.
• "Process my expense reports" — agent acts on user's expense data.
• "Search across my documents" — agent acts on user's document library.

When properly bounded, delegation is safe and useful. When unbounded, it grants the agent the user's full power, creating an enormous insider threat surface.

In simple terms:

Delegated access lets an agent act 'as you' — but only for the things you've authorized, only for the duration you've authorized, and only with the scope you've granted.

---

Why It Matters

• Most useful agentic AI use cases involve acting on user data and on user behalf.
• The boundary between user and agent must be cryptographically and architecturally enforced — not just programmatically intended.
• Misconfigured delegation = the agent inherits every user permission → ambient authority disaster waiting for a prompt injection.

---

Delegation Models

1. OAuth 2.0 On-Behalf-Of (OBO)

• User signs in to a frontend or app.
• Frontend requests a token on behalf of the user with specific scopes.
• Agent receives the OBO token and uses it for downstream API calls.
• Audit shows: action by agent on behalf of user.

2. OAuth Scoped Refresh Tokens

• User grants the agent specific scopes (e.g., Calendars.ReadWrite on a particular calendar).
• Agent stores refresh token; obtains access tokens as needed.
• Useful for long-running agents.

3. Service-Account-with-Delegation (Domain-Wide)

• Agent uses a service account with domain-wide delegation (Google Workspace) or app-only with broad permissions.
• Acts as any user. Very powerful; very risky.
• Should be tightly governed; rarely used for routine agent operations.

4. Just-in-Time User Token

• User initiates an agent task; agent receives a short-lived token bound to the user, the action, and the resources.
• Token expires after task complete.

5. SAML Assertion / Claims-Based Delegation

• SAML assertion includes actAs or onBehalfOf claims.
• Downstream service trusts the chain.

---

Bounding Delegation

Scope-Based Bounding

OAuth scopes restrict what the OBO token can do:

• Calendars.Read (not write).
• Files.Read.SharePoint:Site:Finance (not all sites).
• Mail.Send:Folder:Drafts (not anywhere).

Resource-Based Bounding

Token bound to specific resources:

• "This token authorizes access to bucket customer-12345-data only."
• "This token can call /api/orders/12345 only."

Time-Based Bounding

• Short-lived (minutes); bounded to task duration.

Action-Based Bounding

• Token authorizes specific actions only.
• HITL required for actions outside the bound.

Risk-Based Bounding

• Bound to low-risk sessions; higher-risk requires re-authentication / re-authorization.

---

Common Risks

1. Ambient Authority

Agent inherits all user permissions because no scoping was applied. A prompt-injected agent has everything the user has.

2. Domain-Wide Delegation Misuse

Service account with domain-wide delegation acts as any user; one prompt injection = enterprise-wide access.

3. Refresh Token Storage Vulnerability

Refresh tokens stored insecurely; leak grants long-term agent-as-user access.

4. Confused Deputy

User triggers agent; attacker manipulates agent into using the user's authority for unintended actions.

5. Audit Blur

Actions logged as the user — was it the user or the agent?

6. Cross-Tenant Bleed

Multi-tenant agent's delegation leaks across tenants.

---

Real-World Examples

1. Calendar Agent Bounded

A calendar agent bounded to Calendars.ReadWrite on the user's primary calendar only. Even prompt injection couldn't access mail, files, or other calendars.

2. Domain-Wide Delegation Disaster

A team built a Workspace agent using domain-wide delegation for "convenience." A prompt injection in a document caused the agent to enumerate every user's docs. Mitigation: switched to per-user OBO with bounded scopes.

3. SharePoint Agent Risk Reduction

Agent originally had Files.ReadWrite.All (every site). Bounded to specific finance sites with resource-specific scopes. Effective access dropped 90%; risk significantly contained.

4. JIT Token for Long Tasks

A research agent for the user got a 1-hour JIT token per task; refresh required user re-confirmation. Agent couldn't operate beyond task boundaries.

5. Refresh Token Leak

A storage misconfiguration exposed refresh tokens for hundreds of users. Adversary could act as them via the agent. Lesson: secret manager + rotation + leaked-credential monitoring + scope minimization.

---

Best Practices

1. Use OBO with explicit scopes — not broad / "all" scopes.
2. Resource-bound tokens where possible.
3. Time-bound (short-lived).
4. Avoid domain-wide delegation unless absolutely necessary; if used, govern tightly.
5. HITL for sensitive delegated actions.
6. Refresh tokens stored in secret manager, encrypted at rest, with rotation.
7. Audit attribution — preserve user + agent + action in logs.
8. Per-tenant isolation — multi-tenant agents have per-tenant delegation.
9. Revocation tested — user can revoke agent access easily.
10. Quarterly review of delegation patterns.

---

Checklist

• OBO used with bounded scopes?
• Resource-bound where possible?
• Short-lived tokens?
• Domain-wide delegation avoided / tightly governed?
• HITL on sensitive delegated actions?
• Refresh tokens in secret manager + rotated?
• Audit chain preserved?
• Per-tenant isolation in multi-tenant agents?
• Revocation tested?
• Quarterly review?

---

How Forestall Helps

Forestall maps delegation across your environment:

• OBO grants per agent.
• Domain-wide delegation usage.
• Refresh token storage patterns.
• Cross-tenant delegation risk.
• Recommendations to bound and rotate.

---

Frequently Asked Questions

What's the difference between OBO and app-only?

OBO: agent acts on behalf of a user. App-only: agent acts as itself with its own permissions. Both have valid use cases; OBO when user context matters.

Can OAuth scopes be granular enough?

For most providers, yes — combine with resource-binding where supported. Some legacy APIs lack granularity; bound at network / API gateway level.

Is domain-wide delegation ever OK?

For limited, governed scenarios (org-wide compliance, archival agents). Not for routine agent operations.

How do I revoke delegation quickly?

Revoke OAuth grants from IdP; rotate refresh tokens; notify user; document playbook.

What about consent fatigue (constant re-prompts)?

Balance UX and security — bound but long-enough scopes; use refresh tokens; HITL only for sensitive actions, not every call.

---

Conclusion

Delegated access is essential to useful agentic AI — and the easiest place to create catastrophic risk. Use OBO with bounded scopes, avoid domain-wide delegation where possible, store refresh tokens safely, preserve audit attribution, isolate per tenant, and review quarterly. Done well, agents act faithfully and safely on user behalf. Done poorly, agents become the worst-case insider threat — fast, smart, and fully empowered.