What is runtime AI governance?
Runtime AI governance evaluates context, policy, and risk while an AI interaction or agent action is taking place, allowing an organization to observe, allow, block, redact, or require approval before or during execution.
This is an operational definition. The available interventions depend on a control point that can affect the interaction or action. Observing activity can inform a decision without stopping it; requesting an intervention does not establish that the executor applied it. The integration must define which effects it can produce and under what conditions.
AI usage governance establishes the conditions for permitted use. Runtime governance connects those conditions to a particular interaction while the workflow operates. Its central question is whether the decision still applies to the operation the system is about to perform.
A written policy needs an application point
A rule can be correct and still have no effect on an operation. “Restart staging services only during an approved maintenance window” expresses a condition. An implementation needs to identify the target environment, establish whether the window is open, and prevent the restart from proceeding when the condition is not satisfied.
The policy itself does not need to change for the answer to change. A maintenance window can close, an approval can expire, or the target of a request can change while a workflow is running. A decision based on the earlier context needs defined limits on when and where it can be used.
Runtime evaluation does not replace planning. The organization must still establish the rule, identify its owner, and decide what risk it will accept. The implementation then needs a point at which that rule can affect the relevant operation.
Runtime context can change before the decision is applied
Context should identify the proposed operation, its target, the acting identity, and the attributes needed by the policy. Record where those attributes came from and whether they are sufficiently current for the decision. An environment name supplied in a request and an environment established from an authoritative resource record offer different evidence.
NIST's Zero Trust Architecture, SP 800-207, section 2.1 describes access decisions using identity, application, asset, and other contextual attributes, with reevaluation governed by policy. It provides a reference for dynamic access decisions, not a specification of AI runtime governance or proof of a product's coverage.
Hypothetical example: an operations assistant requests a restart of a staging report-generation service. Policy permits that restart during an approved maintenance window. The request passes a policy check, then waits in an execution queue. The maintenance window closes before a worker picks it up.
The earlier permission is evidence of a decision made under the earlier conditions. The execution contract must establish whether the worker can still use it. In this hypothetical design, the worker checks the window again before dispatch and holds the request if the window has closed. That behavior is a design choice in the example, not a tested KonaSense integration.
The same issue arises if the request's target or arguments change after evaluation. An approval for one proposed restart does not automatically apply to a different environment. Passing a decision identifier along with the request helps locate the record, but the implementation still needs to check that the decision covers the operation.
Define the contract at the decision point
The contract is the agreement between the component evaluating policy and the component able to carry out the operation. It needs to specify the request being evaluated, the context used, the possible decisions, and the executor's required behavior. An AI control plane can coordinate these responsibilities without being the component that performs the action.
At the decision point, determine what remains under control. A wrapper may be able to withhold a tool call but have no authority over a request sent through another client. An application may be able to stop submission of text but not revoke content already transmitted. Name the protected operation precisely enough to distinguish those boundaries.
Decision validity belongs in that contract. Establish which changes require reevaluation, how long a decision may be used when time matters, and whether it applies to a retry. The mechanism for binding a decision to the operation depends on the architecture; a session-wide label alone does not describe the target, arguments, or conditions authorized.
Policy evaluation can also lack enough information to return an applicable result. Missing context, an unsupported decision, and a transport failure are different states. Define what each means for execution instead of allowing the adapter's incidental behavior to become the organization's policy.
The architecture guide maps these responsibilities to components and trust boundaries, including the identity and authorization each handoff must preserve.
What each decision requires from the executor
Decision names are useful only when their effects are defined. The table below describes conceptual contracts, not a list of controls available in every integration.
| Decision or mode | Required behavior for the intended effect | Limit of the conclusion |
|---|---|---|
| Observe | Record the relevant activity without claiming the observation prevents it | A record can support later decisions; it does not itself establish intervention |
| Allow | Permit the specified attempt while respecting its conditions and destination authorization | Permission does not establish successful execution or grant additional destination privileges |
| Block | Withhold the protected operation on the controlled path | The block does not cover another path unless that path is also controlled |
| Redact | Replace or remove the specified sensitive content before the protected use of that content | A suggested replacement or added instruction is not proof that the original content was replaced |
| Require approval | Keep the operation pending until a valid, applicable decision permits it | A warning dismissed by the requester is not automatically approval by a designated reviewer |
For redaction, the contract needs to identify what is transformed and what happens if the transformation cannot be applied. Hiding text in a display is different from changing the content sent to a model or tool. Confirming an editor's value is useful evidence about that editor; additional evidence may be needed to establish the transmitted content.
For approval, specify who may decide and what information they review. If the operation changes while approval is pending, determine whether the previous review remains applicable. A pending request should not become permitted merely because a response did not arrive.
Pre-execution governs a particular effect
Pre-execution governance evaluates a proposed operation at a point where its execution can still be withheld. “Before” refers to the effect being governed. A check before restarting the staging service may govern that restart even though the assistant has already read operational information or completed other steps.
During an ongoing workflow, a later decision can govern a future step or interrupt work that the integration can still stop. It cannot undo a completed restart or retract data already delivered. Recovery or reversal, where possible, is a separate operation with its own authority and evidence.
The restart example therefore needs a check before dispatch to govern the queued operation. Canceling a subsequent retry may limit another effect, but it does not establish that the first restart was prevented. AI agent governance places these individual decisions within the agent's broader delegated authority.
The pre-execution governance guide examines how to match a decision to concrete targets and arguments, including calls that contain several operations.
Treat failure behavior as part of the policy contract
A runtime dependency can time out or become unavailable. The executor still does something: continue, remain pending, stop, or follow another defined path. Review that behavior explicitly for the protected operation. A timeout is not a policy decision that the request is acceptable.
Where policy requires authorization before execution, the absence of that authorization must not be treated as approval. OWASP's Authorization Cheat Sheet recommends checking permissions for each request and handling authorization failures without creating a bypass. This is a design requirement to assess; it does not describe the behavior of every runtime adapter.
If a supplemental integration is configured to continue when evaluation fails, document that loss of control for the affected path. Assess the authorization that remains at the destination. Do not report the failed check as preventive enforcement merely because normal requests are evaluated successfully.
Retries and fallback paths need the same scrutiny. In the hypothetical queue, a worker should not retry a restart under an expired permission merely because an earlier attempt failed. A manual exception can provide another authorized route, but it needs an owner, scope, and evidence of which route was used.
Evidence should show how the contract was fulfilled
Keep the policy result and the executor's handling distinguishable. A response emitted by an adapter shows what the adapter produced. An acknowledgment can show that another component received it. Evidence of the executor's behavior is needed to establish what was applied, with destination evidence where the conclusion depends on the external effect.
For the queued restart, a useful review would connect the initial request, the window state used for evaluation, the later validity check, the worker's handling, and any observed restart result. If the destination outcome cannot be established, leave it unknown. The example has not been executed as a test, and these records are proposed evidence, not fabricated logs.
The analysis of observability and governance examines proof of preventive control in more depth. Here, the additional requirement is to preserve the context and conditions under which a decision could be applied, so a later reviewer can assess whether the contract was fulfilled.
Where runtime governance can operate
A browser integration can participate before a supported submission. A coding-agent hook can participate at a particular lifecycle event. An application or service can place a check before invoking a tool, releasing an output, or changing a resource. Each location exposes different context and gives the integration different authority over the next step.
An output check can govern a later use of generated content when that use waits for the check. It does not establish that earlier prompts or tool calls were governed. An observation received after an operation can inform a later decision without becoming a preventive control for the completed operation.
For each surface, verify the installed integration, the relevant event, supported responses, and alternative execution paths. “Runtime enabled” is not enough to describe coverage. The useful description identifies what can be evaluated, which operation can be constrained, and where the implementation cannot establish the effect.
Use the KonaSense Runtime AI Governance Framework to examine which responsibilities and information are missing from a specified governance outcome.
How KonaSense approaches runtime AI governance
KonaSense's integration paths have different contracts. Their behavior should be evaluated for the specific operation and installation.
In the reviewed Kona for Browser implementation, a supported DOM submission path can withhold submission after a block decision and attempt to replace text when a transformation is returned. The effect depends on the path and inspection mode. Some error or missing-response paths resume submission, so the implementation does not establish a universal fail-closed guarantee. An editor update alone does not prove what the destination received.
In the reviewed Claude Code PreToolUse path for Kona for Agents, the adapter can return a denial, request user approval, or return updated tool arguments. Other hooks map decisions differently, and evaluation errors fall back to Allow. Those mappings should not be generalized into approval or content replacement across every hook or agent.
The reviewed OTLP ingestion paths evaluate exported activity separately from the emitting application's execution. They return OTLP responses without intervention decisions for that application. A policy result attached to the collected event is evidence of analysis, not confirmation that a control was applied by the emitter.
Assessing these mechanisms means checking the contract at each supported point: context, decision, application, failure behavior, and available evidence. No single decision label establishes all five.