The developer's guide to AI agent authentication and authorization

AI agents are becoming load-bearing infrastructure. They triage support queues, manage deployments, process payments, and coordinate work across systems. And almost none of them are secured properly.

The gap isn't negligence. It's that the security models we have were built for a different kind of software. OAuth, RBAC, service accounts, MFA: these primitives assume the entity making a request is either a human or a deterministic program whose behavior was defined by a developer and reviewed before it shipped. Agents are neither. They reason at runtime, generate their own intent, and take actions that no one explicitly programmed. The existing toolbox doesn't have a slot for that.

This guide is an attempt to fill that gap. It's written for backend, platform, and security engineers who are either building agentic systems or being asked to secure ones that already exist. It covers the full stack: how to give agents their own identity, how to authenticate them without borrowing user sessions, how to enforce the right authorization at every tool call, how delegation chains break down at scale, how to detect and contain failures when they happen, and how to stop new security challenges like cross-agent privilege escalation, session smuggling in multi-agent pipelines, and Confused Deputy attacks through shared service accounts. Let's dive in.

By the end of this guide, you will know how to give AI agents their own identity, authenticate them without borrowing user sessions or sharing service accounts, and scope what they can do at the level of individual tool calls rather than broad API access. At the end you can find a full implementation checklist you can use to evaluate any agentic system you are building or inheriting, and a list of resources for any topic you want to dive in further. Let's start.

Why agents break everything you know about auth

Most authentication infrastructure was designed for humans. Even the machine-to-machine patterns we use today (service accounts, OAuth client credentials) carry hidden assumptions: the calling entity is deterministic, its behavior is defined in code that can be reviewed, and its scope of action is knowable at provisioning time.

AI agents violate all three assumptions.

An agent is not executing a fixed codepath. It is reasoning at runtime: interpreting a goal, deciding which tools to call, and taking sequences of actions your code never explicitly specified. Two invocations with the same system prompt and the same user request can produce different tool call sequences. A new model version, a new document in the agent's context, or a subtly different phrasing of the input can change what the agent does, without a deploy, without a code review, without anyone noticing.

This creates a new threat surface with some specific characteristics:

• ‍Unpredictable scope at runtime. A service account calling POST /charges does so because a developer wrote that line. An agent calling POST /charges does so because a model inferred that it should. You cannot enumerate the full set of actions an agent might take the way you can audit a microservice.‍
• Amplification through chaining. Agents orchestrate other agents. A compromised or manipulated orchestrator with elevated permissions can issue instructions to downstream agents and cascade failures across your system. A single rogue credential becomes a system-wide incident.‍
• Adversarial inputs as an attack surface. Traditional software treats its inputs as data. Agents treat instructions embedded in inputs (documents, web pages, tool responses) as potential directives. An attacker who can get malicious content into an agent's context can potentially redirect its behavior without ever touching your infrastructure.‍
• No judgment about context. Humans recognize when a request feels wrong and pause. Agents don't have that instinct. An agent asked to diff production secrets against staging doesn't weigh whether the requester should see production secrets. It checks its permissions, finds them sufficient, and executes.

The combination of these properties means traditional perimeter defenses and coarse-grained access control are structurally insufficient. The rest of this guide explains what to do instead.

Agents are not users, and they are not service accounts

The instinct when encountering a non-human identity is to file it under one of two existing buckets: it's either a user account (maybe a bot user) or a service account. Both analogies are wrong, and the mismatch creates real operational and security problems.

Here's a comparison that captures the structural differences:

The most important difference is the first one. A service account's behavior is defined in code. The set of API calls it can make is, in principle, enumerable from its source. Behavior changes only when code changes, through a deploy pipeline with reviewers, tests, and rollback capability.

An agent's behavior is produced at runtime by a model interpreting natural language. The set of actions it might take is not enumerable in advance; it is a function of its prompts, its tools, the model version, and the conversation state at the moment of inference. This means most existing non-human identity controls (code review, change management, behavioral baselining from known endpoints) cannot be applied in the same way.

The scope difference matters too. Service accounts are typically provisioned with narrow, fixed scopes: a Stripe API key for one subaccount, a Snowflake service account with read access to one schema. Least privilege is achievable because both the privileges and the work are narrow. Agents often need access to a broad tool surface because the set of requests they handle is unpredictable. This is not over-provisioning in the traditional sense; the agent genuinely needs breadth. But it means the standard "enumerate and restrict" model of least privilege doesn't translate directly.

