The Governance Object Has a Shape

On Monday, July 13, 2026, at the IEEE Symposium on Agentic Services held with IEEE ICWS 2026 in Sydney, four researchers from the University of Maryland, Baltimore County published Deontic Policies for Runtime Governance of Agentic AI Systems. The authors are Anupam Joshi, Tim Finin, Karuna Pande Joshi, and Lalana Kagal. Their claim is short and unusually precise: the policy engines currently deployed in production, meaning XACML, Rego, and Cedar, address only the permit and prohibit subset of enterprise governance. The wider governance object, the one an autonomous agent that invokes tools and coordinates with peer agents actually needs, has a different shape.

Six days earlier, on July 8, Yujiao Chen's Institutional Red-Teaming paper argued that in multi-agent deployments the safety-relevant object is the rule, not the model. This week's paper is the natural next question. If the rule is the safety object, what is a rule? What structure does an enterprise rule actually have, once it has to reach an autonomous agent, and what runtime layer is supposed to interpret it?

What the current engines can say

XACML, Rego, and Cedar are all what the authors call permit/prohibit engines. They evaluate a request against a policy and return an allow or deny decision, sometimes with obligations attached as advisory metadata that the enforcement point is free to ignore. Their expressive core, in practice, is boolean.

That expressive core was designed for a world in which the actor was a human or a service account calling an API. In that world the difficult governance question is whether this identity may perform this action on this resource under these conditions. Permit or prohibit is enough.

An autonomous agent invokes tools, manipulates data, installs software, and coordinates with peer agents across organizational boundaries. The governance question is no longer only whether the action is allowed. It is also what the agent is obliged to do after certain actions, under what conditions a standing obligation may be waived, and which rules take precedence when policies conflict. The paper's abstract enumerates these as obligation lifecycle management, meta-policy conflict resolution, dispensations from policies in specific circumstances, and ontological reasoning over domain class hierarchies. It notes, in one line, that current production engines do not provide them.

What a deontic layer adds

The paper proposes AgenticRei, a runtime layer built on the Rei policy language that Kagal, Finin, and Joshi have developed since 2002. Rei is a policy language expressed in the OWL ontology framework and grounded in classical deontic logic, meaning the modalities of permission, prohibition, obligation, and dispensation. Its Rein successor, developed by Kagal with Tim Berners-Lee at MIT, extended the framework across decentralized policy networks on the Semantic Web.

Twenty-four years later the same primitives return, this time as a runtime layer for agentic AI.

AgenticRei sits outside the language model. Both tool-call interception and agent-to-agent message interception share the same PolicyEngine, AuditLogger, and ObligationManager. The logic engine evaluates deontic statements about what an agent may do, must do, may be excused from doing, and what constraints apply when two policies collide. The paper offers one small worked example. An agent may be obliged to notify the Chief Information Security Officer after certain classes of action. A standing obligation may be waived, under specified circumstances, as a dispensation. Two policies may conflict, and the meta-policy specifies which one wins.

None of this is expressible in a permit/prohibit engine without contortion. The engine is not the wrong tool because it does not scale. It is the wrong tool because its logic does not describe the object.

What this changes about the argument

The immediate consequence is that the choice of runtime governance layer stops being an implementation detail and becomes a governance decision about the governance object itself. If the substrate for enforcement is a permit/prohibit engine, obligations, dispensations, and conflict resolution can be described in policy documentation, but they cannot be enforced by the engine that is actually deciding, in the milliseconds after a tool call is proposed, whether the agent proceeds. The distance between the written rule and the enforced rule collapses into whatever the engine can encode.

There is a second consequence for the standardization landscape. The paper notes that its approach naturally complements industry frameworks like A2AS, the emerging agent-to-agent security and certification framework. A2AS defines what an agent must present at the boundary; a deontic layer defines what the agent is authorized, obliged, or excused from doing once inside. The two describe different halves of the same enforcement surface, and neither describes the model.

What the paper does not resolve

The paper is a proposal, not a settlement. It shows through examples that deontic policies can capture governance constraints on security and privacy that cannot be expressed in current production engines. It does not, in its published form, resolve the questions that any deployment of such a layer would immediately raise.

• Where does the authoritative deontic policy for a given agent, tool, and message pair originate, and who is empowered to change it during operation?
• If the engine sits outside the language model and intercepts tool calls and agent-to-agent messages, what is the accountability posture when the engine and the language model disagree, and which of the two produces the artifact of record?
• If an obligation lifecycle is now a first-class runtime object, what is the audit surface across obligation creation, obligation discharge, obligation waiver, and obligation timeout, and who supervises that surface?
• If enforcement of deontic policies is the new governance object, what does the deployed operating environment produce as evidence that the policies in the ontology were the policies actually applied at runtime?

The governance artifact is retained. The governance function is not.