Blog · arXiv Analysis · Last reviewed June 25, 2026

The Agent Rulebook Leaves the Prompt

The June 2026 arXiv paper Deontic Policies for Runtime Governance of Agentic AI Systems, by Anupam Joshi, Tim Finin, Karuna Pande Joshi, and Lalana Kagal, argues that agent governance cannot stop at authentication, access control, or prompt-level instructions. A tool-using agent needs a runtime rule system that can say what is permitted, what is prohibited, what obligations follow from an action, when an obligation is waived, and which rule wins when policies conflict.

An agent rulebook is the external policy layer that turns a proposed action into a structured decision: subject, action, resource, credential, domain class, matched rule, priority, obligation, exception, and audit record. It is not a prompt, a model preference, or a safety slogan.

The Prompt Is Not the Policy Engine

A prompt can tell an agent to obey policy, but it is not itself a policy engine. It lives inside the same model context as the user's request, retrieved documents, tool descriptions, conversation history, memory, and other agent messages. That makes prompt-level governance easy to state and hard to enforce. The agent may summarize the rule correctly while still making a tool call that violates the institution's actual control structure.

The Joshi, Finin, Joshi, and Kagal paper makes the boundary sharper. An agent that invokes tools, manipulates data, installs software, and coordinates with peer agents across organizational boundaries needs runtime governance. The authors argue that current policy engines such as XACML, Rego, and Cedar mostly cover permit and prohibit decisions. Enterprise governance also needs obligations, dispensations, conflict resolution, and reasoning over domain classes such as healthcare, cybersecurity, or privacy concepts.

The important distinction is source authority. A user instruction, a retrieved document, a tool result, a model-generated plan, and an institutional policy are different kinds of text. If all of them enter one prompt as undifferentiated language, the system has already lost the legal and operational boundary. The policy layer has to know which facts came from the user, which came from trusted credentials, which came from the tool schema, which came from a policy knowledge base, and which were merely inferred by the model.

This is related to the site's pages on intent-governed tool authorization, mechanical governance gates, policy compilers, and the agent-to-agent protocol handshake. The difference is the rule form. This paper asks what a machine-readable governance language must express when the agent is already at the action boundary.

Current Context

For this June 25, 2026 review, the paper sits inside a wider shift from model-only safety to runtime agent governance. NIST's AI Agent Standards Initiative says agent systems capable of autonomous actions need industry-led standards, community-led protocols, agent authentication, identity infrastructure, and security evaluations. NIST's NCCoE concept paper on software and AI agent identity and authorization likewise treats enterprise agents as actors that need identity and authorization patterns, not only chatbot instructions.

The allied Careful Adoption of Agentic AI Services guidance published through CISA and partner agencies makes the same operational point from a security angle: agentic systems should be introduced with strict privilege controls, monitoring, human oversight, risk ownership, and the ability to contain or roll back autonomy when risk changes. That is close to the institutional problem AgenticRei targets, even though the paper is about a particular deontic policy architecture rather than a national cybersecurity baseline.

The Model Context Protocol shows why this is not abstract. The 2025-11-25 MCP authorization specification requires resource indicators in authorization and token requests, token audience validation by MCP servers, and no token passthrough. MCP security guidance calls out confused-deputy risks, scope minimization, local server risk, and audit clarity. Those requirements do not implement AgenticRei, but they make the same premise visible: tool-using agents need policy outside the model's prose.

Regulation adds a narrower but important signal. EU AI Act Article 12 requires high-risk AI systems to support automatic event logging for traceability, risk identification, post-market monitoring, and operational monitoring. Article 14 requires human oversight measures proportionate to risk, autonomy, and context of use. Those provisions do not certify AgenticRei and they do not apply to every agent. They do show why consequential agent systems need records and intervention paths that survive after the prompt is gone.

What AgenticRei Adds

The paper, arXiv:2606.19464, was submitted on June 17, 2026 and is listed under Artificial Intelligence and Multiagent Systems. It proposes AgenticRei, a runtime governance approach built on the Rei deontic policy framework. The policies are expressed in OWL, the Web Ontology Language, and evaluated by a logic engine outside the LLM. The same pipeline governs both agent tool invocations and agent-to-agent messages.

The paper's architecture has a clear contract. A middleware layer intercepts an outbound action, whether a tool call or an A2A message, and extracts a subject, action, and resource triple from the structured invocation. A policy engine evaluates the triple against Rei-encoded rules and domain ontologies. The middleware then permits the action, prohibits it, or applies default-deny, and may return attached obligations for the agent to satisfy.

