EVIDENCE TRAIL
RBAC and ABAC — role-based and attribute-based access control for agents
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The title "RBAC and ABAC" uses the NIST-standardised labels from SP 800-178 and SP 800-162; the strongest upstream verbatim match for the combined pattern in an agentic context is OWASP Threats & Mitigations v1.1 Playbook 4, which names "granular RBAC & ABAC" as the first proactive control for agent privilege management.
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
NIST SP 800-162 — Guide to Attribute Based Access Control (ABAC) Definition and Considerations
SP 800-162 — Abstract / Definition of ABAC
"a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes."
Supports: The canonical NIST definition of ABAC as the four-attribute model (subject, object, action, environment) on which this control is built. The per-request policy-evaluation mechanic described here is precisely what the MDX page recommends.
Does not prove: Does not address agentic AI, LLMs, or non-human principals. The standard was authored for enterprise user-access scenarios; the extension to agent identities is Helmwart's application, not NIST's.
NIST SP 800-207 — Zero Trust Architecture
NIST SP 800-207 §1 Introduction — operative definition of Zero Trust
"Zero trust (ZT) provides a collection of concepts and ideas designed to minimize uncertainty in enforcing accurate, least privilege per-request access decisions in information systems and services in the face of a network viewed as compromised."
Supports: Verbatim establishment of "least privilege per-request access decisions" as the foundation of ZTA — the design principle that RBAC + ABAC together operationalise for agent calls. The MDX cites §3.4 as the relevant section; the per-request least-privilege principle is in fact stated definitionally in §1 and carried through the document.
Does not prove: Section 3.4 of SP 800-207 covers network and environment components, not ABAC specifically. The MDX reference to "SP 800-207 §3.4 makes per-request attribute-based decisions the foundation of the ZTA control plane" misattributes the specific claim to §3.4. The principle is real and verbatim, but it appears in §1 (the ZT definition) and §2 (tenets), not §3.4 (Network/Environment Components). Helmwart should cite §1–2 instead.
OWASP Agentic AI — Threats & Mitigations v1.1
§T3 Privilege Compromise — Description
"Privilege Compromise occurs when attackers exploit mismanaged roles, overly permissive configurations, or dynamic permission inheritance to escalate privileges and misuse AI agents' access. Unlike traditional systems, AI agents autonomously inherit permissions, creating security blind spots where temporary or inherited privileges can be abused to execute unauthorized actions."
Supports: Names the exact threat that RBAC/ABAC is cited in the MDX to mitigate. The "mismanaged roles" and "dynamic permission inheritance" framing maps directly to what RBAC bounds and what ABAC narrows per-request.
Does not prove: T3's mitigation guidance says "implement granular permission controls, dynamic access validation" but does not name RBAC or ABAC by their NIST labels in the threat description. The RBAC/ABAC name-drop appears in Playbook 4, not the threat body itself.
OWASP Agentic AI — Threats & Mitigations v1.1
§Playbook 4: Strengthening Authentication, Identity & Privilege Controls — Step 1: Implement Secure AI Authentication Mechanisms (Proactive)
"Implement granular RBAC & ABAC to ensure AI only has permissions necessary for its role."
Supports: The only verbatim RBAC+ABAC name-drop in the OWASP Threats & Mitigations document. Establishes that both models together — not either alone — are the recommended proactive control for agent privilege management.
Does not prove: Appears as a single bullet in a checklist; no elaboration on implementation mechanics, attribute sourcing, or the RBAC-for-coarse-scoping / ABAC-for-per-request-constraints layering the MDX recommends.
OWASP Top 10 for Agentic Applications 2026
§ASI03 Identity and Privilege Abuse — Description
"Identity & Privilege Abuse exploits dynamic trust and delegation in agents to escalate access and bypass controls by manipulating delegation chains, role inheritance, control flows, and agent context … Without a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible."
Supports: Establishes the "attribution gap" that RBAC/ABAC directly closes: agents without governed identities and role bindings cannot have least privilege enforced. The MDX maps T3/ASI03 as the primary threat this control addresses.
Does not prove: ASI03's prevention guidelines name "task-scoped, time-bound permissions" and "centralized policy engine" rather than RBAC/ABAC by name. The RBAC/ABAC label comes from SP 800-162 and Playbook 4, not from the ASI03 body.
OWASP AI Exchange — General Controls
§1.3 Controls to limit the effects of unwanted behaviour — #LEAST MODEL PRIVILEGE
"Least model privilege: Minimize what a model can do (trigger actions or access data), to prevent harm in case the model is manipulated, or makes a mistake by itself."
Supports: Names least model privilege as a normative runtime control and lists permission/authorisation configuration as the primary mechanism, aligning with RBAC/ABAC as the implementation vehicle. Also explicitly warns against implementing authorisation inside GenAI instructions (prompt-level grants), reinforcing that policy-engine decisions — the RBAC/ABAC pattern — are required.
Does not prove: Does not name RBAC or ABAC by label. The AI Exchange control is a principle statement; NIST SP 800-162/178 provide the standards that operationalise it.
Red Hat — Zero Trust for Autonomous Agentic AI Systems: Building More Secure Foundations
§Delegated token exchange — mechanism description
"The identity provider (e.g Keycloak) validates Token A and issues Token B that: Is derived from Token A; Preserves the original subject (sub); Encodes the exchanging client as the actor (act claim), establishing explicit on-behalf-of semantics; Is scoped to the new audience and purpose; Is short-lived by policy."
Supports: Provides the delegated-token-exchange mechanism (RFC 8693 on-behalf-of semantics) that the MDX recommends alongside RBAC/ABAC to preserve user authority into agent-initiated calls. The "scoped to the new audience and purpose" language directly supports the ABAC contextual constraint pattern.
Does not prove: The article does not use RBAC or ABAC terminology explicitly. The contextual enforcement it describes is delivered through token scoping and delegated exchange rather than traditional RBAC/ABAC labels — the MDX's framing of the article as describing "scoped identity + contextual authorisation" (i.e. the RBAC/ABAC pillars) is an interpretive mapping, not a verbatim claim.