Pre-execution governance evaluates a proposed operation before the effect being governed can occur and requires a control point able to apply the resulting decision to that operation. This is an operational definition: the point must know the material targets and arguments while it can still withhold the protected effect. Approving a tool name alone does not establish that boundary.
The value is a remaining choice: permit the scoped operation, withhold it, change the proposal where supported, or obtain applicable approval. Runtime AI governance describes how decisions remain valid during a workflow. This guide examines the unit of work those decisions actually cover, especially when one call contains more than one operation.
Start with the batch request, not the tool name
Consider a hypothetical maintenance task: add a follow-up label to the resources owned by a particular team for an upcoming review. The task authorizes changes to that team's resources only. Suppose the agent proposes a batch label update, but resolving its selection produces resources owned by that team and another team. The executor's credential permits access to both.
These conditions are an example for evaluating the design, not a KonaSense integration or a test result. No platform-specific meaning, automatic consequence, or atomic behavior is assumed for the label update. The architecture must establish those properties for the actual tool before relying on them.
The tool may be permitted for the task while the resolved batch exceeds the delegation. Allowing “label update” does not answer which resources may change, which label value should be applied, or whether the executor will use the same selection the evaluator saw. The permission in the credential establishes available authority; the task defines a narrower intended use.
Choose the point that can see and still withhold the effect
A useful control point combines relevant information with authority to stop the operation it evaluates. An early check may know the user's intention but not the selected resources. A later component may resolve those resources yet lack any way to prevent a request already dispatched elsewhere. Evaluate both conditions before describing the mechanism as preventive.
| Inspection point in the hypothetical workflow | What it can establish | Boundary still to verify |
|---|---|---|
| Initial task instruction | Requested team, intended label, stated purpose | The final selection and executor identity may not yet exist |
| Selected tool name | Which interface the agent proposes to call | One interface can affect resources inside and outside the task |
| Resolved batch before submission | Proposed resource set, label arguments, relevant ownership facts | The executor must consume the evaluated proposal without silently expanding it |
| Operation at the service applying the change | The item or request that service is about to process | The service needs its own applicable authorization and a way to withhold that effect |
| Response or later state observation | What a source reports after an attempt | An effect that already occurred cannot be prevented by this observation |
The rows describe logical positions, not required services or guaranteed visibility. A system may combine them or repeat a check for each item. The architecture guide maps the component and trust responsibilities; the design here asks what operation remains under control at each position.
Resolve a concrete proposal and its authorization facts
Represent the proposal precisely enough for the evaluator to distinguish an allowed update from an out-of-scope one. In this example, that means identifying the resources in their relevant namespace, the proposed label and value, the operation's update semantics, and the identity that will perform it. Adding a label and replacing a label set are different proposals even if the same interface supports both.
Keep the selection expression separate from its resolved result. “Resources for the review” is an instruction to find a set, not evidence that every returned resource belongs to the authorized team. Establish where the ownership facts come from and which observations the evaluation uses. If enumeration is incomplete or an ownership reference cannot be resolved, preserve that limitation instead of treating the unknown items as authorized.
The evaluator also needs the task's delegation, including any permitted exceptions. A broad service credential does not supply that missing delegation. OWASP's authorization guidance recommends validating permissions on every request. Apply that principle to the actual operations and resources exposed by the implementation; a permission check on the batch interface is not automatically a check on each item it processes. OWASP Authorization Cheat Sheet.
The analysis of prompt-level governance explains why accepting an initial request does not establish that material resolved afterward was examined.
Bind the decision to what the executor will consume
A decision about a resolved resource set is useful only if the executor can establish which operation it covers. Define how the evaluated targets, material arguments, acting identity, and relevant context are associated with the request used for execution. A shared session identifier locates related work but does not make two versions of a batch equivalent.
If the evaluator sees an explicit resource list but the executor later reruns a dynamic selection, the same selection text can produce a different set. Where the interface supports it, one design is to submit the evaluated explicit list and verify that it remains applicable. Another is to evaluate each resolved operation at the service before that operation's effect. These are design options to assess, not interchangeable guarantees or capabilities attributed to KonaSense.
Specify what happens when that correspondence cannot be established. A changed target, label argument, or execution identity can require a new proposal and decision. Do not attach an old approval to the replacement merely because the runtime retained the task ID. OWASP's transaction authorization guidance describes protecting material transaction data and checking authorization at a final gate tied to execution. That supports the relationship between an approved operation and the operation carried out; it does not prescribe this batch architecture. OWASP Transaction Authorization Cheat Sheet.
Make Allow and Deny precise about their scope
Allow permits an attempt covered by the decision's conditions. For a batch, name whether that decision covers the whole submitted request or particular resolved operations. The executor must implement the corresponding granularity. An evaluator that produces item-level conclusions cannot assume that a batch-only executor will apply them individually.
Deny means withholding the protected operation on the controlled path. If the gate has authority to stop a whole request before submission, it can withhold that request. If processing has already started elsewhere, a later denial may stop only remaining work. It does not establish that earlier items were unchanged. The useful statement names the operation, the point, and what was still preventable.
For the mixed-team example, a policy might reject the submitted proposal because it includes unauthorized resources. Whether the implementation can reject before any item changes depends on where evaluation occurs and what the executor supports. Do not infer all-or-nothing behavior from the word “batch.” If that behavior is required, it must be provided and verified by the actual execution mechanism.
Treat a transformed batch as a new proposal
Removing the other team's resources may reduce the requested authority, but it can also change the task's meaning. The original selection might have been wrong, the intended review might require a different set, or the user might need to know that part of the requested work remains unresolved. A smaller batch is not automatically a correct or complete result.
Where transformation is supported, identify the exact change and evaluate the resulting proposal under the applicable policy. Determine whether it still fulfills the permitted task and whether its approval conditions changed. Preserve the original proposal and the relationship to its replacement. If the executor cannot use the approved replacement reliably, returning altered parameters is not enough to establish that the original request was withheld.
Splitting a batch also changes the execution plan. The new requests need decisions at the appropriate granularity and a way to distinguish their results. If some authorized items are updated and others remain pending, report that partial completion explicitly. Do not silently resubmit the unresolved remainder under the decision for the completed subset, or assume rollback and idempotency that the interface has not established.
Ask for approval of an identifiable operation
An approval request should expose the material choice: which resources would change, what would change on them, and whose authority the executor would use. The person reviewing it must be authorized for that scope. A generic “continue” prompt does not by itself establish approval from the owner of another team's resources.
OWASP's transaction authorization guidance recommends letting the user identify and acknowledge significant transaction data. In the hypothetical batch, that means making the actual proposed scope reviewable, not merely showing the tool name. The guide's financial authorization methods are not requirements for every agent workflow. OWASP Transaction Authorization Cheat Sheet.
Pending approval must retain the proposal it concerns. If the selection changes while a reviewer considers it, determine whether the approval still applies to the version that would execute. Approval is not permission to remove the subsequent applicability check. If no authorized reviewer or supported approval mechanism exists, the system must not label an agent's assertion as the missing authorization.
Follow operations hidden behind the initial call
A tool can submit a job that later discovers resources, invokes another service, or starts a process. A check before that initial call may govern job submission while leaving later operations outside its view. Describe that limit explicitly. It is not evidence that each resulting resource access was inspected or authorized against the task.
For the batch example, a remote service might accept only a selection expression and resolve it later. A client-side gate that cannot see the final set cannot make the same item-level claim as a service evaluating each resolved target. The service's own access controls remain necessary, and a narrower client decision needs a supported way to constrain the work it delegates.
When MCP carries a tool request, its specification requires servers to validate tool inputs and implement access controls; it also recommends that clients show inputs and seek confirmation for sensitive operations. Those responsibilities do not mean every server implements the task's business authorization or evaluates hidden sub-operations. Assess the actual server and execution path. MCP Tools, 2026-07-28.
The same question applies to allowing a shell or runner: what does the check inspect, and what can the process do afterward with its environment and permissions? Authorization at the destination and isolation of the executing process have their own roles. A pre-execution hook should not be described as complete control over subprocesses, network access, or remote effects without evidence of those boundaries.
Verify the boundary with benign cases
Use a controlled environment with synthetic resources to review the design. For the example, propose a batch entirely within the delegated team, a mixed-team batch, a selection that changes after evaluation, a transformed subset, and a request still awaiting approval. These are suggested validation cases, not tests executed for this guide.
For each case, compare the proposal evaluated with what the executor consumed and what the destination reported. The result should let a reviewer distinguish a request withheld before submission from one partly processed, a replacement proposal from the original, and accepted work from completed updates. If item-level observations are unavailable, keep that limit visible rather than reporting a fully verified batch outcome.
Include the evaluation-unavailable path in the review. A system that continues under that condition has a different preventive boundary from one that withholds the operation. Record the behavior that actually applies and the destination authorization that remains. The audit trail guide explains how to specify the relationships and evidence limits needed for those conclusions.
What the reviewed KonaSense integration can establish
In the reviewed Claude Code PreToolUse implementation for Kona for Agents, the adapter constructs deny or approval-request responses from policy decisions and can return updated tool arguments in the applicable Allow path. The changed-input response emits an explicit Allow decision; it should not be described as preserving every native permission prompt. Applying the response depends on the host.
That implementation falls back to Allow when policy evaluation fails. The source therefore does not establish an always-blocking control, item-level governance for the hypothetical batch, or authority over a remote executor's later operations. Verify the installed host, integration, and tool behavior for the particular effect being governed. The example and design options in this guide are not results from testing that integration.