The identity chain difference is the third critical distinction. Service accounts are single-hop: one credential, one identity, one request. Agents delegate to other agents, spawn sub-agents, and call tools on behalf of users. The authorization question "who is acting?" may have a five-level answer by the time a write reaches your database.

Treating agents as service accounts causes teams to apply IAM controls that assume deterministic behavior, fixed scope, and single-hop identity, and then discover that none of those assumptions hold.

The three anti-patterns almost every team starts with

Most agentic systems in production today fall into one of three patterns when it comes to credentials. All three are some version of "the agent has far more access than it needs."

Anti-pattern 1: Borrowing the user's session

The user authenticates. The agent uses the resulting session token to make API calls on the user's behalf. This works, and it's the easiest implementation. It's also the equivalent of handing your car keys to a valet and telling them they can also access your bank account.

The blast radius of any failure (a compromised agent, a prompt injection, a plain bug) is the user's entire permission set. If the user is an admin, a confused or manipulated agent is an admin too. The server cannot distinguish the agent's requests from the user's, so there's no meaningful audit trail. And when the session expires, the agent has no way to re-authenticate without human intervention.

Anti-pattern 2: Shared service accounts

A single service account with broad API access gets shared across every agent in the fleet. One credential, stored in an environment variable, used by the support agent, the analytics agent, and the deployment agent alike.

This is the agentic version of a problem enterprise security teams solved for microservices a decade ago. The fix then was per-service identity with scoped credentials. The same fix applies here. Shared service accounts mean you cannot attribute actions to specific agents, you cannot revoke access for one agent without affecting all of them, and you cannot scope permissions to what each agent actually needs.

Anti-pattern 3: Static API keys with no scoping or expiry

A long-lived API key with full access gets baked into the agent's configuration at deployment. No expiry, no rotation, no scope limits. If the key leaks through a log file, a debug endpoint, or a compromised dependency, an attacker has persistent, broad access. And because the key never expires, so does their access.

All three patterns share a root cause: the agent was not treated as a first-class principal with its own identity, its own scoped credentials, and its own permission boundaries. The rest of this guide is about building that model.

Authentication: Giving agents their own identity

Every action an agent takes should answer three questions: Who is acting? What are they authorized to do? What did they actually do? Authentication is the answer to the first question.

The conceptual shift: Agents as principals

An agent is not an extension of the user. It is a new category of actor in your system. The industry is formalizing this: Microsoft introduced Entra Agent ID as a native identity class in their IAM stack; NIST published a concept paper on agent identity in early 2026; the IETF is standardizing an /agents resource in SCIM. These are early signals, but the direction is clear: agents get their own identity, separate from users and separate from service accounts.

Practically, this means each agent (or each class of agent, depending on your deployment model) gets its own client ID, its own scoped credentials, and its own audit trail. When something goes wrong, you can trace it to a specific agent identity. When you need to revoke access, you revoke it for that agent without affecting anything else.

Authentication methods

OAuth 2.0 Client Credentials (recommended for most cases)

The Client Credentials flow is the right primitive for machine-to-machine authentication. An agent authenticates with a client ID and secret, the authorization server validates them and issues a short-lived access token, and the agent uses that token for downstream API calls.

  
const params = new URLSearchParams({
  grant_type: 'client_credentials',
  client_id: process.env.M2M_APP_CLIENT_ID,
  client_secret: process.env.M2M_APP_CLIENT_SECRET,
});

const response = fetch('https://<subdomain>.authkit.app/oauth2/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: params,
}).then((response) => response.json());

const accessToken = response.access_token;

  

The authorization server returns a time-limited JWT:

  
{
  "iss": "https://<subdomain>.authkit.app",
  "aud": "client_123456789",
  "sub": "user_01JQ0E27VT3MH79RY0FVA4QBP9",
  "org_id": "org_01HRDMC6CM357W30QMHMQ96Q0S",
  "sid": "app_consent_01JQ0E27WE4K1RCMH7Q094M1GJ",
  "jti": "01JQ0E27ZXE4XNHVP870S6PWYN",
  "exp": 1742698034,
  "iat": 1742697734
}
  

