Skip to content

PATTERN Cited by 6 sources

On-behalf-of (OBO) agent authorization

Pattern

When an AI agent makes a tool call on behalf of an authenticated human user (or a calling service), the tool-invocation boundary (typically an MCP server) forwards the call carrying the caller's identity and scoped consent — not a shared agent-service token. The downstream data system then enforces its normal per-user authorization policy against the carried identity, as if the user had made the call directly.

Key properties:

  1. Agents do not hold bulk credentials. Every tool call is authorized by the upstream caller's identity, resolved through the enterprise's IdP (Identity Provider).
  2. Authorization is per-call, not per-session. Even inside a single agent task, tool calls that touch different data sensitivities can carry different scoped tokens.
  3. Audit trails are keyed on the human. "What did user X's agent do on their behalf?" is a well-defined query because every action is traceable to the caller, not to a shared agent-service account.

Canonical statement on the wiki

Alex Gallego's 2025-10-28 Redpanda Agentic Data Plane launch names OBO as the first shipped ADP governance feature (Source: Gallego 2025-10-28):

"Remote MCP + authentication + authorization for OBO (on-behalf- of) workloads with IdP integration."

Gallego's structural foil (the failure mode OBO is pitched against) verbatim:

"the new digital workforce often interacts with systems created in the API era of root-token permissions, with all-or-nothing as the norm."

The failure mode OBO fixes

Enterprise-integration patterns from the pre-agent era:

  • One service-account token per integration. The integration (e.g. an agent tool) holds a long-lived credential scoped to the full set of operations any user might ever need.
  • Audit trail keyed on service account. The downstream system logs "service-account X accessed record Y", which is useless for per-user accountability.
  • Broad scopes. Since the same token serves every user's request, its scope is the union of every user's maximum entitlement.

In the agent era this fails structurally:

  • An agent instance with a root-token credential is a per- task blast radius — compromised prompt injection can exercise the full scope.
  • Per-user entitlement cannot be enforced at the data system because the data system sees a single shared identity.
  • GDPR / HIPAA / SOX audit requirements keyed on individual user actions are unsatisfiable.

Architectural shape

  Human user
  (authenticated via IdP)
    |
    v
  [ Agent task ]
    |         (plan + tool calls)
    v
  [ MCP server / tool gateway ]  <- OBO boundary
    |         (forwards call with caller's identity
    |          + scoped consent token, not agent token)
    v
  Downstream data system
  (enforces per-user policy
   against carried identity)

The MCP server is the OBO proxy — it has an identity itself (to authenticate to the downstream system), but each call it forwards carries the original caller's identity as the authorization principal. The downstream system trusts the MCP server's channel authentication but applies the caller's entitlements, via a token-exchange flow with the IdP or via JWT passthrough with downstream validation.

  • patterns/mcp-as-centralized-integration-proxy — the generalisation of the enforcement point. MCP-as-proxy is the deployment shape; OBO is the identity semantics it carries.
  • patterns/central-proxy-choke-point — the structural stance (single enforcement point) that OBO depends on.
  • layered-jwt-plus-mesh-auth — the underlying authentication substrate that typically carries OBO claims (JWT with actor claims / token-exchange RFC 8693 semantics + mesh mTLS for channel identity).
  • per-tool-authorization-decorator — Pinterest's 2026-03-19 canonicalisation of per-tool policy enforcement inside the MCP server; composes naturally with OBO (the decorator evaluates policy against the OBO-carried identity).
  • patterns/business-group-authorization-gating — group-level entitlement check that layers over OBO at the group altitude ("this user's group is allowed to use this tool").
  • machine-to-machine-authz — the service- identity substrate beneath OBO's actor side (the MCP server itself needs an m2m credential to reach the downstream system).

Task-based authentication extension

