Understanding "On-Behalf-Of" in AI agent authentication

TL;DR

• Delegation for AI agents: AI agents need to act on behalf of users with scoped, auditable permissions, not full access. Traditional identity systems aren’t built for this.
• Structured tokens with nested claims: Tokens include both agent and user identities using ^sub and ^act.sub claims, enabling secure attribution, least-privilege enforcement, and traceability.
• Chained delegation support: Multi-agent workflows (e.g., user → InfraBot → ArgoCD) are represented through nested claims, ensuring every service in the chain can enforce policy and log actions properly.
• Context-aware permission inheritance: Agents receive only the permissions needed for the task, filtered from the user’s scopes and evaluated at runtime based on environment or trigger.

Security and compliance built-in: Short-lived tokens, revocation checks, and structured logs ensure delegated actions are verifiable, revocable, and meet standards like SOC 2 and HIPAA.

Introduction: The agent delegation challenge

An engineering team at a fast-growing infrastructure company is developing “InfraBot,” an AI agent designed to automate DevOps tasks, including running post-deploy checks, querying monitoring dashboards, and filing PagerDuty alerts. The challenge? InfraBot must interact with external services like Datadog, GitHub, ArgoCD, and AWS CloudWatch, which enforce fine-grained, identity-based authorization using established access management protocols and IAM systems.

This creates delegation issues, where InfraBot must act on behalf of the engineer, but traditional authentication systems don’t fully support agent delegation. However, conventional authentication models, such as OAuth, don’t account for agent delegation. OAuth assumes a human user, and internal tools enforce session-bound roles, leaving InfraBot either over-permissioned or reliant on manual approvals. These patterns also struggle with distributed identity and cross-system delegation, especially as systems span multiple digital service providers.

This gap in delegation creates security and audit challenges, reducing the overall security posture. This is where "On-Behalf-Of" (OBO) authentication comes in. By implementing OBO authentication, teams can secure agent actions with scoped, revocable permissions, ensuring each action is traceable and fully attributed to the right user through proper security and accountability mechanisms.

In this article, you'll learn how to implement secure, scoped delegation for AI agents, ensuring they operate within the permissions granted by users, while maintaining security and compliance across services.

Technical requirements for secure “On-Behalf-Of” delegation

Core challenges in agent delegation for secure access

Before diving deeper into implementation, it’s worth clarifying the core challenges teams face when introducing delegated agent access:

• Dual identity enforcement: Most identity systems are built around single-subject tokens. Representing both the agent and the initiating user in a secure and verifiable way requires changing assumptions at the infrastructure level.
• Scope leakage and over-permissioning: Without fine-grained delegation controls, agents often end up with broader access than necessary, increasing risk.
• Cross-service attribution: Actions performed by agents must retain a consistent attribution chain even as requests move across systems like GitHub, Datadog, or PagerDuty.
• Revocation and expiry enforcement: Many systems lack real-time controls to revoke or limit delegated permissions dynamically.
• Auditability under scale: In distributed systems, audit logs must clearly show who acted, on whose behalf, and what was authorized, especially across identity chaining or when using Active Directory for internal federation

These challenges make it clear why structured, scoped, and verifiable delegation is critical, laying the groundwork for what follows in the rest of the writeup.

When InfraBot performs tasks like querying dashboards or triggering alerts, it must do so with just enough access to represent the engineer who initiated the action. But that requires a foundational shift in how we model identity, authorization, and accountability, one that most current systems aren’t built for.

Delegated identity must represent the full chain of actors

Traditional OAuth flows assign a single subject to a token, usually the human user. However, when an AI agent like InfraBot acts, the token must represent two identities simultaneously: the user (who initiated the action) and the agent (which executes it).

That identity relationship must be encoded in a structured and verifiable manner using claims inside the token itself.

OBO delegation is not the same as impersonation. In impersonation, an agent assumes full user identity, often bypassing fine-grained controls. In OBO, the user identity is preserved inside the token, separate from the agent’s. This distinction allows downstream systems to enforce least privilege and trace actions back to the original user, even when executed by an agent using standard authentication/authorization patterns and identity chaining.

Here's an example of a decoded JWT payload that encodes both the agent identity (sub) and the delegated user identity (obo):

This structure ensures that downstream systems can verify:

• Who made the request (^{agent:infrabot})
• Who delegated the authority (^user:eng123)
• What permissions were scoped (^{incident:read}, ^{monitoring:query})