That extraction detail matters. AgenticRei is not trying to make a free-form paragraph legally binding by asking a model to be more careful. It assumes the action has already become a typed invocation: tool name, argument schema, resource, actor, and credential facts. The policy layer can then reason over an object the institution can audit, not over a private chain of thought or a chat transcript.

The authors state that the prototype implements permission, prohibition, obligation, dispensation, and meta-policy priority resolution over the Rei ontology, with subclass reasoning supplied by RDFox's OWL/RDFS entailment. They also report that credential verification is simulated through trusted-issuer matching in the prototype, while integration with production agent runtimes and cryptographic credential verification remains ongoing work. That limitation matters: the paper is a governance architecture and prototype, not a claim that enterprise deployment is already solved.

Why Obligations Matter

Allow and deny are too small for many institutional duties. A system may be allowed to install software only if it notifies a security officer. A clinical agent may be allowed to read a record only if the access is logged and justified. A financial agent may be allowed to export a report only if the export is tied to a credential issued by the right authority. The policy question is not only whether the action may occur. It is what must happen because the action occurred.

That is why the paper's treatment of obligations and dispensations is important. An obligation records a duty attached to a permitted action. A dispensation releases the actor from that duty under specified circumstances. Meta-policies decide which rule takes precedence when an organizational prohibition, project permission, and regulatory exception collide. Ontological reasoning lets the rule apply to a category, so a policy written for regulated data can cover future subclasses without rewriting every attribute list.

For agent governance, this changes the audit question. A log that says a tool call was allowed is incomplete. Reviewers need to know which policy version was loaded, which rule matched, which credentials were presented, which obligation was created, whether it was discharged, and which conflict-resolution rule resolved the decision.

Claim Boundary

AgenticRei is strongest as a statement about where policy should live and what the policy language must express. It is not a full safety case for a deployed agent platform. It governs actions that can be represented as structured triples and matched against loaded policy and ontology sources. If the action extractor misses the resource, misclassifies the action, trusts the wrong issuer, or receives a malformed tool schema, the rule engine can be precise while the surrounding system is still wrong.

It also does not solve obligation follow-through by returning obligation text once. A production obligation needs lifecycle state: created, assigned, due, discharged, overdue, waived, escalated, or revoked. The obligation manager has to know when the post-action duty was actually satisfied and must preserve that result in the audit trail. Otherwise obligations become another kind of policy decoration.

Ontologies and priorities also encode institutional choices. A class hierarchy can be incomplete, a new data class can arrive before the ontology is updated, and a priority rule can hide a bad institutional preference behind a clean formal structure. The governance gain is not that formal policy becomes automatically right. The gain is that policy decisions become inspectable, testable, versioned, and separable from the model's fluent explanation.

Governance Standard

A serious agent platform should keep governance decisions outside the model loop. The LLM can propose, explain, and request. It should not be the final authority on whether a controlled action satisfies policy. Action-boundary middleware should extract structured facts, consult an external policy engine, default-deny on failure, and preserve a structured audit record.

The policy language should be richer than a tool allowlist. It should express permissions, prohibitions, obligations, dispensations, trusted credential issuers, domain classes, and rule priority. It should work for both tool calls and agent-to-agent messages, because an agent can cause harm by sending data or instructions to another agent even when no local shell command runs.

The paper's audit detail is especially useful. It describes structured decision records that include the matched rule, latency, credential issuers, and a hash of the loaded policy knowledge base. A stronger production version would also preserve enough staged request context to reproduce contested decisions. That is the bridge between AI audit trails and runtime enforcement.

What This Changes

The agent rulebook leaves the prompt when a rule becomes something the system enforces, not something the model is asked to remember. The shift is small in interface terms and large in institutional terms. Governance moves from advice to infrastructure.

The Spiralist rule is practical: if an agent can act, the institution needs a policy engine at the action boundary. Prompts can carry norms. Runtime policy decides authority. Audit records decide whether the institution can later prove what happened, under whose rule, and with which unresolved obligation still attached.

Source Discipline

Use the arXiv paper for AgenticRei's architecture, prototype scope, deontic constructs, middleware contract, OWL/RDFox details, audit-record claims, and stated limitations. Use W3C OWL materials only for the ontology-language context. Use OPA and Cedar documentation for what those policy systems claim about policy-as-code and authorization; do not treat the AgenticRei paper's comparison as proof that every production OPA or Cedar deployment has the same limits in practice.

Use NIST, CISA, MCP, and EU AI Act sources as current governance and security context, not as certification that AgenticRei satisfies any particular standard or legal duty. A paper, a standardization initiative, a protocol specification, a cybersecurity advisory, and a statute are different source types. A useful agent rulebook names which source supplies the rule, which component enforces it, which credential issuer it trusts, which version was loaded, and which evidence a later reviewer can inspect.

Sources

Return to Blog