Wiki · Concept · Last reviewed June 25, 2026

XACML 3.0

XACML 3.0 is the OASIS standard for expressing attribute-based access-control policy, authorization requests, authorization responses, and a processing model for policy decision points.

Category: Concept Updated: June 25, 2026 Tags: XACML, authorization, ABAC, PDP, PEP, policy-as-code, AI agents

Definition

eXtensible Access Control Markup Language Version 3.0, usually called XACML 3.0, is an OASIS Standard approved on January 23, 2013. The cited core specification was edited by Erik Rissanen and dated January 22, 2013. It defines an XML policy language and an XML request/response language for access-control decisions.

XACML is closely associated with attribute-based access control. NIST SP 800-162 defines ABAC as a logical access-control method where authorization is determined by evaluating attributes of the subject, object, requested operation, and sometimes environmental conditions against policy, rules, or relationships.

The practical point is separation. A Policy Enforcement Point, or PEP, intercepts the attempted action. A Policy Decision Point, or PDP, evaluates policy. A Policy Information Point supplies attributes. A Policy Administration Point manages policies. XACML gives those roles a common vocabulary and processing model.

How It Works

A XACML request describes the access question in attributes. Those attributes can describe the subject, resource, action, environment, or deployment-specific categories. The PDP evaluates the request against policies, rules, targets, conditions, and combining algorithms.

The decision can be Permit, Deny, NotApplicable, or Indeterminate. A response can also include obligations and advice. Obligations are operations the PEP is expected to carry out in conjunction with the decision; advice can supply non-mandatory guidance or explanation-like material.

XACML is not merely a list of roles. A policy can depend on attributes such as clearance, resource classification, time, purpose, tenant, location, device posture, project membership, or risk state. That expressiveness is useful, but it makes attribute quality and policy testing central governance problems.

Agent Context

AI agents turn ordinary authorization into repeated, high-speed decision work. A tool boundary may need to ask whether this user, acting through this agent, may read this record, modify this file, send this message, query this system, or trigger this workflow under the current context.

XACML is one way to model that question as policy rather than as prompt text. The agent may propose the action, but the PEP should still ask a PDP. The request should include the human principal, agent identity, requested action, resource, tenant, data classification, tool source, session state, and other attributes that the policy actually uses.

This is adjacent to AuthZEN Authorization API, Cedar Authorization Policy Language, and Open Policy Agent. XACML is an OASIS XML standard and processing model. AuthZEN is a modern authorization API. Cedar and Rego are different policy languages with different deployment assumptions.

Governance Risks

The first risk is stale or invented attributes. A PDP can only evaluate the facts it receives or retrieves. If an agent gateway sends a model-derived project label, guessed intent, or stale group membership as if it were authoritative, the decision may look formal while resting on weak evidence.

The second risk is policy opacity. XACML can express complex rule sets and combining behavior. Without test cases, explanations, and policy versioning, a permit or deny answer can become difficult to challenge, especially when downstream users only see the final action.

The third risk is obligation theater. A policy response may say "permit if the PEP logs, redacts, warns, limits, or notifies." If the PEP does not reliably discharge those obligations, the PDP decision is not the implemented control.

Governance Pattern

Source Discipline

Use the OASIS XACML 3.0 standard page for status, approval date, and citation details. Use the OASIS core specification for the policy language, request/response model, architectural terms, decisions, obligations, advice, and processing rules. Use NIST SP 800-162 for ABAC terminology and organizational considerations.

Do not say that XACML makes an agent safe, compliant, or well governed by itself. It can express and evaluate access-control policy. It cannot prove user understanding, model reliability, data accuracy, downstream harmlessness, or institutional legitimacy.

Spiralist Reading

Spiralism reads XACML as a grammar for conditional authority. It asks the institution to stop saying "the system can do it" and instead name the subject, action, resource, context, policy, and consequence.

For agents, that grammar matters. A machine should not inherit a vague aura of permission from a logged-in user. It should meet a bounded rule at the moment of action, and the record should show why the gate opened or stayed closed.

Open Questions

Sources

Return to Wiki