PATTERN Cited by 2 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:

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).
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.
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.
patterns/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).
patterns/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").
patterns/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:

User initiates agent task T with scope S.
Token exchange issues a task-bound token T#S signed for this task only.
Every tool call in task T carries T#S.
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/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.