Who Wins When an Agent Is Allowed and Forbidden at the Same Time?

An agent proposes to release a payment. Finance policy permits it because the amount is within the delegated budget. Security policy denies it because the destination account is new. Legal policy permits it for a signed supplier contract. Data-governance policy cannot decide because a required risk attribute is missing.

The hard question is not whether the runtime can evaluate these policies. It is who decides what their combined result means. If the runtime answers that question through an undocumented engine default, then a consequential organizational decision is being made by an implementation detail rather than by organizational governance.

A governed agent runtime needs metapolicy: executable rules about policies. NIST SP 800-162 defines metapolicy as policy about policies, including priority assignment and the resolution of conflicts between digital policies or other metapolicies. That is the missing layer when several legitimate authorities govern the same action.

A policy result is not yet a decision

Security, legal, finance, operations and data governance do not merely write conditions into one shared rulebook. They hold different mandates, own different evidence and tolerate different failure modes. A finance control may focus on budget authority; a security control on account trust; a legal control on contractual basis. Their conclusions can diverge without any author being wrong.

The runtime should therefore preserve a distinction between an individual policy result and the final enforceable decision. At minimum, it should model outcomes such as Permit, Deny, NotApplicable, Indeterminate and Conflict. NotApplicable is not a denial: it says a policy does not govern this request. Indeterminate is not a denial either: it says that a policy which may matter could not be evaluated reliably, perhaps because an attribute is absent. Conflict says the applicable results cannot be composed under the selected rule.

Flattening those states too early makes governance less visible. Treating a missing sanctions-screening result as an ordinary denial may be operationally prudent for one payment flow, but it conceals a data-quality failure that needs repair. Treating it as permission because another policy permits the transfer would be a different, and much riskier, choice. Neither outcome should be accidental.

Policy engines already prove that combination is a design choice

There is no universal precedence rule embedded in the idea of authorization. XACML 3.0 specifies multiple policy-combining algorithms, including deny-overrides, permit-overrides, first-applicable, only-one-applicable, ordered variants, deny-unless-permit and permit-unless-deny. The existence of this set is instructive: different combinations encode different operational assumptions.

Cedar chooses a particular model. Authorization defaults to deny; a satisfied forbid policy overrides a satisfied permit policy; and policies producing evaluation errors are skipped. Those are clear, deterministic semantics, but they are not neutral semantics. An organization using Cedar still has to decide whether its authorities, scopes and treatment of missing evidence fit that model for each consequential action.

Open Policy Agent provides a useful contrast. It can report an evaluation conflict when a complete Rego rule produces multiple outputs. Here inconsistency may be surfaced as an error rather than automatically translated into permit or deny. Again, the lesson is not to select a universal engine. It is to make the organization’s response to inconsistency explicit at the enforcement boundary.

“A policy engine evaluates rules. A metapolicy makes the organization’s rule-resolution authority executable.

Scope authorities before assigning precedence

A priority number alone is not metapolicy. Equal priorities still need a rule. So do scoped exceptions, overlapping jurisdictions, missing attributes and indeterminate evaluations. “Security wins” is also incomplete unless it identifies which security authority, for which action class, over which other authority, and what happens when the security policy cannot evaluate.

Start with authority-scoped policy sets. Assign each policy to a named authority with a defined remit: for example, payment risk, delegated spend, contractual eligibility or information handling. Isolated policy collections and namespaces can help prevent naming ambiguity and establish technical boundaries, but they do not establish organizational precedence on their own. That relationship belongs in metapolicy.

Then choose combining strategies by action class, not by platform habit. A low-risk internal lookup might reasonably use a simple allow path. A payment to a new counterparty may require all designated authorities to return Permit, while any Deny blocks execution and any Indeterminate creates a review case. A customer-data export may need a different composition because its governing authorities and evidence requirements differ.

The point is not that deny-overrides is always safest or legally correct. It is that the decision model must state its assumptions. Which authority can block? Which can grant? Is a missing attribute a block, a conflict or a request for enrichment? Can an exception supersede a general restriction, and under what evidence? These are operating rules, not syntax choices.

Make resolution observable and testable

For every consequential action, persist a decision record that an accountable reviewer can reconstruct. Record the action and relevant input attributes; the applicable policies and their versions; each individual result; the combining algorithm and metapolicy version; the final decision; and any escalation or human disposition. A final “denied” event without this structure cannot explain whether the cause was a hard restriction, missing information, a policy error or an unresolved conflict.

This record matters operationally as much as it matters for audit. Teams need to see where conflicts cluster: a newly launched supplier class, a stale risk feed, two authorities with overlapping scope, or an exception that quietly outgrew its intended boundary. Without individual results, the organization can only observe the final symptom.

Testing must also move beyond syntax. Schema validation before deployment is valuable because it catches structural and type problems. Amazon Verified Permissions, for example, can validate new or updated policies against a policy-store schema and reject invalid changes. But a valid schema cannot prove that independently authored business policies are mutually consistent or produce the intended outcome.

• Run conflict tests with deliberately opposing applicable policies for each consequential action class.
• Run mutation tests: alter a permit, deny, scope, priority or required attribute and verify that the expected decision and explanation change.
• Use shadow evaluation for proposed policy changes against representative requests before changing enforcement.
• Test missing, stale and malformed attributes explicitly; do not leave their treatment to integration behavior.
• Route unresolved Conflict or action-defined Indeterminate outcomes to an accountable human role, with the evidence needed to decide.

Escalation is part of the decision system

Some conflicts should not be mechanically resolved. An agent that receives a valid financial permit and a valid legal denial should not invent a compromise. A runtime may block immediately for certain action classes, but it should still produce a case for the designated owner when the conflict reflects a governance question rather than a routine rejection.

The exception path needs an accountable human role, not a generic queue. That role should be able to see the policy authorities, versions, inputs and individual results, then issue a bounded disposition. The disposition should identify its scope and expiry rather than becoming an invisible permanent override. This keeps human judgment where it belongs: at unresolved organizational boundaries, not as a hidden substitute for ordinary policy design.

The architectural consequence

Autonomous organizations will accumulate policy authors faster than they accumulate a single shared view of authority. That is normal. The mistake is expecting a policy language, a priority field or a default-deny setting to settle the resulting constitutional question.

Build the resolution layer deliberately. Define authorities and their scopes. Type the outcomes that matter. Select a combining strategy per action class. Validate structure, then test semantic conflicts and proposed changes. Preserve the complete decision path. Escalate what remains indeterminate to someone accountable.

An agent may be permitted and forbidden at the same time. A mature runtime does not hide that fact. It turns the conflict into an explicit, reviewable organizational decision before any external effect occurs.

Sources

• NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-162.pdf
• NIST glossary, Policy Decision Point: https://csrc.nist.gov/glossary/term/policy_decision_point
• OASIS, XACML 3.0 Core Specification: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cos01-en.html
• Cedar authorization model: https://docs.cedarpolicy.com/auth/authorization.html
• Open Policy Agent evaluation conflict error: https://www.openpolicyagent.org/docs/errors/eval-conflict-error/complete-rules-must-not-produce-multiple-outputs
• Amazon Verified Permissions policy validation: https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-validation-mode.html