The KonaSense Runtime AI Governance Framework

The KonaSense Runtime AI Governance Framework is an eight-function model for examining how an organization connects knowledge of AI use, accountable policy decisions, effective controls, and reviewable evidence. It helps a team identify the responsibility or connection missing from a specified governance outcome.

The functions are Discover, Identify, Observe, Evaluate, Decide, Enforce, Approve, and Evidence. This is KonaSense's proposed model for program analysis. It is not an external standard, a certification scheme, or evidence that a product implements all eight functions. Its usefulness must be assessed against the organization's actual workflows and available evidence.

Start with a governance outcome and a boundary

Choose a concrete outcome before assessing the functions. “Govern our agents” is too broad to determine which information or control is missing. For a hypothetical maintenance workflow, “Do not send a maintenance order to an external contractor until the authorized site owner approves its scope” identifies a protected operation and an authority requirement.

Define the applications, people, agents, environments, and paths included in the review. Name the operation being governed and the relevant destination. Record exclusions so that a conclusion about one managed path does not silently become a conclusion about every way to perform the work.

NIST's AI RMF Playbook, MAP 1.1, calls for understanding the intended purpose, context of use, assumptions, and limitations. Those principles support setting the review boundary; they do not define this eight-function model.

AI usage governance establishes the conditions for permitted use. This framework asks which functions make those conditions actionable and verifiable within the chosen boundary.

Read the functions as connected responsibilities

The order of the names is not a universal execution sequence. An inventory may exist before a workflow begins, identification may be refined during it, and observations can inform later evaluations. Several functions may run in one component or be distributed across teams.

Approval is conditional. When policy requires it, the protected operation must remain pending until an authorized decision applies. Approval information feeds the decision and its applicability check before release; placing Approve after Enforce in the list does not put human authorization after the effect. Evidence accompanies the functions, including decisions that produce no action.

Separate the owner accountable for a function from the mechanism performing part of it. A service can evaluate a policy without owning the business rule. An operations team can maintain an integration without being authorized to approve an exception. NIST GOVERN 2.1 supports documenting roles and communication paths; the assignments below are responsibilities to resolve in a particular organization.

The eight functions

1. Discover

What AI applications, agents, coding tools, and usage paths are in scope? Discovery establishes what the program has found and where it looked. Application records, deployment configuration, user reports, and observations may contribute different parts of that picture. Preserve their sources and coverage limits instead of merging them into an unsupported claim of completeness.

The inventory owner needs help from the teams that operate those surfaces. A reviewable result identifies the known systems, their owners, the paths examined, and unresolved areas. NIST GOVERN 1.6 addresses maintaining AI system inventories and assigning responsibility. A populated inventory still does not establish that every use of each listed application is approved.

2. Identify

Whose activity is this, and which enterprise context applies? Identification connects activity to relevant users, devices, agents, applications, and sessions. It also distinguishes the requester, the person or resource affected, and the identity used to execute an operation. A shared service account can be known while the initiating user remains unresolved.

Identity and application owners must establish the sources and mappings on which these associations rely. The result should let a reviewer follow an activity reference to the relevant identities, or see precisely which association could not be established. A name supplied by an agent is not automatically a verified identity, and a verified identity is not itself authorization for the task.

3. Observe

Which activity and conditions can the program actually see? Observation provides signals needed to understand usage, sessions, tool requests, data movement, risks, and actions. Select signals for the question being asked. A record of a proposed tool request and a destination record of a completed change answer different questions.

The teams responsible for instrumentation and collection need to specify the source, collection path, access restrictions, and known gaps. Their reviewable output is a bounded account of available observations, including missing or delayed information. Collecting more content is not automatically more useful; unnecessary prompt or response capture can create additional sensitive copies. The Evidence function determines how the relevant observations support a reviewable conclusion.

4. Evaluate

What do the applicable policy and risk criteria say about this context? Evaluation needs the relevant rule version, the operation or use being examined, and the facts that affect the answer. Keep a declared purpose, an observed attribute, and an unresolved condition distinguishable. Otherwise, an assumption can enter the evaluation disguised as evidence.

The policy owner defines the criteria; the owner of the evaluation mechanism is responsible for applying them as intended. A reviewable evaluation identifies the criteria assessed, the facts used, and material uncertainty or missing context. This makes it possible to distinguish an unsuitable rule from incorrect application of a suitable rule. Evaluation may be automated, human, or combined; the model does not require every organizational judgment to be automated.

5. Decide

What response is authorized for the evaluated use or operation? A decision may allow, deny, require approval, request a supported transformation or redaction, alert, or record. Its meaning must be explicit. An alert can request attention without withholding an operation. Allow can authorize an attempt without establishing its success.

