Beyond RBAC — Why AI Agents Need Purpose-Aware Access Control

When a human runs a SQL query, you can reasonably infer the purpose from their job function. An analyst querying a dashboard table is probably doing analytics. The access control question is simple: does this role have SELECT on this table?

When an AI agent runs the same query as step 47 of an autonomous chain — three levels of tool delegation deep, far from the original human prompt — that inference breaks. The agent might be operating well outside the user’s intent, and the access control system has no way to know. It only knows the role. It doesn’t know the purpose, the chain depth, the agent type, or whether this access pattern is normal.

The question that keeps surfacing in every security architecture I think about: can this agent invoke this tool on this data for this purpose? RBAC doesn’t answer that. It doesn’t even have the vocabulary for it.

A Concrete Example

#

Imagine a customer support agent built on MCP. A support engineer asks it: “summarize this customer’s recent tickets.” The agent calls a search_tickets tool, retrieves 5 tickets, and summarizes them. Perfectly reasonable.

Now imagine the same agent, same role, same permissions — but an adversarial prompt injection in one of the tickets causes it to chain additional tool calls: export_customer_data → call_external_api → send the data to an external endpoint. Every individual tool call passes RBAC — the role has access to all of these tools. But the purpose has shifted from “summarize tickets” to “exfiltrate customer data,” and no access control layer noticed.

RBAC sees: role has permission. RBAC doesn’t see: why, how deep in the chain, whether the purpose changed, or whether this access pattern is anomalous.

That’s the gap.

What Would Catch This?

#

The answer isn’t more roles or finer-grained permissions. It’s a fundamentally different kind of access control — one that evaluates context, not just identity.

Attribute-Based Access Control (ABAC) evaluates policies against a rich set of attributes at decision time. Not just “who are you” but “what are you doing, why, with what, and does that make sense right now?”

In the support agent scenario above, an ABAC policy would have caught the exfiltration at the second tool call: purpose shifted from ticket_summary to data_export, chain depth exceeded the threshold, and the call_external_api tool was invoked on PII-classified data — three attribute violations in one request.

For agents and tool calls, the relevant attributes span four dimensions:

Agent Identity Attributes

#

• Human principal — who is the agent acting on behalf of?
• Agent type — is it a trusted internal agent, a sandboxed tool, an external MCP client?
• Agent version — is this a known, reviewed agent build or an untested version?
• Current tool — what specific tool is being invoked right now? (read_table is very different from export_data or call_external_api)

Request Context Attributes

#

• Purpose — what was the original user intent? (analytics, reporting, data export, model training)
• Data classification — what sensitivity level is being touched? (public, internal, PII, financial, regulated)
• Chain depth — is this a direct human request or step N of an autonomous agent chain?
• Prompt lineage — can the current action be traced back to an explicit human instruction?

Environmental Attributes

#

• Time and region — is this happening during business hours, from an expected geography?
• Network path — PrivateLink, VPN, or public internet?
• Regulatory regime — GDPR, DORA, EU AI Act Article 9 (high-risk AI systems)?
• Data residency — does the data need to stay in a specific jurisdiction?

Behavioural Attributes

#

• Access pattern — has this agent made anomalous requests in this session?
• Volume and velocity — is the rate of tool calls within expected bounds?
• Data volume — is the agent accessing more rows/columns than typical for its purpose?
• Escalation pattern — is the agent progressively expanding its access scope?

The policy then becomes something like:

allow tool=sql_query
  if principal.clearance >= data.classification
  AND request.purpose IN ['analytics', 'reporting']
  AND agent.type = 'trusted'
  AND agent.chain_depth <= 3
  AND NOT behavioural.anomaly_detected

That’s a fundamentally different statement than GRANT SELECT ON table TO role.

The Architecture