Gallego's ADP roadmap names "OBO to task-based authentication" as the governance extension: the identity attached to a tool call is scoped not just to the user but to the specific agent task the user authorized. Reduces blast radius from "any-action-this-user-can-do" to "the specific workflow this user explicitly consented to".

Structurally this is a consent-workflow overlay on OBO:

  1. User initiates agent task T with scope S.
  2. Token exchange issues a task-bound token T#S signed for this task only.
  3. Every tool call in task T carries T#S.
  4. Downstream enforcement validates both the user identity and that the task token matches the requested operation's scope.

Known limitations

  • Token-exchange cost. Every tool call may require a token-exchange round-trip to the IdP unless caching is layered in. For long-running agent tasks with many tool calls this is material latency.
  • Downstream-system support required. OBO only works if the downstream data system either accepts delegated tokens (PostgreSQL row-level security + JWT, AWS STS AssumeRole with session tags, Snowflake secondary-role, Databricks Unity Catalog per-user entitlements) or is proxied by an OBO-aware gateway. Legacy APIs with no per-user identity model can't benefit from OBO without a gateway refactor.
  • Prompt-injection does not bypass OBO but can abuse it. OBO prevents credential-theft failures (the agent can't leak a root token). It doesn't prevent entitlement-abuse failures (a compromised agent operating as the legitimate user exercises the user's legitimate entitlements maliciously). Guardrails at the tool-call altitude are an orthogonal axis.
  • Consent workflow UX. Task-based authentication requires users to grant scoped consent at task-initiation time. Over-granting consent to avoid friction defeats the purpose; under-granting causes task failure mid-workflow. The product UX is non-trivial and the ADP post doesn't disclose its shape.
  • Not disclosed at mechanism altitude in the ADP post. Gallego names OBO as a shipping feature but doesn't disclose the token format (JWT? opaque?), the token-exchange flow (RFC 8693? SAML assertion? IdP-native?), the consent-capture UX, or the downstream-system integration surface. The pattern canonicalisation on the wiki is therefore structural (proxy carries caller identity), not mechanistic (which token flow, which consent vocabulary). A follow-up Redpanda deep-dive will be required for mechanism-altitude ingest.

Seen in

  • sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker — The identity-broker instantiation of OBO, now open-sourced (MIT). Zalando's Agentic Identity Broker is the canonical wiki instance of OBO realized as a central broker + token vault rather than JWT-passthrough: the broker records grants (a revocable, optionally time-limited delegation from a user to an agent), holds user sessions (encrypted provider tokens per user + service, shared across that user's agents), and does a RFC 8693 token exchange at tool-call time so the provider token returns only to the gateway and the agent never holds it. Effective permission is stated verbatim as the intersection of the user's authority and the agent's allowed capability ("a tool call lies inside both the user's authority and the agent's allowed capability"). Three sharpened contributions to the pattern:
  • Semi-autonomous / impersonation branch. Between interactive sessions and fully autonomous agents, privileged bridge apps (Google Chat bridge, GitHub webhook apps, schedulers) with a user attestation but no user presence are allowed to impersonate the user toward the broker, so the downstream MCP server still applies the user's effective permissions. Extends OBO to the no-browser trigger case.
  • Consent names a business capability, not a scope. Zalando deliberately does NOT expose OAuth scopes as the consent unit ("provider scope vocabularies are inconsistent and often too coarse for a person to evaluate") — consent reads "reading repositories." Directly addresses the pattern's "consent workflow UX" limitation, and contrasts with XAA (which removes per-vendor consent) by keeping a central consent screen so users can reduce an agent's permissions.
  • Asymmetric revocation named as a first-class limit. "A revoked or expired grant blocks future exchanges, but it cannot revoke a provider token that has already been issued" — the sharpest wiki statement of the token-exchange revocation gap; short token lifetimes are the only mitigation. Also confirms the token-exchange latency limitation from production microservice experience ("a central STS ... on every hop can become expensive or prohibitive in terms of latency"), motivating a move to SPIFFE to split agent-identity attestation from human-identity. Fine-grained per-tool-call authz is layered on via OPA/ExtProc in the gateway (the out-of-band policy shape) — "both broker exchange policy and gateway tool-call policy must permit a request." OBO as the recommended identity flow for an external-agent-to-governed-analytics MCP surface. Databricks' Genie One MCP recommends OBO precisely because agents query through Genie One rather than the underlying tables: the external assistant (ChatGPT, Claude, Copilot, Claude Code) passes the end user's OAuth token, and Genie evaluates Unity Catalog privileges, row filters, and column masks in that user's context. Verbatim: "Two users can ask the same question in the same client and receive appropriately scoped answers without per-user prompt logic", and deep links open only assets the user can access. The post names the OBO foil explicitly — M2M service-principal auth "represents every caller as one identity, removing per-user permission enforcement and potentially limiting personalization and memory" — the clearest wiki statement yet that M2M is the identity-flattening anti-shape OBO exists to replace. External MCP connections are Unity Catalog securables governed through standard grants.
  • sources/2026-07-21-databricks-why-rd-data-belongs-in-the-lakehouse-and-why-agents-need-it — Customer-side production deployment at cellcentric (Daimler Truck × Volvo Group). First wiki instance of OBO deployed end-to-end in a real industrial data platform (hydrogen fuel cell R&D). Identity flows Azure AD → Data Hub → Databricks via OAuth 2.0 token exchange. Verbatim: "If the user lacks access to a table, masked column, or governed view, the agent receives the same boundary." Confirms the structural property that agents are consumers only: "Consumers, including agents, do not receive production write identities." Canonical production evidence that the OBO pattern works at the data-product layer, not just the table layer — agents access governed data products (with markdown context, ownership, lifecycle state) through MCP, all within the user's permission boundary.
  • sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog — Databricks generalises OBO from coding-agent (the 2026-04-17 instance) to org-wide agent populations. First explicit Databricks disclosure of the "specific table row" granularity — "identity flows end to end, from the user who asks the question to the specific table row the agent retrieves. Agents inherit the invoking user's data permissions in real time via on-behalf-of token passing, not a shared service account." The architectural detail that ties OBO to UC's row-filter / column-mask / classification machinery — agents inherit the user's UC permissions in real time, including ABAC-driven row filters and column masks. Dual-identity logging is named explicitly: "Every action is logged against both identities: the real user who triggered the request and the agent that acted on their behalf, capturing which tables were accessed, what operations ran, and when." — first wiki disclosure of the dual-identity audit-log property as a load-bearing OBO requirement. Also positions OBO as layer 1 of the three-layer agent control composition (permissions / Service Policies / Guardrails) within the four-pillar framing (Pillar 1: Delegated access).
  • sources/2025-10-28-redpanda-introducing-the-agentic-data-plane — canonical introduction as Redpanda ADP's first shipped governance feature.
  • sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale — Names the concepts/token-vault as the critical OBO-enabling substrate for systems that don't support service accounts. Redpanda 2026-04-14 Openclaw is not for enterprise scale post canonicalises the token-vault-plus- OBO composition verbatim: "Many enterprise systems — Salesforce, ServiceNow — don't support service accounts at all. They only support user-based auth. On-Behalf-Of (OBO) flows through a token vault, allowing an agent to act in the context of a real user, with that user's actual permissions, without ever directly holding their credentials. You can't build a real multi-tenant agent without this." Bridges OBO from the 2025-10-28 abstraction-altitude framing to the four- component agent production stack's architectural decomposition — OBO is the identity-flow pattern, token vault is the substrate making it work for user-auth-only systems. Mechanism (specific token-exchange protocol) still not disclosed.

Merged aliases

  • identity-broker-for-agent-delegation
  • identity-propagating-ai-gateway- agentic-access-control
  • idp-extended-to-ai-agent-tools
Last updated · 766 distilled / 2,225 read