AI agent authorization: whose permissions apply?

TL;DR

• AI agent authorization should restrict a delegated request to permissions held by both the agent and the requesting person.
• Permission intersection sets a ceiling. Task scope, tenant boundaries, and current policy can narrow access further.
• Signed identity claims establish trusted context; authorization policies and enforcement points must still check each protected operation.
• Apply access restrictions before enterprise data enters model context. Response filtering cannot undo an earlier disclosure to the model.

What is AI agent authorization?

AI agent authorization determines which resources an agent may access and which operations it may perform. For requests made on someone’s behalf, access should respect both the agent’s permissions and that person’s permissions. Policies can further restrict the request by task, tenant, resource, and current conditions before allowing retrieval or execution.

An agent answers a compensation question for a payroll specialist. A support engineer asks the same question through the same interface. Should they receive the same answer?

Only if they have the same relevant access rights. A shared interface doesn’t create shared authority.

That distinction becomes urgent when agents combine information across systems. The agent might have a legitimate reason to query a payroll source during one workflow. But that doesn’t authorize every colleague to retrieve those records through it.

For an October 2026 rollout, test this with two identities and one request. A successful demonstration should include the denial, not just the answer.

Why AI agent authorization needs more than an agent role

An agent’s permission scope answers what it may do in general. A delegated request adds another question: what may it do for this person?

The single-scope problem

Suppose a reporting agent can read customer accounts across several regions. Its assigned job requires that reach. An account manager, however, can access only their region.

If the retrieval service checks only the agent’s account, the manager may receive records outside their territory. The agent’s broad scope has become a route around the manager’s narrower rights.

This isn’t an inevitable property of service accounts. A service identity can sit behind correctly enforced user-specific policies. The failure occurs when the system treats that service identity as sufficient authority for the whole request.

The OWASP excessive-agency guidance separates excessive permissions from excessive functionality and autonomy. Reducing the tool list helps, but it doesn’t settle whose permissions govern each call.

When an agent acts on behalf of a person

Keep two identities distinct: the agent executing the operation and the person requesting it. The person’s identity isn’t a replacement for the agent’s identity.

You need both to explain the decision later. An audit record containing only an employee ID hides which agent acted. A record containing only an agent ID hides whose request justified access.

A non-human identity should therefore have its own owner, purpose, and permitted activities. A delegated request should also carry authenticated context about the requesting person.

That context must come from a trusted authentication path. A name typed into a prompt, an email address in a ticket, or a model-generated field cannot establish authority.

The over-privilege failure mode

The reverse case matters too. A payroll specialist may access compensation records, but a support-triage agent shouldn’t gain payroll access merely because that specialist uses it.

The person’s broad rights must not expand the agent’s purpose. Otherwise, a narrowly scoped assistant becomes a general-purpose proxy for whichever colleague happens to ask.

AI agent authorization extends established AI access control principles into delegated execution. You’re checking a relationship between identities, resources, and operations, rather than attaching a single role to a chat interface.

Document resource boundaries before assigning roles. If two teams use the same connector with different restrictions, write down both allowed and denied cases. That gives reviewers a concrete contract for AI agent permissions, rather than a role name whose meaning changes between systems.

For buyers weighing the build vs buy: identity axis, the useful question is concrete. Can the platform show separate restrictions for the agent and the requester, including a case where either restriction blocks access?

The intersection model for AI agent authorization

Permission intersection allows an operation only when both relevant permission sets allow it. Think of the result as an access ceiling, not a complete security policy.

How agent and requester permissions intersect

For a delegated request, start with this rule:

`effective access ⊆ agent permissions ∩ requester permissions`

The subset symbol matters. Even an operation present in both sets may be denied by a task restriction, tenant boundary, or organization-wide rule.

Consider a payroll lookup using an agent approved for compensation queries. Each row below is an independent case, not a product benchmark.

In short: either identity can restrict access; neither identity can grant permission that the other lacks.

A practical agent authorization model evaluates more than the table’s two inputs. Identify the resource, operation, tenant, and task before making the decision. “Read ticket” and “export every ticket attachment” should not collapse into the same unchecked permission.

Also distinguish reading from changing data. Permission to view an account doesn’t imply permission to edit its contract. A response may be authorized while a proposed follow-up action is not.

For background work, there may be no requesting person. Use a separately governed service principal with an accountable owner and explicit purpose. Don’t attach a fictitious employee session to make a delegated-access formula fit.

JWT claims and the acting-person context

A JSON Web Token, or JWT, can carry signed claims about the request. These may identify the issuer, subject, intended recipient, and relevant acting party.

