Deep Dive: Enterprise Security with OBO Tokens & AI Agents

Why On-Behalf-Of (OBO) Tokens are Critical for Enterprise AI Agents

The Scenario: Sally & Steve

The Characters:

• Sally (The Traveler): She just returned from a business trip and needs to submit her expenses. She has the basic expenses.submit scope.
• Steve (The Manager): He is Sally's leader. He needs to review and approve expenses. He has the elevated expenses.approve scope.
• Traveler Assistant (The AI Agent): A helpful bot inside the company chat app.

Step-by-Step Security Flow

1. Authentication & Minting the User Token

When Sally logs into the Traveler App chat interface, the Identity Provider (like Okta or Google) verifies who she is. It issues a standard User Access Token.
Token Claims: { User: "Sally", Scopes: ["expenses.submit", "expenses.read_own"] }

Use Case: Why Not Just Use Sally's Token?

You might think, "Sally already has a token, why not just give that to the Agent?" This is a major security risk.

If We gave this raw token to the AI Agent:

• The AI Agent (and the LLM provider) would theoretically have access to all of Sally's data, not just expenses.
• If the Agent was compromised, the attacker could read Sally's emails.

The Best Practice: We follow the Principle of Least Privilege. We never share the raw user token. We exchange it for a narrow OBO token that can only do one thing: talk to the Expense Service.

2. The Handshake: Token Broker & OBO Exchange

Sally types her request to the AI Agent. The application doesn't just pass her raw User Token to the bot. instead, it calls the Token Broker.

The Token Broker performs a secure exchange: "Here is Sally's User Token. Please give me an OBO Token specifically for the Expense Service."
The resulting OBO Token is narrower. It is only valid for the Expense Service and only for a short time.

3. The AI Agent Acts

The AI Agent receives the request along with this OBO Token. It analyzes the text ("Check status...") and decides it needs to call a tool.

4. MCP Scope Validation (The Gatekeeper)

This is where the Model Context Protocol (MCP) shines. The AI Agent connects to the "Expense MCP Server."

Before running any function, the MCP Server inspects the OBO Token:

• Check 1: Does this token belong to a valid user? (Yes, Sally).
• Check 2: Does this token have the scope to read all expenses? (No).
• Check 3: Does this token have the scope to read own expenses? (Yes, expenses.read_own).

The MCP Server executes the function get_expense_status(user="Sally") and returns the result. Usefully, if Sally tried to ask "Approve my own expense," the MCP Server would see she lacks the expenses.approve scope and block the action immediately before the tool even runs.

Failure Walkthrough: When the AI Agent Must Say “No”

After successfully checking her expense status, Sally asks the same AI Agent: "Approve my own expense." From the user’s perspective, this feels reasonable.
From a security perspective, this is the most important test of the system. Why This Is a Dangerous Moment At this point, many AI-powered systems may fail to enforce proper security. A naïve implementation might:

• Parse the intent (approve_expense)
• Trust the agent’s identity
• Execute the action

Step-by-Step Failure Path

1. The Agent Interprets the Intent (But Makes No Decision) The AI Agent:

• Detects the intent: approve_expense
• Selects the appropriate MCP tool
• Forwards the request with Sally’s OBO token attached

• User: Sally
• Scopes present:
• expenses.submit
• expenses.read_own
• Scope required:
• expenses.approve ❌

• No database call is made
• No partial execution occurs
• No rollback is required

• expenses.read_own
• expenses.approve ❌

• No database call is made
• No partial execution occurs
• No rollback is required

• No security details are leaked
• No workaround is attempted
• No policy logic exists inside the agent

• Least privilege is enforced
• Authorization is externalized
• The agent is not a security boundary
• Every action remains auditable

What About Steve?

If Steve asks the exact same AI Agent, "Approve Sally's expense," the flow is identical, but his On-Behalf-Of Token contains expenses.approve. The MCP Server sees this scope and allows the approve_expense function to execute.

The simplicity of this architecture: The AI Agent logic doesn't need complex if/else statements for security. It simply passes the On-Behalf-Of (OBO) Token, and the underlying services (via MCP) enforce the rules based on the original user's identity.

In the proposed draft, the access token structure is defined as follows:

The access token should be a JWT (JSON Web Token) that follows the OAuth 2.0 JWT Access Token standard (RFC 9068). This token is used to clearly show who is calling an API and on whose behalf they are acting. The token must include information that explains the delegation chain — meaning:

• Who the end user is
• Which application or service is acting for that user

                iss: The issuer of the token
                sub: The subject of the token
                act: The actor of the token
                azp: The authorized party of the token
                aud: The audience of the token
                exp: The expiration time of the token
                iat: The issued at time of the token
                jti: The unique identifier of the token
                act: The actor of the token
                aut: The authorization type of the token
            

            {
                "iss": "https://authorization-server.com/oauth2/token",
                "aud": "resource_server",
                "sub": "user-456",
                "azp": "s6BhdRkqt3",
                "scope": "read:email write:calendar",
                "exp": 1746009896,
                "iat": 1746006296,
                "jti": "unique-token-id",
                "act": {
                "sub": "actor-finance-v1"
                },
                "aut": "APPLICATION_USER"
            }
            

Key Benefits of On-Behalf-Of (OBO) Tokens

On-Behalf-Of (OBO) tokens are a critical security feature for enterprise AI agents.This is evolving as per the draft. They allow AI agents to act on behalf of users with delegated permissions, creating a clear audit trail and enforcing fine-grained access control. OBO tokens are essential for ensuring that AI agents can securely access resources on behalf of users without compromising security.

Here are the key benefits of using On-Behalf-Of (OBO) tokens in enterprise AI agents:

• Secure Identity Chaining: OBO tokens allow AI agents to act on behalf of users with delegated permissions, creating a clear audit trail and enforcing fine-grained access control. OBO tokens are essential for ensuring that AI agents can securely access resources on behalf of users without compromising security. This is achieved by including the original user's identity in the token and this is propagated through the token chain.
• Enhanced Security & Reduced Risk:
  • Scoped Permissions: Tokens are "downscoped" to only the API/resources the agent needs by generating a new token with the required scopes, limiting potential misuse.
  • Least Privilege: The agent can only do what the user can do (by cross checking the token with the authorization server and comparing the scopes), adhering to the user's existing access rights.
• Strong Auditability & Accountability:
• Clear Audit Trail: Creates a clear, auditable chain of command, proving the agent acted with delegated authority.
• Traceability: Ensures every action is traceable back to the original user, improving security posture.
• Accountability: OBO tokens allow AI agents to act on behalf of users with delegated permissions, creating a clear audit trail and enforcing fine-grained access control. OBO tokens are essential for ensuring that AI agents can securely access resources on behalf of users without compromising security.
• Simplified Compliance:
• Automates tracking of who accessed what and when, making audits and regulatory reviews easier.
• Fine-Grained Access Control:
• Enforces data controls (like those in Databricks Unity Catalog) based on the user's identity, not just the agent's.
• Efficient Permission Management:
• Allows for permission inheritance, reducing consent complexity in multi-agent or multi-instance scenarios.
• Improved Productivity:
• Enables complex workflows without hardcoding security logic into the agent, letting underlying services enforce policies.