What is ABAC for AI agents?

Attribute-based access control (ABAC) decides a request by evaluating rules against attributes of the subject, the object, the operation and, sometimes, the environment. For an AI agent, the subject is the agent together with the person it acts for, and the object is a tool or resource it calls. This guide maps the NIST model onto agent tool calls.

What ABAC means in NIST SP 800-162

NIST SP 800-162 defines ABAC in one sentence: “ABAC is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of entities (subject and object), operations, and the environment relevant to a request.”

The practical point is that the decision is recomputed from attribute values. NIST says access decisions “can change between requests by simply changing attribute values, without the need to change the subject/object relationships defining underlying rule sets.” For agents, that means a change in a person’s team or in the agent’s session context can change the outcome without anyone editing the rule.

How ABAC differs from ACLs and RBAC

NIST treats ACLs and RBAC as special cases of ABAC that use a single attribute. ACLs use identity, and RBAC uses role. The difference is that ABAC policies “express a complex Boolean rule set that can evaluate many different attributes.”

Model	Attribute the decision uses	Typical agent question it answers
ACL	Identity	Is this agent allowed to call this tool at all?
RBAC	Role	Does this agent’s role include this tool?
ABAC	Any mix of subject, object, operation and environment attributes	Does this agent, acting for this person, may call this tool with this input, in this context?

NIST also notes that an ACL or RBAC model can be made to meet ABAC goals, but demonstrating compliance is “difficult and costly,” and a change to the requirement can leave you hunting for every place the ACL or role mapping needs an update.

Map the NIST components to a tool call

NIST defines four functional points and one optional helper. The table pairs each with a role in an agent tool call. The right-hand column is our mapping, not NIST’s.

NIST component	NIST definition	Where it sits for an agent (our mapping)
Policy Enforcement Point (PEP)	Enforces the decision in response to a request	The point that receives the tool call, such as an MCP server or a gateway in front of it
Policy Decision Point (PDP)	Computes the decision by evaluating applicable policies	The engine that reads the rules and attributes. For Claude Code calls, the client’s permission check plays this part
Policy Information Point (PIP)	Source of the attributes needed for evaluation	Claims from a validated token, direct tool input fields, and any directory or environment lookup
Policy Administration Point (PAP)	Creates, manages, tests and debugs policies	The place where rule files are written, reviewed and tested
Context Handler (optional)	Sets the order in which policy and attributes are retrieved	Decides when attributes are fetched, or cached before a request arrives

The subject: the agent and the person it acts for

An MCP server that protects its tools must validate the token it receives. The authorization specification says servers “MUST validate that access tokens were issued specifically for them as the intended audience.” It also says servers “MUST NOT accept or transit any other tokens.” An invalid or expired token gets a 401, and a valid token without the needed scope gets a 403.

That rule sets where subject attributes come from. Use claims from a token the server validated. Do not accept a team or role value that the agent passes in a tool argument, because the agent controls its own arguments.

The object and operation: attributes you name and own

NIST says ABAC does not work without a usable attribute set. “Attributes need to be named, defined, given a set of allowable values, assigned a schema, and associated to subjects and objects.” Subject attributes also need an authority, meaning the system that issues and revokes them.

For tools, the object is usually a tool name plus the resource it touches. Define each attribute you rely on, list its allowed values and name the system that owns it. Do not rely on annotations that a server publishes about its own tools. The MCP tools specification says clients “MUST consider tool annotations to be untrusted unless they come from trusted servers.”

The environment: when it was read

NIST includes “environment conditions” in the ABAC definition but does not list which ones to use. Its Context Handler description says attributes “may be retrieved in advance of an access request, or cached to avoid the delay inherent in retrieval at the time of the access request.” An environment attribute can therefore be older than the request it decides.

For each environment attribute, write down the maximum age you accept and what the decision does when the lookup fails. A refusal on failure is the safer default for a deny-by-policy rule, but that is a design choice for your team, not something NIST prescribes.

What Claude Code can match today

Claude Code rules are enforced by the client, not by the model. The permissions page says that instructions in a prompt or CLAUDE.md “don’t change what Claude Code allows.” Rule order (deny, then ask, then allow) is covered in tool-level authorization for AI agents. This section covers the one attribute-style mechanism the page documents: matching a tool’s input.

Deny and ask rules can match “a top-level input parameter on any built-in tool with Tool(param:value).” The page gives these examples:

Rule	Matches
`Agent(model:opus)`	Agent calls that request the Opus model tier
`Agent(isolation:worktree)`	Agent calls that request a git worktree
`Bash(run_in_background:true)`	Bash calls that run in the background

The page sets the limits that matter for an ABAC-style design:

The parameter must be a direct field of the tool’s input. Fields nested inside an object or array are not matchable.
Each rule names one parameter. To gate on two parameters, write two rules. Each one blocks on its own, so two deny rules cannot express “block only when both are true.”
A parameter the model omits is never matched. Agent(model:*) does not match a call that leaves model unset.
The value is compared with the literal input before normalization. Agent(model:opus) matches the alias but not a full model ID.
An allow rule for one parameter value does not establish that the call is safe overall, so allow rules keep using each tool’s own specifier syntax.
The primary content field of a tool, such as command for Bash or url for WebFetch, cannot be matched this way. Claude Code ignores such a rule and warns.
For MCP tools, a parameter rule goes in --disallowedTools. Claude Code skips any mcp__ rule that has parentheses when it loads a settings file.

Steps to write attribute rules for an agent

These steps follow the NIST model and the Claude Code limits above. Checked against the Claude Code permissions page, MCP specification revisions 2025-06-18 and 2025-11-25, and NIST SP 800-162, all fetched 2026-11-11.

Decide and place each attribute

List the tool calls in scope. For each one, write the decision as one sentence that names the subject, the object, the operation and any environment condition.
For each attribute in those sentences, record its name, allowed values, the authority that issues it and where it is read at decision time: a token claim, a direct tool input field, or a lookup.
If a rule needs an attribute you cannot read when the decision is made, refuse the request. Dropping the condition would widen access, so an unreadable required attribute never counts as a pass.
Send each attribute to a place that can enforce it. A direct scalar input field can go in a Claude Code parameter rule. Anything else belongs in the server or gateway that receives the call, because the MCP specification requires servers to implement access controls for their own tools.

Write, enforce and test the rules

Write deny rules for the calls that must always be refused. Put them in the settings level your organization controls. Per the permissions page, managed settings are the highest level and no other level can override a managed permission rule.
Keep allow rules scoped to tool names and do not use parameter values in them.
Test each rule with calls that should match and calls that should not. Run Claude Code with --verbose to see the exact parameter names and values it sends.
Write down each attribute you chose not to enforce, and why.

Gaps that a rule file does not close

Attribute rules fail in a few predictable places.

Token passthrough breaks the subject. If a server forwards a token it received to another service, the downstream service may trust attributes that were issued for the first one. The MCP authorization specification forbids this pattern for servers.

Stale environment data makes an allow decision wrong. A cached attribute can still be served after the condition has changed. Set a maximum age, and test what happens when the lookup fails.

Grant and deny patterns leak attributes. NIST notes that “subject attributes can be revealed by the patterns of grant/deny decisions.” Treat decision logs as sensitive, because they can show who has which attributes.

Unowned attributes drift. NIST states that the cost of ABAC includes “managing and maintaining subject attributes and the policies needed for ABAC.” An attribute with no authority will go out of date, and the rules that depend on it will go out of date with it.

When ABAC is worth the cost

NIST says that “ABAC is not the right solution for every access control problem but can prove viable for environments where subjects and objects carry a rich set of attributes and access decisions involve complex relationships among these attributes.”

Use that as a test. ABAC is likely worth the effort when:

The same tool must behave differently for different people or teams.
The attributes you need already exist in a system with an owner, such as an identity provider.
You can name each environment condition and read it at decision time.
You can test rules before they go live, and you have a place to record the decisions.

If most of these are false, a simpler rule on tool names may be enough, and the effort is better spent on the identity and audit layers.

Tool-level rules decide which tools an agent may call, and they are the first layer to get right: how to set tool-level authorization for AI agents. Identity for the agent and the person behind it comes before any attribute check, so read how to map AI agents and humans to one identity model with OIDC. For role-based controls on Kubernetes, see RBAC for AI agents in Kubernetes.

Next steps for your agent policy

Start with the decision sentences from step 1. Most teams find that only a few calls need attribute conditions, and those are the first rules to test. Keep the rest on tool-name rules, which are simpler to audit.

For the broader governance pattern, see the AI agent governance solutions page. The AIControls platform page describes the controls the product documents today.

Sources

Frequently asked questions

How is ABAC different from RBAC for AI agents?

A role answers one question: does this agent hold a role that includes the tool? ABAC can also test the person the agent acts for, the input and the operation together, such as allowing a tool only for one team and only for read operations. That needs attributes that exist, have an owner and can be read when the decision is made.

Can Claude Code enforce ABAC rules on tool calls?

Only in a narrow form. Claude Code permission rules can match a direct, top-level input field of a tool with a parameter rule, such as Agent(model:opus). They match only the tool's own direct input fields. A PreToolUse hook can run your own checks before the permission step, but a hook decision does not bypass a matching deny rule. For anything broader, the check belongs in the server or gateway that receives the call.

Should the agent's identity or the user's identity be the ABAC subject?

Take subject attributes from a token the server validated, since the MCP authorization specification requires tokens issued for that server. A team value that arrives as a tool argument does not qualify, because the model writes the arguments.

Do MCP tool annotations such as read-only make reliable ABAC inputs?

No. The MCP tools specification says clients must treat annotations as untrusted unless they come from trusted servers. Use annotations as review hints, and base rules on attributes your team defines, such as the tool name, or on values the server checks itself.