The signature helps the receiver detect an altered token. It doesn’t establish that every claim is appropriate for every operation.

The receiver still validates the trusted issuer, expected audience, permitted algorithms, and applicable time limits. JWT best current practices explains why token validation requires more than accepting a valid-looking signature.

Claim names also need care. RFC 8693 token exchange defines an `act` claim for an actor and `may_act` for an authorized actor. It does not standardize an `act_as` claim.

DevRev describes `act_as` in its implementation as context for the person on whose behalf an agent acts. That is an implementation-specific claim, not a universal OAuth requirement.

For the credential lifecycle behind these checks, see how an agent proves its identity. Authorization starts with validated identity evidence; it must not reconstruct identity from the conversation.

Cryptographic evidence still needs policy enforcement

A signed request can ask for a prohibited operation. The signature tells you who made the request, not that you should approve it.

There are three parts to it: validate the identity evidence, evaluate the access policy, and enforce the result. A denial has to stop access. Otherwise, you’ve logged the right decision while permitting the wrong operation.

In Computer, by DevRev, DevRev applies the intersection of agent and acting-person privileges before data reaches the model. Agent Studio provides the configuration surface for agent scopes. DevRev describes its implementation as combining acting-person claims, policy decisions, and query-time restrictions, including field-level controls.

A signed token is only one part of AI agent authorization. Ask where the policy runs and which component prevents a denied request from reaching the protected resource.

For AI agent permission management, also ask how policy changes take effect. A signed token can remain valid after someone changes roles. Depending on the design, permission freshness may require current policy evaluation, token invalidation, or another documented control.

These are implementation requirements, not automatic properties of JWTs. Short token lifetimes reduce an exposure window; they don’t replace the access decision.

Data-layer enforcement: keep unauthorized records out of context

Access restrictions should apply before protected enterprise data reaches the language model. Waiting until the answer is written leaves an earlier exposure unaddressed.

Query-time filtering versus response-time filtering

Imagine the reporting agent retrieves accounts from every region, then asks the model to summarize only the requester’s region. The instruction may shape the answer. It doesn’t change what entered model context.

A response filter runs later still. It may catch an exposed account name, but unauthorized records have already passed into the generation step.

A stronger retrieval design checks access first and constrains the query or its results before they cross that boundary. The model receives only the approved context for that request.

This distinction concerns enforcement timing, not a simplistic choice between application code and database code. An application can enforce access before retrieval. A database can also enforce row and column restrictions. Either approach needs complete coverage and tests.

The weak pattern is post-response-only protection. The stronger requirement is that unauthorized source records never enter this request’s model context.

Field-level enforcement at the data layer

Record access isn’t always enough. A support engineer may read a ticket while remaining unable to view a confidential commercial field attached to it.

A field-level rule has to control the projection: which fields the retrieval operation returns. Removing the confidential value from the final answer is too late if the value already entered the prompt.

Derived data needs the same attention. A summary, search preview, or aggregate can reveal a restricted value without reproducing the original field. Check those representations, too. Their access restrictions must protect the information they reveal, not merely the format in which they store it.

Consider a search result that hides the commercial field but includes a generated preview quoting it. The record filter appears correct; the preview becomes the disclosure route. Test representations, not only underlying objects.

What “before the model” actually means

Draw the path from incoming request to assembled context. Include connectors, search indexes, caches, retrieved files, and tool responses. Every route that supplies protected data needs an enforceable access check.

Caching deserves a deliberate design. An answer authorized for the payroll specialist cannot become an unrestricted cache entry for everyone asking the same question. Cache reuse must respect the relevant access context and policy freshness.

Logs are another destination. A retrieval layer that excludes confidential data from model context but writes it into broadly readable debug traces has moved the exposure.

“Never retrieved” is useful shorthand for excluding unauthorized records from the agent’s retrieval path. It is not a claim that data never exists in an underlying system or index.

Nor does access control guarantee that a model cannot guess, infer, or generate sensitive-looking text from other information. Retrieval authorization limits one exposure path. It doesn’t establish universal confidentiality or answer accuracy.

The authorization stack: standards and mechanisms

The stack works when each component has a defined job. Standards supply useful building blocks, but they do not automatically deliver the finished permission model.

OPA for policy decisions

Open Policy Agent, or OPA, evaluates policies against supplied inputs and data. Its documentation separates policy decision-making from enforcement.

An application might ask whether a particular agent may read a particular field for a particular requester. OPA returns a decision based on the policy and information available to it.

The calling system must supply trustworthy inputs and apply the decision. Installing a policy engine doesn’t ensure every connector consults it. Query rewriting needs an integration. A policy result alone can’t supply one.

