The policy that fires too late
Consider an agent executing a multi-step workflow. It reads data from a customer database, transforms it, and writes the result to an external partner's API. The organisation has a governance policy: customer data must not be sent to external systems without classification review. The agent completes the workflow. The governance layer evaluates the policy. The violation is detected. An alert fires.
The data has already been sent.
This is the fundamental problem with post-execution governance. The policy existed. The evaluation machinery worked correctly. The violation was detected. And none of it mattered, because the enforcement happened after the side effect occurred. The external API received the customer data. The partner's system ingested it. No amount of alerting can un-send the request.
Runtime policy enforcement is the evaluation of governance rules during execution, before the side effect occurs. The policy is checked at the point where the agent is about to act, and the action is permitted or blocked based on the evaluation. The enforcement is synchronous with the execution.
The distinction is binary. Either the governance rule was evaluated before the action and had the power to prevent it, or it was evaluated after the action and could only report on it. The first is enforcement. The second is monitoring. Calling monitoring "governance" is a category error that creates real risk for organisations deploying agents into production systems.
Why does post-execution governance persist?
The prevalence of post-execution governance is not a mystery. It is an engineering convenience. Synchronous policy enforcement adds latency to every action. It requires the governance layer to be available with the same reliability as the execution layer, because if the policy engine is down, either the action is blocked (reducing availability) or the action proceeds unchecked (reducing security). It requires governance rules to be expressed in a form that can be evaluated programmatically and quickly, which constrains the expressiveness of the policy language.
Post-execution governance avoids all of these challenges. The agent acts at full speed. The governance layer processes events asynchronously, at its own pace, with no impact on execution latency or availability. Policies can be complex, involve human review steps, and take as long as they need. The architecture is cleaner. The separation of concerns is textbook.
It is also insufficient. The entire value proposition of governance is that it prevents unacceptable outcomes. A governance system that detects without preventing is a reporting system. Reporting is valuable. Reporting is not governance.
The engineering challenges of synchronous enforcement are real, and they are solvable. The organisational challenge, recognising that convenience has been prioritised over correctness, is harder.
What runtime enforcement looks like in practice
Runtime enforcement requires the governance layer to sit in the execution path. When an agent is about to perform an action, the execution pipeline evaluates all applicable governance rules before the action is dispatched. If the rules permit the action, it proceeds. If they prohibit it, the action is blocked and the agent receives a structured denial that explains which rule was triggered and why.
This is how Covia's rule book operates within the Grid. The rule book is a set of governance policies expressed as executable rules that are evaluated at the point of action. The rules have access to the full context of the execution: the agent's identity, its delegated authority (via UCAN tokens), the specific action being attempted, the target resource, and the current state of the workflow.
A rule might specify that agents with a particular authority scope cannot write to production databases outside of designated maintenance windows. Another might require that any action affecting customer PII triggers a classification check before proceeding. Another might enforce rate limits on the number of external API calls an agent can make within a single execution, preventing runaway behaviour from exceeding expected bounds.
The critical property is that these rules are evaluated before the side effect occurs. The agent cannot bypass the evaluation because the rule book is part of the execution pipeline. The evaluation adds latency measured in milliseconds, an acceptable cost for the guarantee it provides.
The difference between a gate and a camera
The metaphor is physical. A security gate checks credentials before allowing entry. A security camera records who entered and generates alerts. Both are security infrastructure. They serve fundamentally different purposes.
Post-execution governance is the camera. It records. It alerts. It enables investigation after the fact. Runtime enforcement is the gate. It prevents. It blocks. It ensures that only authorised actions proceed.
Most organisations need both. The failure mode is deploying only the camera and calling it a gate. When the auditor asks "how do you prevent agents from violating governance policies?", the answer "we detect violations and alert on them" is not the same as "we evaluate policies before execution and block violations." The first is monitoring. The second is enforcement.
How does this connect to the compliance landscape?
The EU AI Act's requirements for high-risk AI systems include provisions for human oversight and the ability to intervene in the system's operation. The specific implementation is left to the deployer, but the intent is clear: there must be a mechanism to prevent the system from producing unacceptable outcomes. Detecting them after the fact is insufficient.
SOC 2's trust service criteria include requirements for controls that prevent unauthorised access and changes. "Prevent" is the operative word. A control that detects without preventing is a detective control, valuable in a layered security model, insufficient as the primary governance mechanism for autonomous systems.
The compliance frameworks are converging on a principle that should have been obvious from the start: governance of autonomous systems requires the ability to constrain their behaviour in real time. The autonomy is the feature. The constraint is the governance. If the constraint operates on a different timeline than the autonomy, the system is ungoverned for the duration of the gap.
The architecture decision that determines governance posture
Whether governance is runtime or post-execution is an architecture decision, not a configuration choice. It determines where the governance layer sits relative to the execution layer. It determines the failure modes (does governance unavailability block execution or permit unchecked action?). It determines what guarantees the organisation can make to auditors, regulators, and customers.
Retrofitting runtime enforcement into an architecture designed for post-execution governance is possible but expensive. The execution pipeline must be modified to include synchronous policy evaluation. The policy engine must be elevated to the same availability and performance tier as the execution infrastructure. The governance rules must be re-expressed in a form suitable for synchronous evaluation. And the entire system must be re-tested to ensure that the added enforcement does not introduce unacceptable latency or availability regressions.
Covia's Grid was designed with runtime enforcement as a foundational property. The rule book evaluation is part of the execution pipeline, built in at design time. This is a design-time decision that cannot be replicated by adding governance tooling to an execution platform that was not built for it.
Enterprise organisations evaluating agent platforms should ask a direct question: does the platform enforce governance rules before or after the agent acts? The answer reveals whether the governance is structural or decorative.
What remains unresolved
Runtime enforcement solves the timing problem. It does not solve the completeness problem. The rules in the rule book are only as good as the governance team's understanding of what needs to be constrained. A perfectly enforced but incomplete policy set still leaves gaps.
This is the deeper challenge: governance requires ongoing attention. The agents evolve. The workflows change. The threat landscape shifts. The governance rules must keep pace. Runtime enforcement ensures that the rules that exist are actually enforced. It does not ensure that the right rules exist.
The organisation that has runtime enforcement and reviews its rule book quarterly is better governed than the organisation that has comprehensive post-execution monitoring and never updates its policies. The enforcement mechanism is necessary. It is not sufficient. Sufficiency requires the organisational discipline to treat governance as an ongoing engineering practice that continues well past deployment.
Whether organisations will invest in that discipline before or after their post-execution governance fails to prevent a consequential violation is a question that each organisation answers through its actions, and each CISO answers for.