An approved model can still be used to request an unauthorized action. When an agent turns model output into an operation against another system, governance must reach the authority used to carry out that operation.
The consequential change is organizational. An AI program may determine that a model is suitable for a task. A business owner may approve the purpose of the workflow. The owner of the destination system still needs to establish what that workflow may read or change. Those decisions have different scopes, even when one team performs several of them.
Moving governance from models to actions means making those boundaries explicit. Model evaluation remains necessary. Its approval should travel with conditions that the people responsible for execution can interpret and enforce.
What model and provider approval still resolve
A model review can establish whether its behavior and limitations are acceptable for an intended use. A provider review can examine data handling, service dependencies, and contractual terms. Together, they inform whether the organization should use that model or service, and under what conditions.
These decisions remain valuable after deployment. If a workflow changes from summarizing public material to interpreting internal records, its earlier evaluation may no longer answer the relevant questions. Governance needs a way to bring that change back to the appropriate reviewers.
The limit is that suitability does not confer operating authority. An evaluation can support using a model to prepare a recommendation without establishing permission to execute it. The broader AI governance program must connect those two decisions without collapsing them into a single “approved” label.
What an agent adds to the approval decision
An agent can select a sequence of operations while carrying out a task. That makes the scope of the delegation important: approving the goal should not leave the agent's available authority undefined.
Hypothetical example: a team asks an agent to prepare a financial reconciliation using synthetic data in an isolated test workspace. A reviewer checks the result and approves its quality. The agent then proposes writing that result to the organization's system of record.
The calculation has not become less accurate. The proposed use of it has changed. A correct reconciliation of test data is still test output; approving its quality does not authorize an entry in official records. The proposed write needs its own decision about the destination, the identity performing it, and the scope of that identity's authority. Until those conditions are established, it should remain outside the permitted workflow.
The person sponsoring the experiment may have authority to approve the trial while lacking authority to permit writes to that system. The destination owner may authorize a narrowly defined operation while lacking authority to approve the model for a different use. Neither approval should silently expand the other.
This is where an approval record needs precision. “Reconciliation agent approved” leaves the boundary open. “May prepare results from synthetic data in the test workspace; no writes to the system of record” gives both the experiment owner and the engineering team a decision they can apply.
Why the action is a useful control point
A concrete action exposes the authority the workflow is about to exercise. The organization can evaluate the requested operation against the destination owner's rules, using context that can be verified rather than accepting the agent's explanation as permission.
OWASP's guidance on Excessive Agency recommends enforcing authorization in downstream systems instead of relying on an LLM to decide whether an action is allowed. For an enterprise program, that has a direct implication: approval by the AI team should not override authorization at the destination.
This does not require a person to approve every routine operation. A destination owner can approve a defined class of actions through policy, with bounded permissions and conditions for exceptions. The runtime control then checks whether the actual request fits that delegation. A request outside it needs a different decision, even if the task that led to it was approved.
The AI agent governance pillar explains the technical execution chain and controls in more detail. The management issue is who has authority to set each limit, and who can change it.
Connect observation, decisions, enforcement, and evidence
Observation makes a proposed operation reviewable. It should give the responsible team enough verified context to determine which policy applies. Missing context, such as an unknown destination identity, should be visible in the decision rather than filled in from the agent's assertion.
A decision translates the owner's policy into a permitted scope, a denial, or a request for an authorized approver. The approval mechanism needs to recognize that approver's authority. The person who initiated the task is not automatically entitled to approve every operation it generates.
Enforcement gives that decision an effect on execution. The team operating the integration must establish where a disallowed request is stopped and which destination permissions continue to apply. A decision recorded in an approval system leaves this responsibility unresolved if nobody owns its application in the execution path.
Evidence then supports review of those responsibilities. Assign an owner who can retrieve the relevant policy, decision, approval, and available execution result, and explain gaps. A record of permission and a record of a completed write answer different questions. Keeping them distinct prevents a governance report from overstating what was verified.
What CISOs should change in the approval process
Start with decision rights. The NIST AI RMF Playbook, GOVERN 2.1 and 2.3 calls for clear roles and communication around AI risk, with executive responsibility for development and deployment risk decisions. Our recommendation is to carry that clarity into the handoff between an AI use-case approval and the owner of each affected system.
An approval request should state what authority it grants and what remains outside it. The central program can record the accepted use and model conditions. The destination owner can specify the operations and permissions allowed there. The team operating the workflow can document where those constraints apply and who maintains the evidence. Small organizations can assign several responsibilities to the same person while still recording the separate decisions.
Change review should follow changes in authority, too. If the test workflow gains a credential capable of writing to official records, the destination authorization needs review even if the model, provider, and prompt stay unchanged. Conversely, a model change can require a suitability review even when the workflow's permissions remain fixed. A single change process can route each question to the responsible owner.
Exception handling needs the same discipline. Name who can approve an expanded scope, how long that approval applies, and how the original limits are restored. The owner accepting the risk should also know what happens when a policy service or approval mechanism is unavailable. That behavior must be established for the actual integration; neither an approval ticket nor a product category name proves it.
The KonaSense point of view
KonaSense's position is that governance should follow delegated authority into execution. A useful discussion of agent controls starts with the action the organization intends to permit, the person accountable for that permission, and the place where it can be enforced.
That is the basis for evaluating Kona for Agents: identify the specific agent integration, examine its decision path, and verify its coverage and failure behavior. The financial scenario above illustrates an authorization boundary; it is not a claim of a KonaSense integration with financial systems. Product evaluation should make the implemented boundary concrete for the teams responsible for it.