Sentries as tool gates

This page is for architects, risk owners and others deciding how to govern autonomous agents across an organisation. The implementation is in The static agent and Agents governed by the case.

Summary

After an agent acts, someone asks: what was it allowed to do at that moment, and who allowed it. A tool grant handed out at deployment does not track whether the business condition behind it still holds. An approval written as a line of code is out of sight of the person who owns the policy it enforces. The audit trail, where there is one, is a transcript an engineer interprets for the regulator.

CMMN, the OMG’s Case Management Model and Notation, has the vocabulary for this already. A discretionary item is optional work that becomes plannable when a rule holds. A planning table says which roles may plan it. A sentry starts or stops work when an event happens and a condition holds. Read with an agent in mind, the same vocabulary says which tools the agent may call right now. The agent’s grants are case model data, which whoever owns the case definition reads and changes. A sign-off is a CMMN activation rule. A tool call the agent made is a plan item with the same lifecycle and the same record as work a person planned.

The failure is ungoverned tool access

Two patterns recur:

• A stale grant. An agent was allowed to call a refund tool during last month’s incident. The incident closed and the permission stayed, because it was a config value or a code path and nobody was assigned to revoke it.
• A question nobody can answer unaided. An auditor asks what an agent did on a case last Tuesday and why it was allowed to. Answering needs an engineer to read logs and reconstruct intent. There is no artefact a compliance officer can review alone.

Both have one cause. What an agent may do is decided once, in a place only engineers read, when it needs deciding continuously, in a place the business reads.

Why bolted-on governance falls short

Three approaches dominate, and each makes governance a property of code.

A static allowlist answers what the agent might ever need. It is as current as the last deploy, and it cannot see the state of the case in front of the agent.

An approval hook in code pauses for a sign-off. It works, and changing it (who approves, which action needs it) is a pull request, a review and a deploy. The policy’s owner and its implementer are different people with different tools.

A vendor guardrail framework solves the problem inside one framework. Its governance vocabulary exists nowhere else and moves to nothing else.

CMMN was designed to represent optional, conditionally available work as data.

The mechanism

CMMN was built for case work: work whose order is not known in advance, where a caseworker decides the next step from the state of the case. That describes an autonomous agent’s position more closely than a fixed process diagram does. The vocabulary:

• Case: the unit of work, a container of plan items with no fixed sequence.
• Plan item: one piece of work in the case (a task, a stage, a milestone) with a lifecycle: Available, Enabled, Active, Completed, or Disabled, Terminated, Failed.
• Discretionary item: an optional plan item, added to the case when someone with the authority chooses to.
• Planning table: a stage’s discretionary items and the case roles authorised to plan them.
• Applicability rule: a condition over the case file that decides whether a discretionary item can be planned now.
• Sentry: an event and, optionally, a condition over case data. An entry criterion holds a planned item back until its sentry is satisfied. An exit criterion ends an item, or a whole stage.
• manualActivationRule: an item with this rule lands in Enabled and waits for a person to start it.

The mapping onto agent governance gives none of these a new meaning:

CMMN construct	What it is for an agent
Discretionary item with a task definition	A tool the agent may call
Applicability rule	The business condition under which the tool is offered
Planning table and case role	Which agent, or which stage’s agent, may use which tools
Exit criterion on the stage	What withdraws the stage’s tools
Entry criterion on the item	What a planned call waits for before it runs
manualActivationRule	A person accepts or rejects each call before it runs

The agent’s tool list is the set of discretionary items that apply to its role now, projected from the live case on every turn.

Worked example: a credit-limit review

This case is illustrative. An agent handles a customer’s request for a higher credit limit, in a stage with three relevant items.

1. Identity verification is an ordinary task. When it completes it writes identityVerified to the case file.
2. Pull credit score is a discretionary item with an applicability rule identityVerified = true. Until the rule holds, the tool is absent from the agent’s list and the model is not told it exists. The engine evaluates the rule like any other applicability rule, and no agent code is involved.
3. Trigger manual underwriting is a discretionary item with an applicability rule creditScore < 700 and a manualActivationRule. When the agent calls it, the item lands in Enabled as a suggestion. An underwriter accepts it with ManualStart, which runs the tool with the agent’s arguments, or rejects it with ManualDisable, which closes the suggestion without calling the tool.

A parallel risk evaluation that sets riskLevel = "HIGH" satisfies an exit criterion on the stage. The stage ends, and its tools leave the agent’s list at the next turn. A model call already in flight finishes. The agent reads its tools once per turn, at the turn boundary, and nothing interrupts it mid-generation.

The record comes with the design

With planToolCalls on, a granted call is planned into the case as its discretionary item instead of being dispatched directly. It runs the whole plan-item lifecycle, sentries fire on its completion as they would for a step a person planned, and the model’s arguments are laid over the item’s inputs.

A tool call the agent made is then a plan item in the case, with a start, an outcome and a place in the case’s history. Reading the case answers what the agent did and under what authority. The history also replays against the case definition.

Scope and limits

• Two modes, chosen per spec. A static agent has an allowlist fixed when the loop starts, which fits a bounded task. Everything on this page describes case mode, where the list is read from the live case on every turn. A model author picks one per agent.
• Misconfiguration fails the run. A case-mode agent with no case-aware manifest source fails with AGENT_MANIFEST_UNAVAILABLE. It never falls back to a wider allowlist. The optional park and plan-item extensions fail the same way where they are not supported.
• Control acts at turn boundaries. Revoking a grant, the deadline on DBOS, and the token budget all take effect between turns.
• Budgets are turns, time and tokens. A spec caps turns (maxIterations), wall time (deadlineSeconds) and the tokens summed across the loop (maxTotalTokens). There is no cap in currency.
• Case mode needs the DBOS host today. The broker refuses a case-mode spec when the loop starts.

Where this sits

Graph and conversational agent frameworks solve a different problem well. Flow and agent frameworks compares the architectures. Each approach compared there has a way to gate a tool call. This page argues for one narrower property: the gate is written in a vocabulary built for conditional work years before agents, and read by the people who own the case.

Glossary

Term	Meaning
Case	The unit of work: a container of plan items whose order is not fixed in advance, unlike a BPMN process.
Plan item	One piece of work in a case (a task, a stage, a milestone, an event listener), tracked through a lifecycle.
Plan item lifecycle	Available, Enabled, Active, Completed, with Disabled, Terminated and Failed as the other outcomes.
Discretionary item	An optional plan item, added to a case at run time.
Planning table	A stage’s discretionary items and the case roles authorised to plan them.
Applicability rule	A condition over the case file that decides whether a discretionary item can be planned now.
Sentry	An event and, optionally, a condition over case data, attached to an item’s entry or exit.
Entry criterion	A sentry that holds a planned item until it is satisfied.
Exit criterion	A sentry that ends an item or a stage.
manualActivationRule	A rule that makes an enabled item wait for a person to start it.