Each field is machine-readable and cryptographically signed as part of the JWT, enabling precise, auditable delegation.

The following schematic illustrates the token delegation lifecycle described above:

1. User grants permissions to the agent via a structured delegation token.
2. The delegation token encodes both the user and the agent identity, along with the permitted scopes.
3. InfraBot uses this token to interact with external services (e.g., GitHub, PagerDuty) while acting strictly within the user’s delegated authority.

This visual shows how the identity and permission chain flows through each layer, from user → token → agent → service, preserving attribution and enforcing scoped access at every step.

Permission delegation must be scoped, explicit, and revocable

It’s not enough to say InfraBot can act “on behalf of” an engineer. The delegation must be:

• Explicit: which permissions are being granted?
• Scoped: is access limited to one service? One team? One resource?
• Temporary: does it expire after this action or session?
• Revocable: can the engineer or security team revoke the delegation?

This is especially critical in cases like PagerDuty escalation or ArgoCD rollbacks. InfraBot may need high-sensitivity access temporarily, but any over-granting could allow privilege escalation or lateral movement across services. Scoping of AI agent capabilities becomes critical to prevent such risks.

Some modern delegation models solve this by introducing structured delegation chains, where each level of authority from user to agent to service is encoded in the token itself and validated by downstream systems.

Attribution must survive across service boundaries

If InfraBot files an incident, it shouldn’t just say “infrabot@company.com created incident #2943.” The system must attribute the action to the actual user who initiated it, and be able to prove that relationship in an audit trail.

To do this, tokens must carry delegation metadata that downstream systems can log, store, and query. The IETF draft supports this through fields like act (actor) and obo (on-behalf-of) claims, which enable structured logging and traceability across microservices or external APIs.

How the IETF draft specification addresses these needs

The upcoming standard proposes:

• New token formats to encode agent and user identities
• Support for chained delegation and nested claims
• Grant types that allow secure, signed transfers of authority

We’ll break this down in detail in the next section, including how these new flows work and how to build systems that validate them properly.

But at this point, the core requirement should be clear: for agents like InfraBot to operate securely and usefully, identity and delegation must be first-class features of your auth infrastructure, not bolted-on workarounds.

How agent delegation flows can be represented in tokens

For those who want to explore the emerging standard in detail, the OAuth 2.0 draft on agent delegation outlines one possible approach. But everything covered below is independent of it and can be implemented with standard tools today.

Most identity systems assume there’s only one actor per request. That model breaks as soon as you introduce agents like InfraBot that take action on behalf of someone else. To handle this correctly, you need to encode the agent-user relationship directly into the token. This includes not just who the agent is, but also who delegated authority and what exact permissions were passed along.

Representing identity layers with structured JWT claims

Let’s say an engineer deploys a change through your internal system (which may also integrate with external partners or be tracked via change log entries). InfraBot is triggered and starts its work. It needs to query Grafana, post comments to GitHub, and file alerts. In each case, it’s not acting on its own behalf; it's doing this for a named user.

Tokens need to reflect this layered identity structure. For example:

Here, ^sub refers to the agent performing the request, while ^act.sub refers to the original human user. This allows the downstream service to both attribute the action and enforce fine-grained access control. InfraBot cannot step outside the user’s permissions, and everything it does is logged with a clear audit trail.

Support for multi-level delegation when chaining services

Now, imagine InfraBot triggers another automation tool, like ArgoCD, which then calls AWS to tag resources. This is no longer a simple two-party delegation. It’s a chain.

You can support this by nesting claims inside each other to reflect the delegation depth:

This structure allows each system to extract the actor chain and apply policy at the right level. For example, AWS may want to log that the deploy was triggered by the ArgoCD agent, but ultimately attributed to the engineer who initiated the flow.

This flowchart demonstrates how multi-level agent delegation works, showing how authority is passed across different services while maintaining traceability.

Building trust through signature and expiration

To make these tokens reliable, every link in the chain needs to be:

• Signed by a trusted identity provider
• Scoped to a specific action or audience
• Short-lived, with clear expiration

Tokens that last hours or days increase the attack surface. Delegated tokens, in particular, should be designed to expire quickly, typically 5 to 15 minutes, especially when used in sensitive services like deployment tools or monitoring dashboards.

