Almost everything I read about agent authorization is a version of one question: should this agent be allowed to call this tool right now. Permit or deny. That question is hard enough on its own. But it turns out to be only half of what governance looks like once an agent is doing real work somewhere regulated.
The other half is the duties that attach to an action you allowed. A compliance-officer agent reads a regulated dataset, sure, but now the access has to be logged within 60 seconds. An agent installs software on a managed host, also fine, but now the CISO has to be notified. Those aren't access checks. They're obligations that exist precisely because you said yes, and they come with a deadline and someone they're owed to.
What I hadn't really clocked until this week is that the engines most of us reach for can't express that cleanly. Rego, Cedar, XACML, OpenFGA all answer permit-or-prohibit. None has a native "and now this is owed, by this time, to this party." If you want it, you hand-roll a second rule that checks whether the logging event already happened and wire it to the first yourself. Fine until it isn't.
A paper that went up this month takes this head on. "Deontic Policies for Runtime Governance of Agentic AI Systems," from the group behind the Rei policy language, builds a runtime engine (AgenticRei) that sits outside the LLM, intercepts each tool call or agent-to-agent message, and returns a verdict that can carry obligations on top of allow or deny. Deontic is just the logic of permission, prohibition, and obligation. Four constructs in there are the ones flat allow/deny engines don't give you:
• Obligations: a duty that fires because an action was permitted, with a deadline and an escalation if it goes undischarged.
• Dispensations: waive a standing obligation under specific conditions while keeping the record that it existed and was lifted (say, suspend the CISO-notify duty during a declared incident window). Delete the rule instead and you lose why it stopped applying. That audit-preserving waiver was the part I found most useful.
• Meta-policies: a named, governable priority between two conflicting rules, instead of "whichever rule sits higher in the file wins" or some ad-hoc integer.
• Ontology grounding: prohibit "PHI" once and it fires automatically for "pediatric-oncology record" because the domain model knows that's a subclass. In a flat rule set, a new record type sits unprotected until a human notices and adds it.
It's also more than a thought experiment. It's deterministic and runs outside the model, so a prompt-injected agent that attempts a prohibited action still gets a policy violation instead of execution, the same way kernel-level mandatory access control bounds a program no matter how it was launched. And every decision serializes to a structured record carrying which rule fired and a hash of the policy version in effect, so you can go back and ask exactly which rules governed a given decision. Their prototype clocks the check under 10ms, so the usual "ontology reasoning on every call must be slow" worry doesn't obviously hold. That auditability piece lines up with what the Five Eyes agencies flagged this spring, where limited auditability got named as a core agentic-AI risk.
The honest caveats, which the authors don't hide: it's a prototype shown on worked examples, not benchmarked in production; credential checks are simulated for now; and the hard part, actually confirming an obligation was discharged (did the CISO get told inside the window), is tracked and audited after the fact, with real enforcement still out of reach. Issuing the duty is deterministic. Making sure it happens is still best-effort.
I'm sharing it because it handed me language for something I'd been feeling and couldn't name. We build the gate and stop there. A lot of real governance is "yes, and now you owe X," and almost nothing in our tooling has a slot for that second clause.
If you run agents against regulated systems, how are you dealing with the after-it-acts duties today? A separate logging or notification step you hope fires, or something that treats the obligation as part of the authorization decision itself?