MITIGATION · m-rbac-abac
RBAC and ABAC: role-based and attribute-based access control for agents
Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.
At a glance
TL;DR
- Assign every agent identity a named role at provisioning time. The role is the outer limit on what the agent can ever reach, evaluated by a policy decision point external to the agent.
- Layer ABAC conditions inside that role so individual tool calls are further constrained by request attributes: the user's approval limit, the resource's sensitivity classification, the time window, or the environment risk score.
- The policy decision is evaluated per request and is not subject to agent reasoning. An agent cannot argue or reason past a deny; RBAC and ABAC together are the structural foundation of least privilege for non-human identities.
- Without trustworthy attributes the ABAC layer degrades silently to RBAC. The attribute supply chain (where approval limits, sensitivity tags, and risk scores originate) is where most production deployments fail.
How it behaves
What it is
RBAC and ABAC are the two standard models for authorisation decisions. RBAC assigns every principal a named role; the role carries a fixed permission set; the decision is whether the principal holds a role that includes the requested permission. ABAC evaluates a policy expression at request time against attributes of the subject (identity, role), the resource (sensitivity, owner), the action (read, write, delete), and the environment (time, network zone, risk score). The two models are complementary: RBAC sets the coarse ceiling at provisioning time; ABAC narrows individual decisions inside that ceiling per invocation.
The agentic relevance is not that these models are new, but that agents are long-lived non-human identities that often accumulate far broader permissions than any single task requires. An agent provisioned with write access to a file store, a payment API, and an external webhook service does not need all three simultaneously for most tasks. If it is manipulated via prompt injection or its credentials are stolen, that full permission set is the attacker's gain. RBAC bounds the agent to the role appropriate for its function; ABAC conditions further constrain high-impact actions to the specific request attributes that justify them, for example: an agent in role expense-classifier may invoke approve_claim only when amount is within the user's approval limit and the request falls within business hours.
Delegated token exchange (RFC 8693) carries the original user's authority into agent-initiated downstream calls, so the agent never operates with broader authority than the user it acts on behalf of.
Detection signals
- Policy decision denials per agent identity. A rising rate indicates scope drift, a misconfigured role, or deliberate privilege escalation attempts.
- ABAC attribute mismatches at decision time (for example, request user-tier differs from the authenticated session user-tier). Repeated mismatches on the same agent identity indicate a poisoned or forged attribute supply.
Threats it covers
-
WHY IT HELPS Privilege Compromise occurs when an agent accumulates permissions beyond what any single task requires, giving an attacker a large blast surface if the agent is manipulated or its credentials are stolen. Binding each agent identity to a named role at provisioning time, and further constraining individual tool calls via ABAC conditions, keeps the permissions envelope at task scope rather than system scope.
-
WHY IT HELPS A network-exposed MCP server without per-client authorisation grants any reachable caller access to every tool it exposes. RBAC at the MCP server entry point ties every tool invocation to the caller's role, so network reachability alone does not confer access: a caller must also present a valid, authorised role.
-
WHY IT HELPS Overly broad MCP server permission scoping lets a single client accumulate the server's full permission set. RBAC/ABAC decisions evaluated per request ensure that each client receives only the subset its role permits: the server's aggregate permissions are never forwarded wholesale to any caller.
-
WHY IT HELPS Data residency violations occur when an agent in one jurisdiction reads or transfers data classified as belonging to another. ABAC conditions that encode jurisdictional attributes on both the requesting agent and the target resource enforce residency at the access-control layer, before any read or transfer takes place.
Principle coverage
Defence-in-Depth stage: Prevent — and it advances:
- Zero Trust Zero Trust assumes no identity is inherently trusted. RBAC and ABAC enforce that for agents by requiring an explicit, externally-evaluated allow decision on every request, so a standing agent identity grants nothing on its own.
- Least Privilege The named role is the coarse ceiling on what an agent can ever reach, and ABAC conditions trim it further per request, so the agent never holds more authority than the task in front of it requires.
- Complete Mediation Complete Mediation requires every access to be checked, not only the first. The policy decision point evaluates each tool call independently, so no request proceeds on a cached or prior approval.
Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.
Implementation options
Five verified options covering cloud-native IAM with condition keys, a multi-language open-source authorization library, a standalone Rego-based policy engine, a managed authorization platform, and a Zanzibar-style fine-grained authorization service. Most deployments start with the cloud IAM provider for agents running in that cloud and add a dedicated policy engine when ABAC conditions become complex enough to benefit from Rego or a central decision point.
AWS IAM with condition keys IAM roles provide the RBAC structure; condition keys and session tags add ABAC constraints evaluated by the AWS control plane on every API call. No separate policy engine is needed for AWS-native agent workloads.
Why choose it: Assign the agent a narrowly-scoped IAM role. Pass per-task ABAC attributes (for example, an approval limit) as session tags at AssumeRole time; condition keys in the policy then restrict high-impact actions based on those tags. Tag-based conditions scale to new resources without rewriting policies.
More details:
Apache Casbin Open-source authorization library with implementations in Go, Java, Node.js, Python, C#, Rust, and others. Supports RBAC with role hierarchies, ABAC via model configuration, and hybrid policies. Use when the agent runtime is not in a cloud where IAM handles policy natively, or when authorization logic needs to run in-process.
Why choose it: Authorization models are defined in a .conf file; policy rules load from files, databases, or custom adapters. RBAC role hierarchies and ABAC matchers are data, not code, so policy rules update without redeploying the agent. The Go and Node.js adapters are the most feature-complete.
More details:
OPA (Open Policy Agent) CNCF-graduated general-purpose policy engine. The agent sends a structured input (identity, tool name, parameters, user context) to an OPA sidecar; a Rego policy returns allow or deny in under 1 ms. Use when ABAC conditions are complex, or when a single policy corpus must cover tool calls, memory writes, and Kubernetes admission.
Why choose it: OPA decouples policy authoring from enforcement. The same Rego rules that gate agent tool calls can run in CI via Conftest to catch policy violations before deployment. Decision logs emit one structured record per query. Covered in depth in m-opa; recommended here as the policy engine for RBAC/ABAC when cloud IAM alone is insufficient.
More details:
Permit.io Managed authorization platform built on OPA and OPAL. Exposes RBAC, ABAC, and ReBAC (relationship-based) models via a hosted control plane. Policy Decision Points run in-VPC as containers at sub-millisecond latency; OPAL keeps them in sync with policy changes in real time. Use when self-managing OPA exceeds engineering capacity, or when policy authoring needs a non-engineer-facing interface.
Why choose it: The in-VPC PDP pattern keeps decisions inside your network. Policy authoring is done via UI or API. SOC 2 Type II, HIPAA, and GDPR certified. Choose over self-hosted OPA when authorization models span RBAC, ABAC, and relationship graphs and you want a managed control plane rather than self-hosting OPA, bundle servers, and log infrastructure.
More details:
OpenFGA (CNCF) CNCF authorization service based on Google's Zanzibar relationship model. Authorization decisions are relationship checks: does subject X have relation Y to object Z? Use when agent permissions are naturally expressed as object relationships rather than flat role assignments, for example ownership chains, delegation, or task-scoped access.
Why choose it: OpenFGA's tuple-based model composes RBAC patterns (user to role to permission) with contextual conditions. Best suited to deployments where resource ownership, delegation chains, and task-scoped permissions are the primary authorization complexity. Multiple language SDKs (Go, JS, Python, Java, .NET) and a CLI are available. Self-hosted only.
More details:
Trade-offs
- Policy evaluation latency is negligible at runtime: cloud IAM condition keys add nothing measurable, and OPA and Permit.io in-VPC PDPs return decisions in under 1 ms. The real cost is paid at policy authoring and maintenance, not at request time.
- ABAC scales without rewriting policies as new resources are added, but it front-loads engineering: every attribute the policy depends on (resource sensitivity, user approval limit, environment risk score) must be available and trustworthy at decision time, which requires instrumentation across the stack.
- The more attributes an ABAC policy depends on, the larger the attack surface of the attribute supply chain. An attribute read from a poisoned vector store or an unvalidated session claim can flip a deny to an allow.
- Policy maintenance is the dominant long-term cost. Each new tool type or resource the agent can reach requires new rules, tested in CI and peer-reviewed, before the agent is permitted to use them.
When NOT to use
- Single-user, single-agent deployments where all actions run under the same identity and the blast radius of any compromise is bounded by that context. A simple allow-list of permitted tool names achieves the same effect with far less maintenance burden.
- When ABAC attributes cannot be sourced reliably. A policy built on untrustworthy or manipulable attributes provides false assurance, which is worse than no ABAC layer.
- As the primary control for data sensitivity. Knowing a role can invoke a tool does not determine whether the data the tool returns should be visible to the requesting user. Complement with row-level security or field masking for sensitive-data scenarios.
Limitations
- RBAC alone is too coarse for agent contexts where the same role legitimately needs different reach across different tasks. The confused-deputy problem requires ABAC conditions or time-bound privilege scoping to close.
- Both models are evaluated against declared parameters, not against whether those parameters were manipulated by adversarial input. A prompt-injected tool chain that supplies forged parameters passes the policy check. Pair with intent attestation to bind the decision to the user's stated intent.
- Policy correctness is not automatically verified. A misconfigured condition that evaluates to true for all requests is as dangerous as no policy at all. CI policy testing (Conftest or opa eval) and peer review are required for every policy change.
- Cloud IAM ABAC via session tags requires passing attributes at AssumeRole time. If those attribute values are sourced from the agent's own execution context (for example, a role value retrieved from a document), the tag-passing path becomes an injection vector.
Maturity tier reasoning
- Tier 2 fits because every component (AWS IAM condition keys, Casbin, OPA, Permit.io, OpenFGA) is production-available and documented. The combination is established engineering, not research.
- Not Tier 1, because the attribute supply chain for agentic ABAC is not standardised. No industry-canonical mechanism exists for sourcing trustworthy per-task attributes (user intent, derived risk score, freshness of authority) from agent execution context. The individual engines are mature, but their agentic application, where attributes must be derived from session context rather than from enterprise directories, is not.
- Not Tier 3, because the underlying components are in production use today across enterprise deployments and no novel engineering is required.
Last verified against upstream docs: 2026-05-30.