For additional control, tokens can embed infrastructure hooks such as domain-specific languages for policy expression:

• ^{revocation_url}: a service endpoint to check whether the token has been explicitly revoked.
• ^log_url: a reference to where audit logs tied to this token are recorded.

Example:

This process flow highlights how token expiration and revocation work, ensuring that delegated permissions are short-lived and can be revoked in real time.

Why this structure is worth the effort

Most agents today are over-permissioned. They operate as full admins or service accounts with broad, unsupervised access. When something goes wrong, no one knows whether the action was a bug, an attacker, or a legitimate user request.

By encoding delegation into the token format itself, you get:

• Scoped authority that respects user intent
• Traceability through logs and audits
• Revocation models that actually work

These are not academic improvements. They solve real problems around incident response, least privilege, anomaly detection, and compliance, especially in systems that operate at high scale or with external integrations.

In the next section, we’ll look at how to design and validate these delegation chains in code, including how to issue and verify tokens with nested claims in production systems.

How to represent and validate delegation chains in tokens

To securely delegate authority from a user to an agent like InfraBot, your system must not only issue access tokens but also encode who granted the permission, who is acting, and what scope was delegated. This is the heart of delegation chaining.

A valid delegation token must be readable by machines, verifiable by services, and constrained by design. Otherwise, agents end up over-permissioned or unauditable, both of which create real risks in production.

A delegation token must capture user-to-agent intent clearly

Let’s say an engineer named Sam initiates a deploy from your CI dashboard. InfraBot picks up the event and runs a workflow that includes:

• Querying Datadog for post-deploy metrics
• Commenting on a GitHub PR
• Tagging infrastructure via the AWS API

Each service must verify that InfraBot is acting under Sam’s delegated authority

That means the token InfraBot carries must contain:

• Its own identity (agent:infrabot)
• Sam’s identity (user:sam)
• The scope of the delegation (e.g., monitoring:read, deploy:comment)
• A signature from a trusted auth system

Here’s how that scope can be computed programmatically:

This ensures that the agent only receives scopes that the user actually has, eliminating over-permissioning and guesswork.

A simplified JWT payload might look like this:

Downstream services like GitHub (with fine-grained repo permissions) or Datadog (with scoped API keys) can parse this structure and apply checks. Each service uses the structured token to verify:

• InfraBot is the one calling the API
• Sam is the original user delegating authority
• The request falls within the approved scopes
• The token is time-bound and signed

Chains of delegation require nested actors, not just flat claims

In more advanced workflows, InfraBot may invoke other automation agents. For example:

• InfraBot triggers ArgoCD for a deployment rollout
• ArgoCD tags EC2 instances in AWS
• Those tags later trigger a cleanup process by another agent

Now you need a delegation chain: Sam → InfraBot → ArgoCD → CleanupAgent

To represent this in a token, you can nest the act claim recursively:

Each layer of delegation is preserved. This way, AWS (or any recipient service) can validate:

• Who ultimately authorized the action
• Who executed it
• What trust chain allowed it

You can also limit how deep delegation is allowed using policy. For example, you might enforce: “Only one agent may act on behalf of a user.” That prevents uncontrolled chains or token abuse.

Code example: generating and verifying a delegation token

Here’s how you might issue such a token in Python using ^pyjwt:

And to verify it:

This structure gives you a verifiable and enforceable path from end-user intent to final agent action.

Delegation enforcement must be handled by every service

It’s not enough to issue well-formed tokens. Every backend service that receives the token must:

• Parse and validate the full delegation chain
• Match scopes against allowed operations
• Log both the acting agent and the originating user

Services should reject any token that:

• Is unsigned or malformed
• Exceeds the allowed delegation depth
• Grants scope outside the approved context

The cost of skipping these checks is high. If your monitoring tool blindly trusts any request from InfraBot, it will treat all agent actions as equivalent, even if they stem from different users with different privileges.

In the next section, we’ll look at how to control what permissions are inherited and how to dynamically restrict access based on the user’s context and agent behavior.

Designing permission inheritance for safe and context-aware delegation

Not all actions should be delegated equally. When InfraBot posts a GitHub comment about a deployment, it doesn’t need the same level of access it would to revert production infrastructure. Secure delegation depends on tightly controlling which permissions are inherited, when, and how.

The key is granularity. When a user initiates a workflow, your system must evaluate:

• What scopes the user holds
• Which ones are actually needed for the task
• Which can be safely passed to the agent
• And how long they should remain valid

Say Sam has these permissions:

For a post-deploy task, InfraBot may only need ^{monitoring:read} and ^{deploy:create}. The issuing system can apply a filter:

In practice, this logic lives inside your API gateway or backend services, typically in middleware or request handlers. For example, in a Node.js stack using Express or Lambda, you can evaluate delegation scopes at runtime based on the environment and triggering context.

Context-based delegation rules can be enforced at runtime in your API layer. For example, in a Node.js backend:

Tokens should carry both scopes and context:

Using URI-style scope naming (^{urn:infra:...}) improves compatibility across services and makes validation rules more consistent.

Your downstream services (e.g., Express middleware or Lambda handlers) can then enforce context-based rules using the token payload:

When a delegated action is performed, services should emit logs that capture not just who executed it, but also on whose behalf it was done, what permissions were used, and under what context. These logs power audit trails, access reviews, and incident investigations, especially in regulated environments.

Below is an example of a structured log emitted when a delegated action occurs. These logs are designed to integrate with your existing observability stack, whether it's sent to a Security Information and Event Management (SIEM) system, stored in a log aggregator, or forwarded to an audit service.

With scoped, context-aware tokens, you reduce risk while preserving flexibility; agents can act, but only within the exact boundaries of what’s safe.

Now that we’ve defined secure permission inheritance, the next step is to integrate this model into your existing infrastructure. This involves ensuring your APIs and identity systems can read and validate delegation metadata while remaining compatible with your current setup.

Integrating on-behalf-of delegation into existing auth infrastructure

Defining delegation tokens is one thing; integrating them into production systems is another. Most orgs already have OAuth2, RBAC, and session-bound identity. On-Behalf-Of (OBO) delegation needs to fit within these systems, not replace them.

Your APIs must first recognize delegation metadata. Instead of treating sub as the only actor, they must read both sub (the agent) and act.sub (the user), and enforce permissions accordingly.

Delegation-aware middleware

In a real-world Node.js backend using Express, you can implement delegation-aware middleware like this:

Then in your route handler:

This approach is fully compatible with existing Express applications and can be enhanced with Policy Enforcement Points to gate agent actions. It allows APIs to extract both agent and user identity from JWTs and enforce scoped access based on delegation metadata, all without requiring a new framework or breaking existing routes.

Issuing structured tokens

Your identity provider should issue structured JWTs with the delegated scopes, user-agent relationship, and expiration:

You don’t need a full new grant type. Just extend your token issuance endpoint to support these structured claims internally.

For consistency across internal services, document and standardize your token claims. Common delegation-specific fields include:

• ^sub: the agent or actor performing the request
• ^act.sub: the original user delegating authority
• ^scope: list of delegated capabilities
• ^context: optional metadata (environment, trigger source)
• ^{revocation_url}: link to check token status
• ^log_url: link to audit logs for this token

Internal services can use these conventions to validate identity chains and apply fine-grained access control without custom parsing logic.

Auditability and traceability

Your database and logging layers should store both ^performed_by and ^on_behalf_of:

This ensures every delegated action is traceable and meets audit/compliance needs.

With delegation metadata integrated into your infrastructure, it’s crucial to focus on security. In the next section, we’ll explore how to track, log, and enforce secure delegation chains, ensuring compliance and preventing unauthorized access.

Securing delegation chains and meeting compliance requirements

The biggest risk with on-behalf-of delegation isn’t technical, it’s trust. Once InfraBot holds a token that allows it to act for Sam, the system must prove that:

• It knows who initiated the action,
• It constrained what could be done,
• It can revoke access if needed,
• And it can prove all of that after the fact.

This isn’t just security hygiene. In most regulated environments, from SOC 2 to HIPAA to ISO 27001, this traceability is a baseline requirement.

Audit logs must record the full delegation path

When InfraBot tags a deployment, logs should not say “action performed by infrabot.” They should clearly show:

This format supports:

• Security forensics: Who triggered this? Was it within scope?
• Compliance review: Can we show this was authorized?
• Behavioral analytics: Are agents performing risky actions more often?

Logs should be structured and queryable, not just plaintext or console prints, so they can feed into SIEMs, audit pipelines, and monitoring dashboards.

This visualization shows how audit logs should be structured for compliance, ensuring that all delegated actions are fully traceable and auditable across services.