Token expiry is a feature built-in on purpose. Short-lived tokens limit the window of exposure if a token leaks. Pair this with automatic rotation and you get credentials that are self-limiting.

Mutual TLS (mTLS) for high-security environments

mTLS requires both the client and server to present and verify certificates, establishing a two-way authenticated and encrypted channel. This provides certificate-based identity verification with no shared secrets, and protection against man-in-the-middle attacks.

For AI agents, mTLS is most appropriate in environments where you control both sides of the connection (internal service meshes, high-assurance enterprise deployments) because managing certificate provisioning and rotation for agents at scale adds operational complexity.

API keys: When and how

API keys are simple and widely understood, but they come with significant tradeoffs for agentic systems: they typically don't expire automatically, they often lack granular scope controls, and if compromised they provide complete access to the associated account.

If you're using API keys, apply these constraints:

• Generate unique keys per agent, never shared.
• Scope keys to specific operations at the API level.
• Set explicit expiry and build rotation into your deployment pipeline.
• Store them in a secrets manager, never in code or environment variables in plain text.
• Audit usage and alert on anomalous patterns.

For production agentic systems, treat API keys as a fallback for services that don't support OAuth, not as a default.

Dynamic credential issuance (just-in-time)

The most sophisticated approach is just-in-time credential issuance: rather than providing agents with pre-provisioned credentials, your infrastructure generates temporary credentials on demand when an agent needs to access a resource, scoped precisely to what that task requires, and expiring shortly after.

This is more complex to implement but eliminates the class of credential exposure problems that come from long-lived secrets. It's the direction zero-trust architectures are pushing.

What about agents that need to navigate human login flows?

When agents operate browser-based workflows, they encounter authentication systems designed for humans: OAuth consent screens, SAML flows, CAPTCHA challenges, and session cookies. There are a few patterns here, ranging from bad to acceptable:

• ‍Cookie syncing (avoid): Copying a user's browser session state to an agent's browser. It works, but the access is completely unscoped, there's no audit trail distinguishing agent actions from user actions, and the session expires unpredictably.‍
• Credential injection (avoid): Passing username/password to an agent to complete a login form. This bypasses MFA, is impossible to scope, and creates a persistent credential exposure risk.‍
• OAuth with proper redirect handling (preferred): For services that support OAuth, agents should be able to complete the authorization code flow: the user consents once, and the agent receives a scoped, revocable access token. This requires the agent to handle redirects and for the application to support programmatic OAuth flows. This is the direction MCP Auth and similar protocols are pushing.

The practical reality is that many enterprise applications don't yet support proper OAuth-based agent authentication. The gap between what agents need and what web apps provide is one of the active areas of standardization effort.

Authorization: Why proving identity isn't enough

Authentication tells you who is making a request. Authorization tells you what they're allowed to do. For traditional software, these two problems are often solved together: the service account has a fixed role, and the role defines what it can do.

For agents, this coupling breaks down.

AI agents have two distinct authorization contexts:

• ‍What the agent is allowed to do (its own permissions, granted when it was provisioned or during the OAuth consent flow)‍
• What the user it's acting for is allowed to do (the user's permissions in your system)

For agents acting on behalf of users, both constraints must apply simultaneously. An agent shouldn't be able to do more than its own permissions allow. But it also shouldn't be able to do more than the user's permissions allow. The effective permission set at any tool call is the intersection of the two.

Most current implementations check one or the other, not both. This is the root cause of the Confused Deputy problem.

The Confused Deputy problem

The Confused Deputy is a security pattern where a program with authority is tricked by a lower-privileged entity into misusing that authority. For AI agents, this is not a theoretical risk; it's a practical failure mode that occurs routinely in deployed systems.

Consider a concrete example. A platform engineering team deploys a Cluster Debug Agent to help troubleshoot Kubernetes deployments. The agent is provisioned with a service account that has secrets:read access to verify configuration maps. A legitimate and appropriate capability.

A developer debugging a payment service crash needs to see production environment variables. They don't have direct access to production secrets; those are restricted to SREs. So they ask the agent: "Diff the production environment variables against staging so I can see what changed."