#

  Human prompt
      │
      ▼
  Intent classifier ──► extracts purpose attribute
      │
      ▼
  Agent runtime ──► carries [human_id, purpose, agent_type, chain_depth]
      │
      ├──► Tool call ──► ABAC policy engine evaluates:
      │                   [agent attrs + data attrs + context attrs + env attrs]
      │                   → allow / deny / transform (mask, redact, sample)
      │
      ├──► Inference call ──► same policy engine:
      │                       can this agent send this data to this model?
      │                       (data sovereignty: which LLM is permitted
      │                        for this classification level?)
      │
      └──► Audit trail ──► every decision logged with full attribute context
                           (not just "user X queried table Y" but
                            "agent A, acting for user X, invoked tool T
                             on data classified C, for purpose P,
                             at chain depth D — decision: allow")

Three decisions happen at the policy engine, and they’re different from traditional access control:

1. Tool-level authorization. Not “can this role call this function” but “can this agent invoke this specific tool, on this specific data, for this stated purpose, at this point in the chain.” The same agent with the same role might be allowed to run SELECT COUNT(*) but denied SELECT * with LIMIT 1000000 — because the volume attribute trips the policy.

2. Inference routing. When an agent sends data to an LLM for processing, the policy engine evaluates: can this data go to this model? Data classified as PII under GDPR might be allowed to reach an in-boundary model (hosted within the same platform or region) but denied from reaching an external API endpoint. This is data sovereignty applied to inference, not just storage.

3. Response transformation. Instead of binary allow/deny, the policy engine can transform the response. An agent querying customer data for a reporting purpose gets masked SSNs. The same query for a compliance investigation purpose gets unmasked data. The masking decision is driven by purpose, not just role — dynamic, context-aware data protection.

Where Could This Plug In?

#

The building blocks for ABAC already exist at various layers of the stack — they just aren’t connected through a unified policy engine today.

Identity propagation is largely solved. External OAuth, SAML, JWT claims — these protocols already carry principal identity and role. Extending JWT claims with agent_type, chain_depth, and purpose is a protocol extension, not a new protocol.

Data classification exists in most modern data platforms — automatic tagging of columns as PII, PHI, financial, regulated. These tags already drive masking and row access policies — but only based on role, not on agent context or purpose.

Inference routing is an emerging pattern. Proxies that sit between agents and LLMs can already decide which model an agent reaches. Making that decision dynamic — based on data classification and purpose rather than static configuration — is where ABAC would add value.

MCP and tool-level security is the most interesting integration point. MCP currently has no built-in security layer. Adding ABAC at the tool call boundary — evaluating purpose, chain depth, and data classification before every tool invocation — would be the most impactful enforcement point for agent governance.

Audit is fragmented. Every layer generates its own records — query logs, tool call logs, inference logs — but no single system captures the full attribute context of a decision across layers. A unified audit trail is a prerequisite for the anomaly detection and incident response that ABAC enables.

ABAC Component              │ Current State (March 2026)
────────────────────────────┼────────────────────────────────────────────────
                            │
Agent identity (principal)  │ OAuth / JWT — solved in protocol, adoption
                            │ growing
                            │
Agent identity (type/depth) │ Production — Okta for AI Agents (GA April 2026,
                            │ agents as non-human identities), Auth0 FGA
                            │ (Zanzibar-based delegation chain tracking with
                            │ scope attenuation, Token Vault, XAA in MCP),
                            │ MS Agent Governance Toolkit, Ping Identity,
                            │ Cisco Duo IAM, CSA delegation framework
                            │
Purpose / intent             │ Emerging — Proofpoint "Intent by Design" (5
classification              │ pillars, productized), Token Security intent-
                            │ based controls, Cedar natural-language-to-policy
                            │ in AWS Bedrock AgentCore
                            │
Tool authorization          │ Production — AWS Bedrock AgentCore Policy
                            │ (Cedar, GA March 2026), Cisco MCP gateway
                            │ with fine-grained per-task scoping (RSA 2026),
                            │ OPA/Rego for custom ABAC policies
                            │
Inference routing           │ Emerging — platform-level model routing exists;
                            │ dynamic policy-driven routing based on data
                            │ classification is not standard
                            │
Data classification         │ Production — automatic tagging in data
& agent data access         │ platforms (PII, PHI, financial); Immuta ships
                            │ ABAC + purpose-based policies with agents as
                            │ first-class identities, just-in-time role
                            │ vending, and zero standing privileges (March
                            │ 2026)
                            │
Behavioural baselines       │ Early — MS Agent Governance Toolkit includes
                            │ trust scoring (0-1000 scale); no standard for
                            │ agent behavioural anomaly detection at scale
                            │
Audit trail                 │ Per-layer — query logs, tool call logs,
                            │ inference logs exist separately; MS toolkit
                            │ produces signed attestations per deployment;
                            │ unified cross-layer audit with full attribute
                            │ context is rare
                            │
Unified policy engine       │ Emerging — MI9 research framework proposes
                            │ integrated runtime governance; Proofpoint
                            │ markets unified AI security platform; Cedar
                            │ (AWS), OPA (CNCF) are general-purpose engines;
                            │ no standard agent attribute schema across
                            │ vendors yet
                            │

Sources: AWS Bedrock AgentCore Policy (Cedar, GA March 2026), Microsoft Agent Governance Toolkit, Ping Identity Runtime Identity Standard, Cisco Agentic Workforce Security (RSA 2026), Proofpoint Intent by Design, Token Security Intent-Based Controls, Immuta Agentic Data Access, CSA Agent Delegation Chain Security, Okta for AI Agents, Auth0 FGA + Delegation Chains, MI9 Runtime Governance Framework (arXiv), OPA ABAC.

The industry is moving fast — AWS shipped tool-level policy enforcement (Cedar), Okta/Auth0 are shipping agent identity with delegation chain tracking and scope attenuation, Cisco announced MCP gateway enforcement at RSA 2026, Proofpoint is productizing intent-based agent security, and Immuta is shipping ABAC with agents as first-class identities across data platforms. The gap isn’t that nobody is working on this. The gap is that these efforts are siloed: tool authorization (Cedar/Cisco), agent identity and delegation (Okta/Auth0/Ping), intent classification (Proofpoint), data access (Immuta), and audit (per-layer) don’t evaluate as a unified policy. The connective tissue between them is what’s missing.

What’s Emerging — And What’s Still Missing

#

The industry is moving faster than it might appear. Several capabilities I initially assumed didn’t exist are actually shipping or in advanced development as of March 2026:

Intent classification as a security input — emerging. Proofpoint’s “Intent by Design” framework does exactly this: continuously evaluating whether AI behaviour aligns with the original request and enterprise policy. They define five pillars — Intent Alignment, Identity and Attribution, Behavioral Consistency, Auditability, and Operational Transparency. Token Security is also shipping intent-based controls for agent authorization. This is no longer theoretical — it’s productized.

Chain depth and delegation tracking — emerging. The Cloud Security Alliance published a framework for securing agent delegation chains, requiring scope attenuation at every hop, token-level lineage verification, persistent context alignment, and human approval for sensitive actions. Under the EU AI Act Article 14, traceability of delegation chains is a legal obligation for high-risk systems. The CSA framework is a reference architecture, not a product — but the requirements are defined.

MCP-level policy enforcement — production. Cisco announced MCP policy enforcement in Secure Access (RSA Conference 2026), routing all agent tool traffic through an MCP gateway with fine-grained permissions scoped to specific tasks and short durations. Agent identity management in Cisco Duo IAM maps agents to accountable human owners. This is the MCP security layer I described in the architecture — Cisco is shipping it.

Agent behavioural baselines — early. Microsoft’s Agent Governance Toolkit includes trust scoring on a 0-1000 scale and deterministic policy evaluation at sub-millisecond latency. This is a building block for behavioural anomaly detection, though production-scale behavioural baselines for agent sessions (what’s “normal” for a reporting agent vs. an analytics agent) remain an open problem.

ABAC for agent data access — production. Immuta announced agentic data access capabilities (March 2026) that treat AI agents as first-class identities with their own attributes, intent, and audit trail. The technical architecture is worth understanding because it shows how ABAC can work without being a proxy:

  Agent ──► Immuta API: "I need table X,
  │         acting for user Y, purpose Z"
  │                    │
  │         Immuta evaluates ABAC policies
  │         (who + what + why)
  │                    │
  │         Creates ephemeral role in
  │         Snowflake/Databricks/BigQuery
  │         with only the needed permissions
  │                    │
  │         ◄──────────┘ role credentials
  │
  ├──► Queries data platform directly
  │    (native row access + masking
  │     policies enforced by the platform)
  │
  └──► Task completes → role auto-revoked

Immuta is a control plane, not a data plane — it manages native platform policies (Snowflake row access policies, column masking policies) and vends ephemeral roles, but queries flow directly to the data platform. The agent still needs its own authentication credential to connect — Immuta handles the authorization scope, not the authentication.

Agent identity and delegation chains — production. Okta for AI Agents (GA April 30, 2026) treats every agent as a non-human identity in the Okta Universal Directory with automated access reviews, human owner assignment, and audit trails. More significantly, Auth0 Fine-Grained Authorization (FGA) — built on Google’s Zanzibar model — implements delegation chain tracking with scope attenuation at every hop. Agents use OAuth 2.0 Token Exchange (RFC 8693) to convert session tokens into short-lived, scoped credentials, progressively narrowing permissions at each delegation step. The Auth0 Token Vault solves the confused deputy problem by requiring cryptographic proof of the user session. Cross-App Access (XAA) tracks and revokes delegation lineage — and is now part of MCP under “Enterprise-Managed Authorization.” This is the chain depth and scope attenuation pattern implemented in production.

What’s still maturing:

Cross-layer unified policy evaluation. The products above each cover a layer: Proofpoint (intent), Cisco (MCP/network), AWS Cedar (tool authorization), Immuta (data access). Research is pointing toward unification — the MI9 framework proposes an integrated runtime governance architecture with telemetry capture, authorization monitoring, conformance checking, drift detection, and containment across agent frameworks. Proofpoint markets a “unified AI security platform” enforcing policy across employee AI usage, agent actions, and MCP connections. But in practice, most enterprises are still stitching together separate products at each layer. The fully integrated evaluation — where one policy engine sees tool call attributes, data classification, inference routing, and behavioural context simultaneously — is emerging in research and early products but not yet standard in enterprise deployments.

Open standards for agent attributes in access control. Cedar, OPA/Rego, and XACML can all express rich attribute policies. But there’s no interoperable standard schema for agent attributes (agent_type, chain_depth, purpose, trust_score) across vendors. Each vendor defines their own attribute model — Proofpoint’s five pillars, Microsoft’s trust scoring, Cisco’s IAM registration, Immuta’s purpose-based policies. Until there’s a shared schema — the way OAuth standardized identity claims — enterprises will need to map between incompatible attribute models at every integration point.

The Enterprise Architecture — Centralized Policy, Federated Enforcement

#

ABAC for agents can’t be a point solution bolted onto one tool. It needs to be an enterprise-wide architecture where compliance and legal requirements are translated into technical policies centrally, but enforcement happens at every data and AI touchpoint — federated to domain owners where appropriate, mandatory where necessary.

  ┌─────────────────────────────────────────────────────────────────────┐
  │                 CENTER OF EXCELLENCE                                │
  │                                                                     │
  │  Compliance & Legal ──► Policy Translation ──► Technical Policies   │
  │  (GDPR, DORA, EU AI     (human-readable       (machine-evaluable   │
  │   Act, NIS2, ITAR,       rules & controls)      ABAC policies)     │
  │   industry-specific)                                                │
  │                                                                     │
  │  ┌─────────────────────────────────────────────────────────────┐    │
  │  │              Central Policy Registry                        │    │
  │  │                                                             │    │
  │  │  Global policies (mandatory, non-overridable)               │    │
  │  │  Domain templates (customizable by domain owners)           │    │
  │  │  Classification rules (PII, financial, regulated, public)   │    │
  │  │  Agent trust levels (trusted, sandboxed, external, unknown) │    │
  │  │  Purpose taxonomy (analytics, reporting, export, training)  │    │
  │  └─────────────────────────────────────────────────────────────┘    │
  └──────────────────────────────┬──────────────────────────────────────┘
                                 │ policies pushed / pulled
                                 ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │              FEDERATED ENFORCEMENT POINTS                           │
  │                                                                     │
  │  Each domain has its own PEP that evaluates the central policies    │
  │  Domain owners can add domain-specific rules within guardrails     │
  │                                                                     │
  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐  │
  │  │  Data        │  │  AI / LLM    │  │  Agent / MCP             │  │
  │  │  Platform    │  │  Inference   │  │  Tool Calls              │  │
  │  │              │  │              │  │                          │  │
  │  │  PEP: query  │  │  PEP: model  │  │  PEP: tool invocation   │  │
  │  │  access,     │  │  routing,    │  │  authorization,         │  │
  │  │  masking,    │  │  data flow   │  │  chain depth,           │  │
  │  │  row access  │  │  control,    │  │  purpose validation,    │  │
  │  │              │  │  sovereignty │  │  behavioural checks     │  │
  │  │  Domain:     │  │              │  │                          │  │
  │  │  data eng    │  │  Domain:     │  │  Domain: platform eng   │  │
  │  │  team        │  │  AI/ML team  │  │  + app teams            │  │
  │  └──────┬───────┘  └──────┬───────┘  └────────────┬─────────────┘  │
  │         │                 │                        │                │
  │  ┌──────┴───────┐  ┌──────┴───────┐  ┌────────────┴─────────────┐  │
  │  │  API         │  │  External    │  │  SaaS / Third-Party      │  │
  │  │  Gateway     │  │  Services    │  │  Integrations            │  │
  │  │              │  │              │  │                          │  │
  │  │  PEP: rate   │  │  PEP: data   │  │  PEP: scope,            │  │
  │  │  limiting,   │  │  residency,  │  │  data minimization,     │  │
  │  │  auth,       │  │  contract    │  │  consent validation     │  │
  │  │  scope       │  │  compliance  │  │                          │  │
  │  └──────┬───────┘  └──────┬───────┘  └────────────┬─────────────┘  │
  └─────────┼─────────────────┼───────────────────────┼────────────────┘
            │                 │                       │
            └─────────────────┼───────────────────────┘
                              ▼
  ┌─────────────────────────────────────────────────────────────────────┐
  │              CENTRALIZED AUDIT & INCIDENT RESPONSE                  │
  │                                                                     │
  │  ┌─────────────┐  ┌──────────────┐  ┌───────────────────────────┐  │
  │  │  Audit Log  │  │  Anomaly     │  │  Incident Management      │  │
  │  │             │  │  Detection   │  │                           │  │
  │  │  Every PEP  │  │  Cross-PEP   │  │  Triage: severity,       │  │
  │  │  decision   │  │  correlation │  │  affected data classes,   │  │
  │  │  with full  │  │  Behavioural │  │  regulatory implications  │  │
  │  │  attribute  │  │  baselines   │  │                           │  │
  │  │  context    │  │  Drift       │  │  Response: revoke tokens, │  │
  │  │             │  │  detection   │  │  quarantine agents,       │  │
  │  │             │  │              │  │  notify DPO, file report  │  │
  │  └─────────────┘  └──────────────┘  └───────────────────────────┘  │
  └─────────────────────────────────────────────────────────────────────┘

How This Works in Practice

#

The Center of Excellence is where compliance officers and legal translate regulatory requirements into policy. “GDPR Article 17 requires deletion on request” becomes a technical policy: deny tool=export if data.classification=PII AND NOT request.legal_basis IN ['consent', 'contract', 'legitimate_interest']. These policies are versioned, reviewed, and published to a central registry.

Domain owners operate their own enforcement points but within guardrails set by the center. A data engineering team can define domain-specific masking rules for their pipelines — which columns to mask for which purposes — but they can’t override the global policy that PII never flows to external models without consent. The architecture enforces this by layering: global policies are non-overridable, domain policies extend but cannot weaken them.

Federated PEPs evaluate policies locally at each touchpoint — data platforms, AI inference services, MCP/agent tool calls, API gateways, external service integrations. Each PEP pulls the latest policies from the central registry and evaluates them against the request’s attributes. The decision (allow/deny/transform) and the full attribute context are sent to the centralized audit log.

Centralized audit and incident response correlates events across all PEPs. An agent that makes normal queries through the data PEP but simultaneously exfiltrates via an external service PEP — that pattern is only visible when you correlate across enforcement points. Anomaly detection runs on the combined stream, not on each PEP in isolation.

The Governance Model

#

The key principle: domain owners manage their enforcement points, but the policies they enforce are constrained by the center. A domain owner can grant access to a tool — but only if the center’s global policies permit it for that data classification, agent type, and purpose. This prevents the classic problem of federated security: inconsistent enforcement across teams.

Why This Matters Now

#

The EU AI Act Article 9 requires “high-risk” AI systems to have governance controls that go beyond what RBAC provides. DORA requires financial institutions to demonstrate that automated systems operate within defined bounds. Neither framework is satisfied by “the agent has a role that can access the table.”

The regulatory question is shifting from “who has access” to “what is the AI system doing with the access it has, and is that consistent with its stated purpose?” That’s an ABAC question. It requires purpose, context, and behavioural attributes — not just identity and role.

The interesting product surface here is lifting the policy engine from the data layer up to the agent layer. Not just “can this user see this column” but “can this agent invoke this tool on this data for this purpose.”

Back to the support agent scenario: the exfiltration chain would have been stopped at the second tool call. Not because the role lacked permission, but because the purpose shifted, the chain depth exceeded policy, and PII was being routed to an external endpoint. Three attributes, one deny decision, zero data leaked.

That’s the difference between access control that checks identity and access control that understands intent. The individual pieces are shipping — Cedar for tool authorization, Okta/Auth0 for agent identity and delegation chains, Proofpoint and Token Security for intent, Cisco for MCP enforcement, Immuta for data access governance. The question now is whether these converge into a unified evaluation layer with a shared attribute schema, or whether enterprises spend the next few years stitching them together manually.

Related

#

• Containing AI Agents in Production
• SMCP: Adding Security to the Model Context Protocol
• Governing AI Inference in the Data Cloud
• A Layered Architecture for Python and Conda Supply Chain Security