Test a direct connector call as well as the normal interface. If one path checks policy and another bypasses it, the permission model is only partially implemented.

NIST SP 800-207 and zero trust for agents

NIST SP 800-207 describes zero trust around protected resources rather than implicit trust in network location or ownership. That principle applies to an agent inside your environment as much as an external client.

The practical implication is straightforward: an internal network address can’t substitute for authorization. An agent’s presence in an approved deployment doesn’t grant access to every connected dataset.

NIST’s document does not certify a particular agent architecture or prescribe DevRev’s claim format. Use it to frame resource access decisions, not as an endorsement of an implementation.

Likewise, NIST SP 800-63-4 informs human digital identity. It says it does not explicitly address machine-to-machine authentication. Its assurance concepts should not be presented as a complete agent authorization standard.

Where OAuth and OIDC fit

The OAuth authorization framework supports limited access to protected resources. Its scopes and grants are building blocks for controlled API access, including delegated scenarios.

OpenID Connect supplies an end-user identity layer over OAuth. It helps establish person-related identity context; it does not define an agent-and-requester intersection policy.

OAuth security best current practice emphasizes restricting access-token privileges and addressing replay risks. These controls support a scoped execution path, but the resource server must still validate and enforce access.

AI agent least privilege therefore spans the whole path. A narrow token, broad database connection, and skipped policy check do not add up to narrow effective access.

Test permission changes before deployment

Keep a small set of acceptance cases for the permission model. Include an allowed read, a denied record, and an allowed record with a restricted field. Run each through the same interface your team will use.

Then change one condition. Remove the requester’s access while leaving the agent unchanged. Remove the agent’s access while leaving the requester unchanged. The next decision should reflect the documented permission-freshness behavior, not an unexplained cache lifetime.

Inspect the evidence. A polite refusal isn’t proof that retrieval was blocked; an authorized answer isn’t proof that the permitted fields were the only retrieved fields. Capture policy decisions and safe identifiers at the boundary without copying restricted payloads into the test report.

Include missing context. If the requester’s identity cannot be validated, the delegated path should reject the request rather than silently substitute a broad service account. Background execution requires its own explicitly approved path.

Authorization and runtime enforcement need the same contract

Authorization defines the permitted operation and the checks that protect data access. Runtime controls must also govern what happens when the agent proposes an action.

An agent may read a ticket but lack permission to send its contents to an external address. That action needs its own destination, content, and permission checks. Earlier read access does not authorize later disclosure.

Runtime guardrails and enforcement covers that execution boundary, including approval gates. An approver’s click should satisfy an approval condition, not silently expand the requester’s or agent’s authority.

Use an AI agent security review checklist to request evidence rather than a feature label. Ask for a trace showing the request, validated identities, relevant policy, permitted fields, and denial outcome. DevRev’s trust center provides a route to security documentation; it does not replace that architecture-specific review.

Begin with one record the requester must not see. Run the request through every retrieval route the agent uses, including caches and direct tools. Then change the requester’s permissions and repeat.

A convincing permission model can explain both decisions. The denied retrieval is part of the product demonstration.

Frequently asked questions

How do you authorize AI agents to access enterprise data?

Define an agent’s permitted resources and operations, then evaluate each request against applicable policy. For delegated requests, restrict access to permissions shared by the agent and requester. Enforce the result before supplying protected data to the model. Task scope, tenant boundaries, and current policy may narrow access further.

What is the difference between agent authentication and authorization?

Authentication establishes evidence of identity, such as a validated workload credential or a trusted person’s session. Authorization decides whether that identity may perform a specific operation on a resource. An authenticated agent still needs permission checks. Identity evidence alone does not grant access or justify a delegated action.

What does least privilege mean for an AI agent?

Least privilege limits an agent to the permissions needed for its assigned work. For a delegated request, that includes respecting the requester’s rights rather than exposing the agent’s full reach. Apply additional task and resource restrictions where needed, and review permissions when the workflow, connected systems, or ownership changes.

Should permissions be enforced in the application or database?

Either layer can enforce permissions, and a design may use both. The important requirement is enforcing restrictions before unauthorized information reaches model context or an action executes. Database controls can constrain rows and fields; application controls can validate requests and mediation paths. Response filtering alone cannot undo earlier exposure.

Which standards help with AI agent authorization?

OAuth supports limited API access, RFC 8693 defines token-exchange and actor semantics, and NIST SP 800-207 supplies zero-trust principles. JWT security guidance covers token validation. OPA is a policy engine rather than an authorization standard. These components require integration; none automatically implements agent-and-requester permission intersection.