Delegated permissions must be revocable in real time

If Sam’s access changes, she rotates off a team, revokes consent, or leaves the company, any outstanding delegation tokens tied to her should be immediately invalidated.

To enable this:

• Use short-lived tokens (e.g., 5–15 minutes) with refresh patterns
• Check user permission state at token issuance, not just once at login
• Build a revocation registry, even if basic (e.g., Redis-backed token blacklist)
• Tag tokens with a user rev_version or token_id that can be invalidated explicitly

Example revocation check logic:

This ensures that InfraBot cannot continue using delegated permissions once they are no longer valid.

Defense against abuse starts with token validation

Attackers or over-permissioned agents may attempt to:

• Forge tokens that appear delegated
• Replay old tokens after user revocation
• Chain multiple delegations to climb privilege ladders

To prevent this:

• Sign tokens using your strongest private key infrastructure
• Use audience restrictions to prevent cross-service token use
• Limit delegation depth (e.g., no more than 1–2 levels)
• Reject tokens without the required act.sub, exp, or scope claims
• Require TLS at every hop

Downstream services should never trust tokens blindly, even well-formed tokens can be misused by overly privileged agents or bad actors. Your token validation logic must inspect both the actor and the delegated user before allowing any operation to proceed.

Map delegation enforcement to compliance controls

If you're under SOC 2 or ISO 27001, this delegation system helps you meet multiple control areas:

• Access Control (A.9): Actions are scoped to users, not just service accounts.
• Audit Logging (A.12.4): Every delegated action can be logged and traced.
• User Access Review (A.9.2.5): Delegations reflect current user roles and permissions.
• Least Privilege Enforcement (A.9.1.2): Agents cannot exceed user-granted scopes.

Documenting this system in your policies and internal security architecture helps audit reviewers understand the difference between agent autonomy and uncontrolled automation.

Conclusion: Building a trustworthy agent delegation into your systems

In this guide, we’ve explored how to implement secure, scoped delegation for AI agents acting on behalf of users. We covered the necessary identity and permission structures, how to encode them into JWTs, and propagate context across services in a way that is auditable and revocable. By focusing on permission filtering, scope enforcement, and delegation-aware infrastructure, we illustrated how to build secure agent workflows.

Returning to the InfraBot scenario, with structured delegation tokens and scoped permission inheritance, InfraBot now performs tasks like triggering deployments and querying monitoring systems with proper attribution, limited access, and revocability. If your agents currently rely on generic tokens or operate outside your identity system, start by auditing their actions and integrating delegation-aware middleware. For a seamless solution that supports secure agent delegation, explore Scalekit. Scalekit offers the tools you need to implement safe and scalable agent workflows, empowering you to enforce fine-grained permissions and meet security and compliance standards.

FAQ

How does Scalekit enable secure On-Behalf-Of delegation for AI agents in enterprise systems?

ScaleKit integrates On-Behalf-Of (OBO) authentication by allowing AI agents to inherit user permissions in a secure, auditable way. It utilizes structured delegation tokens with nested claims to ensure scoped and traceable actions without compromising security.

How does Scalekit ensure compliance with SOC 2, HIPAA, and other security standards?

ScaleKit ensures compliance by providing clear delegation paths in AI agent workflows. It utilizes signed delegation tokens, scoped permissions, and real-time revocation features, ensuring that actions are traceable, auditable, and compliant with industry security standards such as SOC 2 and HIPAA.

What is On-Behalf-Of (OBO) authentication in AI agent workflows?

On-Behalf-Of (OBO) authentication allows AI agents to perform actions on behalf of users, securely inheriting permissions. This model ensures actions are delegated with explicit scopes, temporary validity, and real-time revocation, enhancing system security and compliance.

How can I implement secure On-Behalf-Of delegation in my existing OAuth2 system?

To implement secure delegation, extend your OAuth2 flows to support nested claims and delegation metadata. Tokens should carry both the agent's and user's identities, with clear scopes, expiry, and revocation mechanisms to ensure secure, auditable delegation.

Why is token expiration critical for secure On-Behalf-Of delegation?

Token expiration is essential in On-Behalf-Of delegation because it limits the timeframe for delegated actions. Short-lived tokens mitigate security risks by ensuring that agent permissions are revoked as soon as they are no longer needed, thereby preventing misuse or privilege escalation.

‍