Closing the Governance-to-Action Gap with Runtime Mediation

For: CIOs, CROs and security architects. The decision: whether your agent controls sit on the path an action actually takes, or only beside it.

This Field Note builds on the Deterministic Shell: the idea that a model may reason and propose inside the Probabilistic Core, while identity, authority and commitment are enforced by deterministic software around it. It also uses the Commit Boundary, the point where a proposal would become a real effect such as a payment or a changed record.

Having a policy is not the same as enforcing it

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Imagine a state government grants programme that funds community resilience projects. Its financial delegations instrument says a programme officer may approve grants up to $50,000. Anything larger goes to a director. The grants system has an approval screen that shows the delegate’s name, and every approval is written to an audit log.

Now the programme adds an assessment agent. It reads applications, checks eligibility, drafts an assessment and prepares the payment. During the pilot, someone gave its service account permission to call the payments API so it could “schedule approved payments”. That permission has no amount limit, because the API was built for a finance system that was trusted to check delegations itself.

On paper, this programme is governed. The delegation is written down, the screen exists and the log is complete. In execution, nothing stops the agent’s credential from paying $68,000 to an applicant, or paying the same applicant twice. The Governance-to-Action Gap, a CAE construct, names exactly this distance: the difference between governance as declared and governance as enforced on the path that actually creates the effect.

Screens, logs and roles sit beside the path, not on it

Each conventional control fails for a specific reason. The approval screen governs people who use the screen. An agent calling an API never sees it. The audit log is detective: it will tell an auditor in March that a $68,000 payment went out in November without a director’s approval, which is useful for the inquiry and useless for the money.

An instruction to “check the delegation before paying” fares no better; as the launch piece argued, a line in the prompt is guidance, not a control.

Access control is closer, but usually too coarse. A role that says “may call the payments API” answers whether the caller can reach the service. It doesn’t answer whether this payment, of this amount, to this recipient, under this delegation, is permitted today.

The deeper problem is inherited trust. The payments API has no amount limit because, when it was built, its only caller was the finance system, and the finance system checked delegations before it called. The rule lived upstream, in the caller. Give a new caller the same scope and the API extends the same trust, without the check that the trust depended on. A good deal of enterprise governance works this way: a control enforced by convention at one layer and assumed by every layer beneath it. An agent is a new kind of caller that was never party to the convention.

Why now? OWASP’s 2026 LLM Top 10 lists Excessive Agency at number three, and Australia’s Guidance for AI Adoption asks organisations to “maintain human control”. Both point at the same problem: agents are being given credentials faster than their authority is being engineered.

Every consequential action must pass through a control it cannot avoid

The CAE answer is runtime mediation. Every consequential operation an agent proposes goes to an action gateway, a deterministic service that sits between the agent and the system of record. The agent has no other route to the payments API. The gateway evaluates the proposed action against current conditions: who the principal is, what authority has been delegated and how, which policy version applies, whether the evidence is sufficient and fresh, whether human approval is required and whether the operation has already been attempted.

The idea is not new, and the book says so. Saltzer and Schroeder (1975) set out complete mediation: every access to every object must be checked for authority. Anderson (1972) described the reference monitor, a mechanism that is always invoked, protected from tampering and small enough to be verified. Runtime mediation applies those principles to a new kind of caller, one that decides for itself which operations to request.

The gateway returns one of four outcomes, each recorded with its own identifier and policy version:

• Permit when the action meets every current requirement. The gateway then executes it through a controlled adapter, or issues a short-lived capability scoped to that exact operation.
• Deny when the action breaks a rule, or asks for authority that nobody on this path can grant. Nothing executes, and the failed control is recorded.
• Escalate when the rules say a person, or a specialist, must judge. A review task is created with the proposal, its evidence, the uncertainty and a deadline.
• Re-evaluate when the action could be allowed but something it depends on is stale, missing or contradictory, so the workflow must refresh or reconcile before trying again.

In the grants programme, an $18,500 grant with current eligibility evidence and a programme officer’s approval bound to that exact payment is permitted. A payment to a bank account that differs from the recipient’s verified record is denied. The $68,000 grant is escalated to a director with the assessment attached. A grant whose applicant’s financial statements are older than the programme’s freshness window is sent back for re-evaluation.

