Skip to content

Point of view

Why Prompt-Level Governance Is Not Enough for AI Agents

The request can remain unchanged while the operation reveals information that was unavailable to its first reviewer.

A prompt review can assess the request and context it receives. It cannot, by itself, verify the contents of an archive that will be assembled later. When an agent prepares an operation, governance needs to account for material facts that the initial assessment did not examine.

That limit does not make prompt inspection useless. It makes the scope of its conclusion important. A request accepted for a permitted purpose should carry its conditions into the work that follows, rather than becoming blanket authorization for every action used to complete it.

The operation contains facts the prompt did not settle

Consider a hypothetical task: attach a diagnostic bundle to a support ticket. Assume the support destination is approved for an operational status summary, while the organization's policy requires a separate decision before sharing certain application request excerpts. The agent is asked to prepare and attach the bundle; its actual contents are assembled after the initial request is reviewed.

In this example, the resulting archive contains both the status summary and those restricted excerpts. It has been prepared but has not been uploaded. These are hypothetical conditions, not customer data, an observed incident, a KonaSense integration, or an executed test.

The request has not changed. The available evidence has. A reviewer that saw the task but not the assembled archive could assess the purpose of seeking support without establishing that every included file was permitted for that destination. The contents now matter to the proposed attachment, even if the original wording appeared routine.

No prompt injection is needed to produce this gap. A legitimate collection step can produce material that needs a more specific handling decision. The AI agent security pillar examines malicious influence and other threats; this example isolates the limits of an assessment made before the relevant material was examined.

An early decision needs an explicit scope

An initial decision should state what it resolved and what conditions remain. For the diagnostic task, accepting the support purpose could establish an allowed destination and permitted categories of information. It should leave the unexamined archive subject to those conditions, not treat the phrase “diagnostic bundle” as evidence about its contents.

NIST's AI RMF Playbook calls for documenting intended purpose, use context, assumptions, and limitations. Our application of that principle is to keep the basis of a governance decision visible as the workflow develops. The Playbook does not prescribe this archive example or an inspection mechanism. NIST AI RMF Playbook, MAP 1.1.

Prompt-level assessment need not be limited to the typed sentence. If an initial evaluator receives relevant files, destination details, and reliable policy context, its conclusion can reflect what it actually examines. The limit is evidence, not the name of the interface. Material added afterward still needs an applicable decision; repeating the same prompt would not inspect that addition.

Review the resolved action without discarding the first decision

The earlier review remains useful: it supplies the accepted purpose and handling conditions. The next decision concerns whether the prepared attachment fits them. In the hypothetical bundle, permission to share the status summary does not answer whether the request excerpts may be included.

OWASP recommends validating authorization on every request. Applied here, the proposed upload needs authorization for its actual material and destination, rather than inheriting permission solely from acceptance of the initial task. This is an application of the recommendation to the example, not a claim that a particular product performs the check. OWASP Authorization Cheat Sheet.

The workflow could prepare a narrower bundle if that still fulfills the support need, or seek a decision from someone authorized to permit the restricted material. Those alternatives require their own assessment; removing files does not automatically preserve usefulness or make the remainder approved. The pre-execution governance guide explains how to connect a resolved proposal to a control that can still withhold its effect.

Keep unverified material visible in the decision

Knowing that an archive exists is different from knowing what it contains. If the available inspection cannot establish the relevant contents, retain that limitation in the decision. A permitted filename, an approved destination, or a successful packaging step does not supply the missing information.

The organization needs a defined way to resolve the gap: inspect the material through an authorized process, restrict what can be collected, obtain an applicable exception decision, or withhold the attachment when required. Which route is appropriate depends on its policy and available controls. Asking the agent to describe the archive does not automatically provide independent evidence of its contents.

This assessment concerns the proposed transfer. It does not establish that collecting every source file was authorized, nor can a later upload decision reverse earlier access or disclosure. Runtime AI governance explains why the effect being governed and the point where a decision can apply must remain explicit.

Make the control claim match what was checked

When reviewing this workflow, distinguish acceptance of the support request from assessment of the prepared attachment. State which material and destination were examined, which conditions applied, and what remained unresolved. If the archive changes afterward, the previous review cannot be credited with checking the added material.

A useful handoff preserves both decisions: what the initial review permitted and how the resolved operation was assessed against those limits. Evidence that a proposed upload was evaluated is still distinct from evidence that the applicable decision constrained it. The AI agent governance pillar places those responsibilities within the broader execution path.

KonaSense's position is that governance claims should follow the scope of the evidence and the operation being controlled. When evaluating Kona for Agents, identify which context reaches the relevant decision point and what happens when material information is unavailable. Calling a workflow governed should require more than showing that its first prompt was accepted.