A Five-Checkpoint Architecture Names What Governance Frameworks Left to Runtime

A May 2026 IBM Research demo describes a policy layer that intercepts an agent at five structural points, and in doing so, makes visible how much prior governance language has been aspirational rather than architectural.

Governance frameworks for agentic AI have tended to describe what must be controlled without specifying where, mechanically, inside an agent's execution pipeline the control would actually sit. A paper posted to arXiv on May 20, 2026, titled "Governance by Construction for Generalist Agents," by Segev Shlomov, Iftach Shoham, Alon Oved, Ido Levy, Sami Marreed, Harold Ship, Offer Akrabi, Sergey Zeltyn, Avi Yaeli, and Nir Mashkif, takes a position that is notable less for its solution than for what naming that solution reveals about the gap it addresses. The paper opens with a direct statement of the problem: "production deployments require governance by construction," and systems "must specify which actions are allowed, when human oversight is required, and what information may be exposed, without rebuilding the agent for each domain."

The phrase "without rebuilding the agent for each domain" is doing quiet but significant work. It implies that the default alternative, the approach governance-as-policy-document frameworks have generally assumed, would require exactly that: bespoke reconstruction of oversight logic for every new deployment context, an approach that does not scale and that most enterprises do not, in practice, undertake. The paper's contribution is a demonstration that policy enforcement can instead be modular and composable with a generalist agent, rather than baked into a fine-tuned model or reconstructed per domain.

Five Checkpoints, Not One

The paper's architectural claim is specific: policies intercept the agent at five structural checkpoints across the execution pipeline, rather than at a single gate. Upstream of planning, an Intent Guard evaluates the request before the agent begins reasoning about how to fulfill it. Within the system prompt itself, a Playbook component steers reasoning toward permitted patterns. At the tool-call boundary, a Tool Guide enforces proper usage of whatever external capability the agent is about to invoke. Outside the reasoning loop entirely, Tool Approvals implement a human-in-the-loop gate specifically for high-risk actions. And at the output stage, an Output Formatter filters and structures the agent's final response before it reaches the user.

The paper frames this distributed structure as intentional: "rather than passively constraining behavior, policies intercept the agent at five structural checkpoints." The claim being made, implicitly, is that a single checkpoint, wherever it is placed, cannot cover the space of failure modes a generalist agent can produce, because different failure modes originate at different points in the pipeline. A malicious or accidental harmful request needs to be caught before planning begins. A destructive tool call needs to be caught at the moment of invocation, not after. An unsafe response needs to be caught at output regardless of how the agent arrived at it.

What the Demo Actually Shows

The evaluation described in the paper is a healthcare scenario paired with what the authors call a multi-layered enforcement intervention. The demonstration shows dynamic playbook injection enforcing structured tool-sequence patterns, intent guards blocking malicious or accidental harmful requests before they enter the reasoning loop, and human-in-the-loop tool approval checkpoints specifically for potentially destructive actions. The paper describes the result as improved policy adherence and execution consistency, and frames the broader contribution as enabling "faster, safer deployment of enterprise agentic systems" through what it calls typed governance primitives.

It is worth noting precisely what this is and is not. It is a demo, evaluated on a single domain scenario, not a large-scale empirical study of failure rates across diverse deployments. The paper is explicit that its contribution is architectural and illustrative rather than a definitive measurement of how much risk the five-checkpoint structure eliminates in production at scale.

The Privilege Category, Made Concrete

The Five Categories advisory issued by CISA, NSA, and allied agencies names privilege risk as a category demanding strict adherence to least privilege, warning specifically that static role or permission checks fail to capture the context of dynamic decision-making, and that entitlements evaluated only once at system startup rather than at each invocation allow a stale permission decision to be exploited. The five-checkpoint architecture in this paper is a direct architectural response to exactly that warning: the Tool Guide checkpoint operates at the tool-call boundary, meaning permission evaluation happens at the moment of invocation rather than once at startup, which is precisely the distinction the advisory identifies as the difference between a real control and a theoretical one.

That correspondence is what makes this paper worth reading against the arc's recurring argument rather than as a standalone systems paper. The advisory names the failure mode. This paper demonstrates, at demo scale, one architectural shape a system could take to address it structurally rather than through policy language alone. What the paper does not demonstrate is that this shape, once deployed at production scale across heterogeneous domains, holds up against the kind of adversarial pressure the memory poisoning, stored prompt injection, and attack selection research examined elsewhere in this arc describes. A five-checkpoint architecture is a stronger claim than a policy document, but it is still a claim that requires independent verification before it can be treated as a solved governance layer.

Extending the Fog

The recurring argument throughout this arc is that visibility into an agent's behavior is not equivalent to verifiability of the process producing it. A five-checkpoint architecture is an attempt to build verifiability directly into the pipeline rather than bolting it on afterward. That is a meaningfully different posture than governance-as-document. But the paper's own scope, a demo on a single healthcare scenario, means the claim that this architecture generalizes to the full space of enterprise agentic deployment remains unverified. Naming where governance ought to sit inside an execution pipeline is a necessary step. It is not the same as proving that each of the five checkpoints resists the specific attack classes documented elsewhere in the current agentic security literature.

Open Questions

• What would an independent evaluation of the five-checkpoint architecture need to measure, beyond a single healthcare demo scenario, to establish whether it holds under adversarial pressure at production scale?
• How does a Tool Guide checkpoint, evaluating permissions at the tool-call boundary, hold up against a memory poisoning attack that alters what the agent believes its own permitted tool sequence should be?
• At what point does a demo-scale governance architecture need to be re-validated against threat classes, such as cross-session stored prompt injection, that were not part of its original evaluation scenario?
• Who verifies that the Intent Guard, Playbook, and Output Formatter checkpoints are actually enforcing the policies they are configured to enforce, rather than merely being present in the architecture diagram?
• What standard applies when an enterprise adopts a five-checkpoint architecture and treats its presence as sufficient evidence of governance, without independent verification that each checkpoint resists the specific attack classes documented in adjacent research?
• Does the modularity that lets this policy layer compose with a generalist agent without fine-tuning also mean the policy layer itself can be bypassed or reconfigured by the same agent it is meant to constrain?

The loop closed around an oversight function that was never instrumented.