The agent executes the query. It has secrets:read permission. The cluster control plane allows the request. The agent posts the diff to a shared Slack channel:

  
- STRIPE_SECRET_KEY: "sk_test_..."
+ STRIPE_SECRET_KEY: "sk_live_51M..."
  

A production API key is now visible to everyone in that channel.

No misconfiguration occurred. The agent acted within its permissions. The developer acted within theirs. The system failed because it did not check the intersection of their privileges. The agent's secrets:read permission was used to satisfy a request from someone who shouldn't have had that access. The agent acted as a confused deputy.

The architectural implication is that authorization in agentic systems must check whose permissions apply at the moment an action is taken: the agent's own capabilities, and the capabilities of every principal in the delegation chain leading to that action.

In systems where agents operate in shared contexts (a team Slack channel, a shared dashboard, a multi-user workspace) the problem is more subtle. If the agent authenticated with a high-privilege user's credentials, it can surface data to anyone who interacts with it in that shared context, regardless of whether those users have access to that data. Authorization needs to happen at output time (who will see this response?) not just at retrieval time (do I have permission to retrieve this?).

Fixing this requires knowing whose permissions should be intersected in the first place, and that depends on what kind of agent you're dealing with.

On-Behalf-Of vs. Autonomous agents

Not all agents have a user in the loop. The authorization architecture for an agent acting on a human's behalf looks fundamentally different from one operating autonomously, and conflating the two is one of the more common design mistakes teams make early on.

On-Behalf-Of (OBO) agents

OBO agents are extensions of a human user within an active session. Claude Code, GitHub Copilot, and most AI pair-programming tools work this way. The agent acts because a human user asked it to, in the context of that user's session.

The key authorization requirement for OBO agents is scope attenuation: the agent should access a subset of the user's permissions, never the full set. If a user asks an agent to refactor a specific file, the agent should access that file, not the entire repository, not the adjacent configuration files, not the secrets the user happens to have access to.

In practice, most OBO implementations inherit the user's full access token. This is the easy implementation, and it's wrong. It makes every agent action as privileged as the most privileged user in your system.

The correct model is: when a user delegates a task to an agent, the agent receives a constrained token that represents a bounded subset of the user's capabilities, scoped to what the task actually requires. This is harder to implement and requires thinking about delegation at the protocol level.

Autonomous agents

Autonomous agents operate without a live user session. They're triggered by schedules, events, or orchestrators. A CI/CD agent, a data pipeline agent, an infrastructure monitoring agent: none of these has a human waiting on the other side.