Chapter 16 of the book makes the organisational point behind the mechanism. A governance forum decides the rule; the durable implementation of that decision is the policy, test and control that make it true at runtime, not the meeting minute.

Test for the gap before you build anything

A simple procedure finds the gap in an existing agent deployment.

1. List the declared rules that bear on effects. For the grants programme: the $50,000 delegation, the verified-bank-account rule, the one-payment-per-approval rule and the programme’s eligibility criteria.
2. Trace every path to each effect. Find every credential, integration and file transfer that can create a payment, not just the one the design diagram shows.
3. Ask one question of each path. Can this path create the effect without the rule being evaluated? If yes, you have found a gap.
4. Close the path, don’t annotate it. Remove the agent’s direct scope on the payments API and route the operation through the gateway.
5. Keep probing, as a standing control. The platform team runs an automated bypass probe on a schedule, weekly and after any change to credentials, integrations or gateway policy. It attempts each prohibited effect along every path traced in step 2, including the file drop and delegated calls, and raises an incident if any attempt is not stopped at the gateway. A gap closed once can reopen with the next integration; a one-off test shows only that it was closed on the day.

Gaps reopen in predictable ways

A second path survives. The API is mediated, but a nightly payment file upload to the bank still accepts anything the agent writes to a shared folder.

Splitting defeats a per-transaction limit. Two $34,000 payments to the same recipient each pass a $50,000 check. The gateway has to evaluate cumulative value per recipient and period, not just the single request.

Delegation launders authority. The agent can’t pay above $50,000, so it asks a finance agent or a workflow tool to do it. Delegated calls must carry the original principal and limits with them.

Escalation becomes decoration. If directors receive forty low-risk reviews a day with thin context, approval turns into a click. Escalation has to be selective to mean anything.

A permit outlives its conditions. Approval is granted on Monday, the bank details change on Tuesday and the payment executes on Wednesday. A permit must be bound to the exact operation and expire.

The limits matter too. The gateway doesn’t make the agent’s assessment correct. A well-evidenced grant to an applicant who is quietly ineligible will be permitted. It doesn’t write the policy, and it doesn’t settle who owns the rule.

Each role closes a different part of the gap

Executives decide that agent authority is written down with the same care as a human financial delegation, that it has an owner, and that “we have a policy” is never accepted as the answer to “what stops it?”

Architects design the gateway as the only route to consequential effects, with policy held outside the model, versioned and testable. They also decide which read-only operations need mediation, such as bulk exports of personal data.

Engineers implement and test the negative cases the probe runs: calls that route around the gateway, split payments, delegated requests and expired permits. Each should fail at the gateway, every time, and the probe’s results should be reported like any other conformance control.

Where the grants programme’s controls actually live

Key takeaways

• Policies, approval screens and audit logs describe how an agent should be governed; on their own they govern nothing.
• The Governance-to-Action Gap is closed only when the execution path cannot create a consequential effect without the applicable control being evaluated.
• Runtime mediation applies complete mediation (Saltzer and Schroeder) and the reference monitor (Anderson) to callers that choose their own actions.
• An action gateway returns permit, deny, escalate or re-evaluate as recorded control decisions, not as advice.
• A gap closed once can reopen with the next integration, so a scheduled bypass probe across every traced path belongs among the standing controls.

Sources and further reading

• The Contextual Agentic Enterprise, Chapter 3 (§3.6) and Chapter 16.
• J. H. Saltzer and M. D. Schroeder, “The Protection of Information in Computer Systems”, Proc. IEEE, vol. 63, no. 9, 1975. doi.org/10.1109/PROC.1975.9939
• Anderson, J. P. (1972) Computer Security Technology Planning Study, ESD-TR-73-51, US Air Force.
• OWASP GenAI Security Project (2026) OWASP GenAI LLM Top 10 2026.
• National AI Centre (2025) Guidance for AI Adoption.

Where the book goes further

Chapter 3 sets out the full list of conditions an action gateway evaluates, how a permit is bound and expires, and how mediation extends to delegated and read-only actions. Chapter 16 shows how governance decisions become executable artefacts. Next week’s Field Note looks at what the gateway needs to see: the Minimum Action-Evidence Bundle. For how decisions are then recorded, see Evidence-First Decision Records.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.