Teams maintaining or migrating a XACML deployment while adding agent workloads.
What to keep from an externalised authorization design, and what to replace.
The control gap
XACML defined the vocabulary everyone still uses: decision point, enforcement point, information point, administration point. That model was right and remains right. What did not survive was XML policy authoring, the attribute retrieval story, and the operational weight. Teams migrating usually keep the architecture and change everything else, and the risk is discarding the architecture along with the syntax.
What good looks like
Externalised authorization survives the migration, expressed in a language people will read, with attributes evaluated where they exist rather than retrieved from an information point on every request.
- Keep the separation of decision and enforcement. It is the durable idea and it is what makes agent control possible at all.
- Replace policy authoring with a language your reviewers can read without training.
- Stop retrieving attributes at decision time where the request already carries them, which removes most of the latency.
- Add outcomes beyond permit, deny, and indeterminate, because agent actions need an approval path.
A production workflow
- Inventory existing policies and classify them: still needed, obsolete, or duplicated elsewhere.
- Rewrite the surviving rules in the target language and diff decisions against the old engine on recorded traffic.
- Move enforcement closer to the action, particularly for agent tool calls where the arguments matter.
- Retire the old engine only after the decision diff is clean for a full traffic cycle.
Evidence to require
- A decision diff between old and new engines over recorded requests.
- The attribute sources each policy depended on, and which are no longer needed.
- Latency before and after, measured at the enforcement point rather than at the engine.
- Policies retired as obsolete, with the reason recorded.
Buyer checklist
- Which XACML policies still describe a rule anyone would defend today?
- How many attribute lookups happen per decision, and are they still necessary?
- Where is enforcement today, and is it before or after the effect it is meant to control?
- Does the replacement support an approval outcome, or only permit and deny?
Practical answers
Common implementation questions
Was XACML wrong?
The architecture was right and is still the standard mental model. The authoring format and the operational cost were what teams could not sustain, which is a different criticism from the design being mistaken.
What replaced it in practice?
No single thing. Policy-as-code engines, relationship-based systems, and cloud-native authorization services each took part of the territory, and AuthZEN is now standardising the request and response shape that XACML also tried to standardise.
Does agent authorization change the picture?
It reinforces the original architecture and raises the bar on latency and evidence. The decision has to be fast enough to sit in a tool call and detailed enough to reconstruct afterwards.