Runtime governance is the evaluation of an AI agent's actions against its declared intent, scope and policy while the agent is executing, with the results recorded as evidence. Sentience Governor implements it as observation and recording: actions are evaluated and flagged, and execution is not interrupted.
Runtime governance is a first-class capability because of what it establishes: a relationship, made during execution and preserved afterward, between an agent's declared purpose, the actions it attempts, the policy that applies and the findings of an evaluation. The record of that relationship is the foundational artifact. What happens in response to a finding, from noting it to stopping the action, is a separate capability that may consume the evaluation and decide what comes next. Runtime governance is therefore not defined by blocking, authorization or enforcement. It is an architectural approach, not a product category, and systems built on it differ widely in what they do with what they learn.
Three moments of governance
| Moment | Typical activities | The question it answers |
|---|---|---|
| Before deployment | Evaluation on test tasks, red teaming, permission design, policy authoring | How does this agent tend to behave, and what should it be allowed to do? |
| During execution | Evaluating each attempted action against a declared reference and policy | Is this action, in this run, consistent with what the agent is supposed to be doing? |
| After execution | Review of records, incident analysis, audit | What happened, and what should change? |
These are complementary. Pre-deployment evaluation is how an organization learns whether an agent is fit to deploy at all, and nothing at run time replaces it. Retrospective review is how lessons are drawn and policies corrected. Runtime governance supplies something the other two cannot produce on their own: a judgment about a specific action, made with the context that existed when the action was attempted, and preserved for the review that follows. NIST's AI Risk Management Framework treats governance as continuous across a system's life for the same reason.
Being active during execution is not what sets runtime governance apart. Gateways, guardrails and observability tooling all operate while an agent runs. The difference lies in what is being established, which the sections below take up.
Why the moment of action matters for agents
Three properties of an AI agent make this middle moment worth attention.
- The path is chosen at run time. An evaluation before deployment samples an agent's behavior. It cannot enumerate the sequences the agent will produce in use, because those do not exist yet.
- Execution is multi-step. Each action changes the situation in which the next is chosen. A step that is harmless alone can matter because of what came before it.
- Context changes underneath the agent. Tool results, retrieved documents and earlier outputs enter the context as the run proceeds. The agent at step fourteen is not reasoning from the material that was reviewed at step one.
None of this makes other controls less necessary. It means that some questions can only be asked while the agent is running.
Distinct from, and complementary to, neighboring controls
Four established approaches sit close to runtime governance. Each does something it does not, and each leaves open something it addresses.
| Approach | What it establishes | What it does not necessarily establish |
|---|---|---|
| Pre-deployment evals | How an agent behaves under the conditions that were tested | How it behaves in a particular run, under conditions nobody tested |
| Guardrails | That inputs, outputs or actions satisfy constraints defined in advance | Whether an action that satisfies every constraint has anything to do with the task at hand |
| Gateways | That requests crossing a boundary the gateway controls are authenticated, routed, limited or logged | A session-level relationship between those requests and a declared purpose, above all for actions that never cross the gateway |
| Traces and observability | What happened during execution, in depth and often live | The governance relationship itself, unless the system is specifically instrumented to carry objective, scope, policy and findings |
The wording is deliberate. A guardrail can be written to be aware of the task. A gateway can hold session state. An observability pipeline can carry an objective and a policy decision as attributes on a span, and some do. None of these capabilities is out of reach for the neighboring approaches. The distinction is in what each is organized around. Evals are organized around tested behavior, guardrails around defined constraints, gateways around the boundaries they control, and observability around what occurred. Runtime governance is organized around one relationship: this action, under this policy, against this declared purpose, with this finding.
That is also why they work together. Evals decide whether an agent should be deployed. Guardrails and gateways bound what it can do. Observability explains how a run unfolded. Runtime governance records how each attempted action related to what the agent was there to do.
The autonomy tradeoff
Anyone deploying an agent meets the same tension. Restrictions that are tightly predetermined are predictable, and they can rule out a legitimate path the agent discovers on its own, which is much of the reason for using an agent. Restrictions that are permissive leave room for that discovery, and they also admit actions that have nothing to do with the task.
Runtime governance does not resolve this tension. It changes what is known about it. With a declared reference in place, an agent can be given room to choose its path while each attempted action is still evaluated against what it said it was doing, and the result is kept. A team can then see, from evidence, where a scope was too tight or too loose, and adjust. What runtime governance does not do is eliminate the tradeoff, or prove that every action it let pass without a finding served the task.
How the parts fit
Runtime governance needs a reference, a vantage point, a unit of analysis, a set of rules and a record.
- A reference. Declared intent: an objective and the scope it authorizes, stated before the agent acts.
- A vantage point. The execution boundary: the point where a decision becomes an attempted operation.
- A unit. The agent action: one attempted operation, described by tool, operation type and target.
- Rules. Policy: defaults that apply to every agent, plus an operator's own governance profile.
- A record. Governance evidence: what was declared, attempted and concluded, with its unknowns left in.
At each boundary crossing, the action is compared with the reference under the rules, and the result is written down.
The record as a first-class artifact
The fifth part deserves more weight than it usually gets. The relationship between the declared reference, the attempted action, the policy and the finding should be three things.
- Explicit. Stated in the record as such, not left to be inferred later from a trace, a prompt and a policy file that may each have changed since.
- Preserved. Written at the time of the action, in order, and kept after the run ends, so that the account does not depend on anyone's recollection, including the agent's.
- Independently useful. Worth having whether or not anything acts on it in the moment. It supports review, accountability and the comparison of one run with another, and it can be handed to other systems.
This is the sense in which the record is foundational. A decision to stop or allow an action is only as reviewable as the record of why it was made. An organization that never stops anything still learns from an accurate account of what its agents attempted and how that related to their purpose. Everything else is a decision about what to do with that account.
Observation, advice, authorization, enforcement
A finding can be met with a range of responses: observe, flag, warn, request approval, restrict, or block. These are separate capabilities that consume the evaluation. They are not part of the evaluation, and an implementation can offer the first of them without any of the rest. This is where implementations differ most, and four broad postures are worth separating because they are often blurred.
| Posture | What happens at the boundary | What it requires |
|---|---|---|
| Observation | The attempted action is recorded | A place to observe from |
| Advisory evaluation | The action is evaluated and findings are recorded or surfaced; the action proceeds | A reference and rules to evaluate against |
| Authorization | A decision is made on whether the action may proceed, by a rule, a policy engine or a person | A position in the path of the call, and a defined behavior when the decision cannot be reached |
| Active enforcement | Actions that fail the decision are stopped, altered or rolled back | All of the above, plus confidence that a wrong decision costs less than the harm it averts |
The first two can sit beside the agent. If they fail, the agent carries on. The last two sit in the path of the call, so their availability, latency and error rate become properties of the agent itself. Neither arrangement is better in general. Many mature systems combine them: a harness that asks a person before a destructive command, a policy engine such as Open Policy Agent deciding on requests, guardrails validating arguments, a sandbox limiting reach, and an advisory layer recording how each action related to the task. Claude Code's hooks, for instance, allow a hook to permit or deny a tool call, and the Model Context Protocol specification asks that a person be able to deny tool invocations.
Sentience Governor 0.3.2 occupies the first two postures only. Of the responses listed above it provides two: it observes and it flags. It evaluates each attempted action, records advisory findings, and lets every call proceed. It does not warn the agent in the path of a call, request approval, restrict or block.
One implementation: Sentience Governor 0.3.2
Where it attaches. Through Claude Code hooks, a wrapper for Model Context Protocol clients, a LangChain callback handler that also covers LangGraph, and a separate package for Pydantic AI. It sits beside the agent. Actions that do not pass through one of these points are outside its view.
What it evaluates. The evaluation is deterministic and rule-based. It does not use a model to judge an action. It checks:
- whether an objective has been declared, and whether an operation that writes, deletes or executes is being attempted without one;
- whether the action's target system falls within the declared scope, by exact match or prefix;
- a small set of default policy rules, including ones for data entering the context unclassified and for writes to persistent stores;
- the operator's profile: signals that a task boundary has been crossed, and operations the operator has marked high-consequence, by tool pattern or by classified effect;
- for Claude Code shell commands only, the potential effects of the command, by domain, action and destructive character, with unknown and incomplete stated as such.
What it produces. Findings attached to the event for that action, as advisory flags and named policy violations, in a local record. Every event is marked as passed through.
An example
The events below are genuine output from the released 0.3.2 Model Context Protocol client wrapper, run in a single process. The tools were stand-ins written for this example, and they did execute: three returned a result and one deliberately raised an error. No real customer system, email service or payment system was operated. The four calls were supplied by the demonstration in a fixed order. They were not chosen by a live language-model agent, so the example shows what Governor records and evaluates, not how an agent behaves. Tool arguments and results do not appear in the record. Default policy rule identifiers are omitted and described in words.
A customer support agent was constructed by its developer with a declared capability of crm.read and the objective "Answer the customer's question about the status of order 1042". Because the developer supplied it, the record marks the intent as explicit:
{
"event_type": "INTENT_DECLARED",
"payload": {
"stated_objective": "Answer the customer's question about the status of order 1042",
"intent_source": "explicit",
"intent_confidence": "explicit",
"session_scope_hint": ["crm.read"]
}
}The demonstration then made four tool calls through the wrapper, in the way an agent's calls would pass through it.
| Attempted tool call | Recorded as | Pre-call finding on the action | After the call |
|---|---|---|---|
crm.get_order | Read, target crm | None | A result entered the context, 12 tokens |
crm.update_customer | Write, target crm | None | A result entered the context, 13 tokens |
email.send_message | Read, target email | Scope mismatch, default intent rule | A result entered the context, 13 tokens |
payments.create_refund | Write, target payments | Scope mismatch, default intent rule | No post-call context event. The tool raised, and the caller received the error unchanged |
The third column covers the finding made on each action before the call. Separately, each of the three context events recorded after a returned result carried its own finding, that the data entering the agent's context was unclassified, together with the default classification rule.
Several things are visible here.
Evaluation happened at each attempt. The email and the refund were marked as outside the declared scope at the moment they were attempted, before either tool ran.
Nothing was stopped. All four calls were passed to the tools. The refund failed because the stand-in payment service raised an error, not because of governance, and the wrapper let that error reach the caller as it was.
Attempt and return are distinguishable. Three attempts are followed by an event recording that a result came back. The fourth is not. A reviewer can see that the refund was attempted and did not return, without the record claiming anything about the payment system.
The limits show too. The declared capability was crm.read, and a write to the customer record produced no finding. The reason is how the released evaluation matches scope. It compares an action's target system with the part of each declared entry that comes before its first dot, and accepts the target if it equals that part or begins with it. crm.read is therefore read as crm, the target crm matches, and the read part of the capability plays no role. Declaring crm, crm.read or crm.write gives the same result, and because the test is a prefix test, a target named crmarchive would match as well. This is the same exact-or-prefix matching described in the declared intent entry, where entries such as shell/process contain no dot and are used whole. The operation types themselves are inferred in this wrapper from the tool's name, which is why email.send_message was recorded as a read. Both are properties of the released implementation and are better stated than discovered.
What runtime governance cannot establish alone
- Effects. An evaluation at the boundary concerns the attempt. Whether the customer record changed or the email was delivered is known to the systems that were acted on. Confirming it takes evidence from them.
- What was never seen. Coverage is a property of instrumentation. Actions that cross the boundary elsewhere need more integration points, not better rules.
- Relevance to the objective. Rule-based evaluation compares structured facts. Deciding whether an in-scope action truly served the task requires interpreting the objective and the action, which is semantic evaluation. That can be done by a person in review or by a model acting as a judge, each with its own costs, and it is not part of the released Sentience evaluation.
- The quality of the reference. A vague objective or a very broad scope gives an evaluation little to work with, however carefully it runs.
- Its own integrity. A record is only as trustworthy as the place it is kept.
Where the concept stops
Runtime governance is a way of attending to actions as they happen. It is not a synonym for control, and adopting it does not by itself make an agent safe. Its contribution is specific: a judgment about each action, made against a reference stated in advance, at the moment the action was attempted, and kept. What an organization does with that judgment, whether it informs a review, prompts a person or feeds a decision in the path of the call, is a separate design choice, and an important one.