Autonomous agents have their own identity and their own permissions, independent of any user. The authorization question is simpler in some ways (there's no delegation chain to maintain) but raises its own challenges around how to scope permissions for work that's non-deterministic at provisioning time.

For autonomous agents, the effective approach is tool-level authorization: rather than granting the agent broad API access, you define exactly which tools it can call, with what parameters, and under what conditions. Access policies attach to tools, not to the agent's credential.

Whether an agent is OBO or autonomous, the underlying problem is the same: agents need enough access to handle non-deterministic work, but not so much that a failure cascades. That tension is what least privilege is supposed to resolve, and for agents, it's significantly harder to apply than it is for traditional software.

Scope attenuation and least privilege

With a microservice, you enumerate what it calls and scope its credentials to those endpoints. The scope is fixed, auditable, and doesn't change unless a developer changes the code. With agents, the scope is non-deterministic by design: a coding agent might need read access to a backend repository today and write access to a frontend repository tomorrow. You can't enumerate all possible access patterns at provisioning time.

This doesn't mean you abandon least privilege. It means you implement it differently.

Tool-level scoping instead of API-level scoping

Rather than granting an agent access to an API (e.g., repo:write), define a set of specific tool functions the agent can call, with constraints on each:

  
# Instead of: grant agent REPO_WRITE scope
# Do this: define a scoped tool that only does what the agent needs

def agent_update_file(
    repo: str,          # constrained to repos agent is authorized for
    file_path: str,     # constrained to file extensions in allowlist
    content: str,
    agent_id: str,      # logged for audit
    session_context: str # the task that prompted this call
) -> UpdateResult:
    # Validate against agent's authorized repos
    if repo not in get_authorized_repos(agent_id):
        raise AuthorizationError(f"Agent {agent_id} not authorized for {repo}")
    
    # Validate file path is within allowed scope
    if not is_allowed_path(file_path, agent_id):
        raise AuthorizationError(f"File path {file_path} outside agent scope")
    
    # Proceed with write
    return repository.write(repo, file_path, content)
  

The tool is the authorization boundary. The agent calls the tool; the tool enforces the constraints.

Time-bound access for elevated permissions

Agents that need elevated access for specific operations shouldn't hold those permissions permanently. Use time-bound access to:

• Grant deploy access only during a scheduled release window.
• Issue temporary permissions that expire after a task completes.
• Require re-authorization for operations outside normal patterns.

This shrinks the window of potential misuse without blocking the agent from doing its job.

Dynamic permissions based on task context

The most sophisticated implementations adjust permissions dynamically based on what the agent is currently doing:

• During a code review task, allow read access to the relevant repository.
• During a deployment task, allow write access to the target environment.
• Outside of active tasks, reduce to a minimal monitoring-only posture.

This requires your authorization layer to understand task context, not just agent identity, which brings us to fine-grained authorization.

Fine-grained authorization and the limits of RBAC

The natural instinct when you need task-scoped, context-aware authorization is to reach for RBAC and start creating more granular roles. It's the model everyone already understands, and it seems like it should scale down to the level of specificity agents need. It doesn't, and understanding exactly why leads directly to the solution.

Why flat RBAC fails for AI agents

RBAC is flat. It maps a subject to a role, and a role to a set of global permissions: tickets:read, files:write, repo:push. This works for humans because human access typically correlates to job title, which is stable and broad. An editor can edit all repos. A viewer can read all tickets. The role is the boundary.

Agent access correlates to tasks, which are transient and specific. You don't want an agent to be an "editor of repositories." You want to enforce: "This agent can push to branch:feature-xyz in repository:api, and nothing else."

To express this in flat RBAC, you'd need a unique role for every permutation of resource and permission: Role: Editor_Repo_API_Branch_XYZ, Role: Viewer_Repo_Frontend_Branch_ABC. In an enterprise with thousands of repositories and ephemeral branches, you're managing O(N x M) roles. The overhead exceeds the value.

The result is the "God mode" problem described in section 6: to avoid role explosion, teams grant broad scope. The billing agent that needs to read invoices gets Files.Read.All. It can now read employee contracts and patent drafts too. You've granted root access to a probabilistic script.

FGA: RBAC applied to a resource hierarchy

Fine-Grained Authorization (FGA) is not a replacement for RBAC; it's an extension of it. You keep the familiar mental model of roles (Editor, Viewer), but instead of attaching them to a global namespace, you attach them to specific nodes in a resource hierarchy:

  
Organization: Acme
 └── Repository: API
       └── Branch: feature-xyz  <-- agent permission starts here
             └── Actions: [push, merge]
  

This gives you two properties that flat RBAC can't provide:

• ‍Vertical inheritance: An agent assigned Editor on Branch: feature-xyz automatically inherits access to every resource inside that branch. You don't need to enumerate every file.‍
• No lateral movement: That permission does not bleed sideways to Branch: staging or upward to Repository: API. The agent has full capability where it's needed and zero capability everywhere else.

Structural resources vs. asset data

A common concern about centralized authorization is the synchronization overhead. If your application manages millions of files, does every one need to be registered in the authorization graph? No, and this distinction matters for performance.

You sync only the structural hierarchy: the containers that define access boundaries (Organizations, Workspaces, Projects, Folders). The high-volume asset data (individual files, records, embeddings) stays in your primary application store. When an agent requests access to a specific asset, your application performs a two-step check:

1. Your application logic identifies which container the asset belongs to (e.g., Folder: Q3-Financials).
2. The FGA service checks (subject=Agent, role=viewer, resource=Folder:Q3-Financials).

Access is decided against the parent container, not the individual asset. The authorization graph stays lean, latency stays low, and you avoid double-write consistency issues.

The intersection check for OBO agents

For agents acting on behalf of users, FGA solves the Confused Deputy problem through an intersection of permissions. Both the agent and the user must have access to a resource before it's returned. Neither alone is sufficient.

When an MCP server receives a tool invocation, the check looks like this:

  
async def authorize_tool_call(
    agent_id: str,
    resource: str,
    user_context: Optional[str],
) -> AuthDecision:

    # Agent must have access
    agent_permitted = await fga.check(
        subject=f"agent:{agent_id}",
        role="viewer",
        resource=resource
    )
    if not agent_permitted:
        return AuthDecision.DENY

    # For OBO agents: user must also have access
    if user_context:
        user_permitted = await fga.check(
            subject=f"user:{user_context}",
            role="viewer",
            resource=resource
        )
        if not user_permitted:
            return AuthDecision.DENY

    return AuthDecision.ALLOW
  

This is also the right place to slot in Rich Authorization Requests (RFC 9396). RAR lets agents pass structured intent objects ({"file": "main.rs", "action": "edit"}) rather than opaque scope strings. But RAR is only a data format; it's an envelope for the request, not the decision engine. It doesn't know that /backend belongs to Team A or that the user is an admin of Team A. FGA provides the hierarchy that gives RAR semantic meaning.

Agent memory as a protected resource

As agents evolve from stateless scripts to persistent collaborators with vector database memory, a new authorization surface opens. If an agent summarizes a sensitive document into long-term memory, that information can resurface to a different user who lacks access to the original source.

The fix is to treat agent memory as a protected resource governed by the same policies as the source files:

• Tag every embedding written to a vector store with its source resource_id.
• When the agent queries its memory, augment the vector search with an FGA check: if the current user cannot access the source resource_id, that memory is invisible to the agent.
• In high-security environments, use ephemeral memory shards that flush when an agent moves between different authorization contexts.

This ensures that an agent's internal context is as strictly governed as its real-time actions, and that the authorization boundary doesn't silently stop at the retrieval layer.

FGA handles the authorization decision at each individual tool call. But in multi-agent systems, those calls happen across chains of agents that each issue and receive tokens. That chain introduces a structural problem that per-call authorization alone can't solve.

Multi-hop delegation: Where OAuth breaks down

Single-hop delegation, where a user authorizes an agent and the agent acts on the user's behalf, is manageable with existing OAuth primitives. OAuth 2.0's Token Exchange specification (RFC 8693) handles this reasonably well. The identity chain is clear: Human → Agent → Service. Authorization servers can validate the delegation.

Multi-hop delegation is where things break. When Agent A spawns Agent B that calls Agent C that accesses Service D, the chain is: Human → Agent A → Agent B → Agent C → Service D. RFC 8693 supports representing this chain through nested act claims in JWT tokens, but the specification itself is explicit about the limitation: prior-actor claims in nested act chains are informational only and are not to be considered in access control decisions.

The IETF is working on extensions to address this. The most relevant drafts: Attenuating Authorization Tokens for Agentic Delegation Chains (requiring each hop to produce a token with strictly fewer permissions than the one it received, preventing privilege escalation through the chain); OAuth Token Chaining (making the delegation chain cryptographically verifiable rather than informational); and a SCIM /agents schema to standardize how agents are represented across IAM systems. None is fully deployed yet.

For teams building multi-agent systems today, the practical guidance is:

• ‍Treat each agent in a chain as an independent principal. Each agent authenticates with its own credentials; each agent is authorized based on its own permissions. Don't propagate user tokens down delegation chains.‍
• Implement scope narrowing at every hop. When Agent A delegates to Agent B, Agent B's token scope should be a subset of what Agent A was authorized to do. Never equal or greater.‍
• Log at the semantic level, not just the HTTP level. OAuth logs show token issuances. You also need to capture what each agent was trying to accomplish at each step.‍
• Design for compromised intermediaries. Assume any agent in the chain could be manipulated. Downstream agents should validate the reasonableness of instructions they receive, not just execute them.

Implementation checklist

The sections above focus on identity and authorization: the two problems that are structurally unique to agents and where the existing toolbox falls shortest. There's more to securing agentic systems than these, things like credential hygiene, audit logging, prompt injection defense, human oversight for irreversible actions. The checklist below spans the full surface. Use it to evaluate where you stand.

Identity and authentication

• Each agent has its own client ID and credentials, not shared with other agents or users.
• Agent credentials are stored in a secrets manager, not in code or environment variables.
• Tokens are short-lived (≤1 hour for access tokens); refresh logic is automated.
• Client secrets are rotated on a schedule (≤90 days); rotation is automated.
• Revocation has been tested: you can kill an agent's access in under 5 minutes.

Authorization

• Agent permissions are scoped to specific tools and resources, not broad API access.
• For OBO agents: user permission check runs at every tool call, not just at session start.
• The effective permission set is the intersection of agent permissions and user permissions.
• Time-bound access is used for elevated or sensitive operations.
• Authorization checks run at output time in shared contexts, not just retrieval time.

Multi-agent and delegation

• Each agent in a multi-agent workflow has its own identity; user tokens are not propagated.
• Permission scope narrows at each delegation hop, never expands.
• Delegation chains are logged with enough detail to reconstruct the authorization path.

Audit and monitoring

• Every tool invocation is logged with agent ID, user context, task context, and authorization result.
• Reasoning traces (where available) are captured alongside API logs.
• Alerts exist for agents calling tools inconsistent with their task context.
• Anomaly detection runs on agent behavior patterns, not just API call volume.

Defense

• Irreversible operations require human confirmation before execution.
• Tool invocations are validated against task context before execution.
• Content from external sources (web, documents, tool results) is treated as untrusted.
• Input from agent-to-agent communication channels is validated before acting on it.

Incident response

• Runbook exists for "compromised agent" scenario.
• Credential revocation path is documented and tested.
• Rollback capability exists for agent-triggered infrastructure changes.
• Security team has access to agent reasoning traces for forensic investigation.

Secure your AI agentswith WorkOS

Everything this guide covers (identity, authentication, authorization, delegation, access control) is something WorkOS has already built for you. So instead of assembling the infrastructure piece by piece, you can ship.

• ‍Get authentication right from the start. User Management and AuthKit give your agents a proper auth layer: OAuth flows, session management, MFA, and more. Add Enterprise SSO and your agents authenticate through whatever identity provider an enterprise customer already uses. When users join or leave, Directory Sync keeps agent access in sync automatically, and Just-in-Time provisioning means agents get exactly the right permissions the moment they're created, not whenever someone remembers to run a script.‍
• Stop worrying about who can access what. WorkOS FGA is purpose-built for the authorization problems agents create. Attach roles to specific nodes in a resource hierarchy rather than a global namespace, and get permission inheritance and scope boundaries automatically: an agent with Editor access on a specific branch inherits everything inside it, and nothing sideways or above. For OBO agents, FGA gives you the API to implement the intersection check cleanly (both the agent and the user must have access before a resource is returned) with a simple two-call pattern. RBAC covers the foundational layer underneath.
• Lock down your MCP servers. WorkOS MCP Auth handles OAuth 2.1 for MCP, including metadata discovery, Dynamic Client Registration, and JWT validation with RBAC enforcement baked in. There are two ways to integrate: the full AuthKit setup, where AuthKit acts as the authorization server and handles the complete OAuth flow; and Standalone MCP OAuth, for teams with an existing auth system who want to add MCP support without replacing their current login experience. Either way, the MCP Auth developer guide walks you through it.
• The rest of the stack. Audit Logs gives you a structured, queryable event trail with every action tied to a specific identity: exactly what you need when something goes wrong and you're trying to reconstruct what an agent actually did. Vault handles encryption key management for sensitive data your agents touch. Radar catches anomalous agent behavior at the traffic layer before it becomes your problem. And the Admin Portal lets enterprise IT admins manage agent access themselves, without filing a ticket every time something changes.

Sign up and start building, or dig into the docs to see how it all fits together.

Read more

• How to build AI agents
• The architecture of governable AI agents: Constrain first, observe always
• How AI agents connect to systems
• AI agents vs. service accounts: Key differences and what to do about them‍
• How AI agents authenticate and access systems‍
• Securing agentic apps: Give your AI agents their own credentials‍
• Logging AI agents into web apps‍
• MFA for AI agents: Why traditional authentication falls short‍
• The developer's guide to MCP auth‍
• Agents need authorization, not just authentication‍
• AI agent access control: How to manage permissions safely‍
• Best practices for AI agent access control‍
• OAuth On-Behalf-Of for AI agents‍
• AI agents and the multi-hop delegation problem‍
• Securing AI agents: A guide to authentication, authorization, and defense