Assign authority to select the response, including who may accept an exception and within what scope. The result is an identifiable decision tied to the evaluated context and its conditions. A failure to obtain a decision must remain distinguishable from a decision to permit the operation. The runtime governance pillar develops the validity and failure contracts that this responsibility needs to specify.

6. Enforce

Which point can apply the decision to the protected operation? Enforcement depends on a mechanism with the necessary authority and a way to associate the decision with what it will control. A policy result sent to another component is not yet evidence that the component respected it.

The owner of the control point must establish its supported responses, affected paths, and behavior when the decision cannot be applied. The reviewable result describes what was applied and what remains unverified, at the relevant boundary. Where authorization must precede execution, OWASP's Transaction Authorization Cheat Sheet, section 2.8 describes a final authorization gate tied to execution. This principle does not establish preventive control over paths outside that gate.

7. Approve

Who may make the human decision that this operation requires? Approval needs an identifiable proposal, the material facts for review, and a person authorized for that scope. Someone able to explain the business purpose may not be authorized to approve access to another team's resource. Missing technical evidence is also not repaired merely by asking that person to click again.

The relevant business or resource owner defines the delegation and exception authority. A reviewable result preserves who decided, what they approved or rejected, and the applicable conditions. Pending, unavailable, or expired approval must remain distinguishable from permission. NIST GOVERN 3.2 supports differentiating human roles in oversight; it does not require a person to approve every AI action.

8. Evidence

What can a reviewer establish about the decision, its application, and the outcome? Evidence connects records from the relevant functions while retaining their source, meaning, and limitations. A denied request can have decision evidence with no attempted action. A dispatched request can have an unknown destination result.

Evidence owners and investigators need to agree on the review question, necessary records, permitted access, and retention. Their output should distinguish supported findings from unresolved questions and identify what would resolve each material gap. The AI agent audit trail guide explains the underlying relationships in detail. A protected record can still be incomplete, and a collection system cannot establish an event that its sources never observed.

Diagnose a gap without mistaking it for another one

Hypothetical design review: a facilities team proposes an assistant that prepares maintenance orders from employee reports. Internal preparation is permitted. Before an order is sent to an external contractor, the site's authorized owner must approve the work and recipient. These are conditions invented for a design exercise, not an existing integration, incident, or test result.

Suppose the design contains an application inventory entry, a shared dispatch account, a policy evaluator, a human confirmation prompt, and a delivery queue. Those components do not yet establish the required outcome. The review must examine the relationships between them.

The first gap is not solved by adding another application inventory row. The second is not solved by retaining a longer conversation. The third does not automatically mean dispatch failed or that an approval control was bypassed. Each gap requires an owner able to resolve the specific responsibility and evidence suited to that question.

The discovery-to-enforcement analysis examines a hypothetical coordination gap in which a policy condition has no established source or responsible owner.

The architecture guide helps locate the components and trust boundaries once a relationship needs engineering work. The framework keeps that work connected to the governance outcome it is intended to support.

Turn the diagnosis into a bounded review decision

Distinguish an absent capability or assignment from an unverified result. If no component can withhold contractor dispatch, the required enforcement point is absent from the proposed design. If a gate is specified but its behavior has not been examined, prevention is unverified. Those findings should not receive the same description or remediation.

Use “not applicable” only with a scope-based reason. A workflow may not require human approval for a particular low-risk operation under its established policy. Someone still owns that policy choice, its limits, and review when the conditions change. The label must not hide an unresolved authority question or make the responsibility for governance disappear.

For each material gap, record the affected outcome, the missing relationship, the person able to resolve it, and the observation or decision needed to close it. Assign an interim operating condition where needed. In the hypothetical review, that might mean allowing internal preparation while keeping contractor dispatch outside the pilot until its approval path is established. This is a proposed restriction, not a control tested here.

Prioritize by consequence and uncertainty. A path that could perform an unauthorized external operation may need attention before a less consequential reporting gap. Uncertainty about that path may itself limit what can responsibly be approved. Do not turn the number of completed functions into a fabricated maturity score or use an aggregate score to obscure one missing control required by the outcome.

The AI Agent Governance Maturity Model offers six levels for reviewing what a scoped program can demonstrate, with evidence requirements and explicit limits.

Revisit the assessment when the workflow, authority, information sources, or control mechanisms change. NIST MANAGE 4.1 addresses monitoring and review mechanisms after deployment. The practical question here is which earlier conclusions remain supported and which relationships need to be checked again.

Apply the model to a real implementation

Use the same questions when reviewing Kona for Agents, Kona for Browser, or the organization's surrounding processes. Name the actual integration and protected operation before assigning a function to a component. Product selection does not establish which responsibilities are fulfilled in a particular installation.

The useful result is a review decision a team can act on: which use is covered, which decision can affect which operation, who owns an unresolved condition, and what evidence is still needed. The eight functions provide a structure for reaching that result; they do not replace the evidence required to support it.