Attribute-based access control for AI agents

ABAC treats authorization as a decision about a specific action in a specific context. That matters for agents because the next operation is selected at runtime. A broad session role can become an unintended blank check as the agent moves across tools and data.

The policy engine should be separate from the model, enforce decisions at the tool and data boundaries, and emit a record of the attributes and policy version used. Good ABAC is not a longer permission list. It is a different decision model.

Why does agentic software need contextual authorization?

Traditional applications expose routes and functions chosen by developers. An agent can compose those functions into paths that were not individually scripted. The system therefore needs to evaluate authority at each boundary rather than assuming the original task description safely covers every step.

Delegation changes the subject

An agent commonly acts on behalf of a person, team, service account, or organization. Authorization must consider both the agent identity and the represented principal. The agent's technical credential should not grant more access than the principal may delegate.

Data changes the consequence

The same read operation may be harmless for a public catalog and prohibited for controlled data. Resource ownership, tenant, classification, retention rule, and purpose can change the result even when the tool name stays the same.

Environment changes the policy

Connectivity, location, device posture, incident state, maintenance window, and deployment boundary can affect whether an action is allowed. A disconnected environment must not depend on a cloud policy service it cannot reach.

What are the parts of an ABAC decision?

Policy input	Agent example	Validation question
Subject	Agent identity, represented user, service account	Who is acting, and for whom?
Resource	Record, file, mailbox, system, tool target	Who owns it, and how is it classified?
Operation	Read, summarize, transmit, modify, delete	What exact effect is requested?
Environment	Time, network zone, incident mode, device	Under which current conditions?
Purpose	Contract review, customer support, investigation	Is this use allowed for the task?
Consequence	Reversible draft or external commitment	What happens if the decision is wrong?
Approval	Reviewer, scope digest, expiry	Has the required authority been supplied?
Policy	Identifier, version, effective period	Which rule produced the result?

Each attribute needs an authoritative source. If the model can declare its own clearance, data classification, or approval state, the policy is only a prompt.

How does an agent request become a policy decision?

1. The runtime authenticates the acting identity and represented principal.
2. A tool adapter converts the proposed action into a typed request.
3. Resource metadata supplies tenant, owner, classification, and retention context.
4. The runtime assigns an operation and consequence class.
5. The policy decision point evaluates the validated attributes.
6. The decision returns allow, deny, or obligations such as approval, redaction, or narrower scope.
7. The policy enforcement point applies the result immediately before the data or tool boundary.
8. The audit trail records inputs, policy version, result, and execution receipt.

The enforcement point matters. A policy decision made in an orchestration plan but not rechecked at the adapter can be bypassed by another code path or stale state.

What does an agent ABAC policy look like?

The following pseudocode is intentionally vendor-neutral.

deny if subject.tenant_id != resource.tenant_id

deny if operation == "transmit" and
        resource.classification > destination.maximum_classification

require approval(resource.owner) if
        operation in ["modify", "delete"] and
        consequence >= "material"

allow if subject.agent_id in delegation.allowed_agents and
         operation in delegation.allowed_operations and
         resource.type in delegation.allowed_resource_types and
         now < delegation.expires_at and
         request.purpose == delegation.purpose

Policies should be tested as code, reviewed through change control, versioned, and deployed independently of prompts. An agent instruction may describe policy to improve planning, but it cannot replace enforcement.

How should approval appear as an attribute?

Approval is not a boolean. A valid approval attribute should include the request or parameter digest, reviewer identity, reviewer authority, decision, expiry, permitted use count, and revocation status.

{
  "approval_id": "apr_392",
  "request_digest": "sha512:...",
  "reviewer": "usr_8421",
  "authority": "resource-owner",
  "decision": "approved",
  "expires_at": "2026-09-20T15:00:00Z",
  "remaining_uses": 1,
  "revoked": false
}

The policy should deny a changed request, expired approval, reused approval, or reviewer whose authority was revoked. See the approval-gate guide for the full state model.

How do you keep attributes trustworthy?

ABAC quality is limited by attribute provenance.

Use authoritative sources

Identity comes from the approved identity system. Tenant and ownership come from the application registry or resource store. Classification comes from governed metadata or a human-controlled process. Consequence comes from a typed action catalog, not free-form model text.

Define freshness

Some attributes can be cached, while revocation, incident state, and approval use count may require current reads. Document each attribute's source, maximum age, unavailable behavior, and reconciliation path.

Bind to the request

The policy input and downstream action should share one stable request identifier and digest. Otherwise the system may authorize one object and execute another.

Minimize inferred attributes

Do not infer sensitive personal traits, clearance, intent, or legal status from content. If a required attribute is unknown, deny or route to an authorized human process rather than manufacture a value.

How does ABAC interact with tools and data stores?

The policy needs enforcement where effects occur.

Tool adapters

Every adapter should expose a typed operation catalog, declare which parameters are material, identify external effects, and reject unrecognized operations. Generic "execute" adapters make useful policy difficult because the runtime cannot distinguish reading from committing.

Data queries

Tenant and classification restrictions should shape the query before data leaves the store. Fetching a broad result and filtering it after retrieval creates an exposure path and weakens negative tests.

Model endpoints

Routing policy can consider approved endpoint, data-handling terms, location, task type, and classification. Model flexibility should not allow an agent to choose an endpoint outside the permitted boundary.

Export and audit

Audit exports are resources too. Apply the same contextual decision to who can view, search, export, or verify decision records.

What should happen when the policy service is unavailable?

The default for consequential actions should be deny or hold. Cached decisions must have bounded scope and expiry. A cached allow for one resource should not become a standing permission for the resource class.

Document the behavior for:

• no policy response;
• stale attribute source;
• missing classification;
• unknown operation;
• policy bundle mismatch;
• clock uncertainty affecting expiry;
• partial revocation data;
• audit write failure.

Availability is part of authorization design. A highly available policy engine that fails open during its rare outage may still be the wrong control.

How is ABAC tested?

Build a decision matrix before testing interfaces.

Test family	Positive case	Negative case
Tenant isolation	Subject and resource share tenant	Cross-tenant access denied before query
Classification	Clearance and destination permit action	Higher-class data transfer denied
Delegation	Operation is inside bounded grant	Unlisted operation denied
Purpose	Use matches approved workflow	Purpose change denied or reviewed
Approval	Digest, reviewer, expiry all valid	Changed or reused approval denied
Environment	Permitted network and time	Unapproved zone or expired window denied
Unknown input	Known typed action	Unknown attribute or operation fails closed
Revocation	Active reviewer and grant	Revoked identity denied immediately or within stated bound

Tests should run at the real enforcement boundary and confirm the downstream side effect did not occur. A unit test of the policy expression alone cannot prove adapter coverage.

How do you measure ABAC without hiding risk?

Measure decision latency by policy family and deployment, but pair it with correctness and freshness. Useful operational measures include denied unknown operations, stale-attribute denials, approval mismatches, cache hit age, policy bundle drift, and unavailable-policy actions held.

Do not publish a universal latency promise from a development benchmark. Policy complexity, attribute retrieval, cryptography, network topology, hardware, and workload all affect the result. Evidence should name the release and test conditions.

What should a buyer ask to see?

Ask for the action catalog, attribute registry, policy examples, source and freshness table, enforcement-point map, cross-tenant negative tests, approval-binding test, unavailable-policy behavior, and audit entries from the exact release.

Then try to bypass the expected path. Call the adapter with an unknown operation, change a parameter after approval, use a stale grant, cross a tenant boundary, and revoke the reviewer. The answer should be a denial at the boundary, not a model apology after the fact.