AI Agent Governance: Control What Agents Can Access and Do

What is AI Agent Governance?

AI agent governance is the set of policies, controls, approvals, and evidence mechanisms used to determine what AI agents may access, which tools they may invoke, and which actions they may perform.

For a concise explanation of delegated authority, read the AI agent governance glossary entry.

For a concise definition of the system being governed, read the AI agent glossary entry.

Its operational question is specific: does this agent have authority to perform this action, with these inputs, against this destination, in this context? Answering it requires more than knowing the model or application name. The organization needs a decision owner, an effective control point, and evidence of the outcome.

Agent governance sits within the broader AI governance program. It focuses on delegated actions, while the broader program also addresses model suitability, organizational responsibilities, and the permitted uses of AI.

Why agents change the security boundary

An agent can turn model output into a request against another system. The security boundary therefore includes the identities, credentials, tools, and data access used to carry out that request. A reliable answer from the model does not establish authority to act.

OWASP describes Excessive Agency in terms of excessive functionality, permissions, or autonomy. Its guidance recommends enforcing authorization in downstream systems instead of relying on the model to decide what is allowed.

For the organization, that means reviewing the authority delegated to the workflow. A prompt that says “do not change production” should be backed by controls on the credentials, destinations, and operations available to the agent.

The AI agent security pillar examines how untrusted inputs can influence the use of available tools and credentials, and which effects a threat model should constrain.

From prompts to actions

Hypothetical example: an engineer asks a coding agent to update a dependency and prepare a patch. The agent may need to read files, edit a dependency manifest, and run a test command. Publishing a package or changing a production service would be a different delegation of authority.

The original request establishes the goal. It does not automatically authorize every step the agent might select to reach it. Governance should identify the approved workspace, allowed operations, acceptable data destinations, and conditions that require review.

Suppose a test fails and the agent proposes uploading the repository to an external diagnostic service. The business goal has not changed, but the proposed data transfer has. A useful control evaluates that new action rather than treating the initial task approval as permission for the entire sequence.

The term agentic AI describes how choices and actions are delegated within such a workflow.

The AI agent execution chain

An execution chain connects a user or trigger to a change in a system. The steps below describe a conceptual architecture, not a fixed implementation or a KonaSense product diagram. An agent may repeat the cycle, make parallel requests, or use different models.

1. User or trigger: a person, scheduled process, or event initiates work under a defined owner and purpose.
2. Agent and model: the agent assembles context and uses a model to propose a next step. Context may include instructions, retrieved material, and earlier tool results.
3. Tool selection: the proposal becomes a tool request with an operation, arguments, and destination. This is the point at which “update a dependency” becomes a concrete file edit or command.
4. Policy evaluation: a control evaluates the proposed request using the context it can verify. The outcome can permit the request, deny it, or require approval.
5. Action and evidence: a permitted request may proceed to the external system, subject to its own authorization. A denied request stops at the control. A request awaiting approval remains pending. Record the decision and, if execution occurs, its observed result.

Allowing a request does not prove it succeeded. The target can reject it, a tool can fail, or the outcome can remain unknown. A denial also deserves an evidence record even though the action did not execute.

Where MCP fits

The Model Context Protocol architecture describes clients and servers exchanging context and exposing capabilities such as tools. MCP is one way an agent application can access a tool; agent workflows can also use built-in functions or direct APIs.

MCP has an authorization specification for HTTP transports. That protocol-level capability does not determine which business actions an organization should permit. The tools specification also requires server access controls. Review the actual server, tools, permissions, and implementation rather than treating an MCP connection as evidence of a governed workflow.

What organizations need to govern

The useful unit of review is a proposed action within a delegated task. The following questions turn a broad policy into something a security architect and a workflow owner can assess together.

Identity and delegated authority

Identify the initiating person or service, the agent runtime, and the identity used at the destination. Those identities can differ. Record who owns the workflow and whose permissions the tool actually exercises. A service account with broad access should not silently enlarge the authority of a narrowly approved task.

Context and data

Determine which workspace, account, environment, and data sources the decision depends on. Distinguish instructions from material supplied as context. A repository file or tool result can contain text that looks like a new instruction; its presence in context does not make it an authorized request.

For the hypothetical dependency update, the allowed repository and destination matter as much as the edit operation. Separately decide which content the governance system needs to inspect or retain. Avoid copying credentials or full source files into evidence merely because they are available.

Tool access and actions

Review the operation and its parameters together. Permission to use a shell is much broader than permission to run a particular test in a particular workspace. The current definition of that test matters too: a command name is insufficient if the script it invokes can change.

Ask where the restriction is enforced. The agent interface, a tool wrapper, the operating environment, and the target service may each hold part of the control. Document unmediated paths so a decision at one integration is not mistaken for control over the whole environment.

Approvals and evidence

Specify which requests can proceed under standing policy and which need a person to decide. Link an approval to the action and context reviewed. Preserve its scope alongside the policy decision and the observed result. These records should show what was authorized without suggesting that authorization alone proves execution.

Design-time governance vs runtime governance

Design-time governance establishes the workflow's permitted capabilities before use. Runtime governance applies decisions while the workflow operates. Both are necessary: a runtime check depends on the authority and context defined for it.

In the hypothetical example, limiting the agent's credentials to a development repository reduces its initial authority. Evaluating a proposed upload adds a decision about the specific destination. Neither control makes the other redundant.

For the distinction between policy configuration, decisions, and enforcement, see the AI control plane glossary entry.

Observe vs control

Observation provides evidence about activity. Control participates in deciding whether an action can proceed. A system may do one, both, or neither for a given event type. Verify the timing and effect of the integration rather than relying on a general label such as “agent visibility.”

Pre-execution vs post-execution

Pre-execution governance evaluates a proposed action at a point that can withhold permission. Post-execution observation receives evidence after an action or attempt. It can support investigation and a subsequent response, but it cannot prevent the event already completed.

For the dependency update, a pre-execution decision can govern the proposed file write. A later tool result can establish whether the write succeeded. A subsequent rollback is another action with its own authorization and risks; recording an event does not make the original action reversible.

Decide explicitly what happens if evaluation times out, context is missing, or the approval service is unavailable. A control that permits continuation on failure has a different operating boundary from one that stops the request. Test and document the behavior the workflow actually uses.

To assess the evidence, examine why observing an agent is not the same as governing it.

Human-in-the-loop

Human review is useful when the reviewer can understand the action and has authority to decide. Show the operation, destination, relevant parameters, reason for escalation, and expected effect. “Allow agent to continue?” provides little basis for a decision if those details are hidden.

Define whether approval covers one action or a bounded class of actions. A material change to the destination, input, identity, or scope should trigger reevaluation under the organization's policy. An approval should not follow a changed request simply because the same agent session is still running.

For the hypothetical upload, the reviewer needs to know what would leave the repository and where it would go. If that cannot be established, record the missing information and keep the request unresolved under the chosen policy. Do not silently turn lack of evidence into consent.

The analysis of human-in-the-loop governance examines what reviewers can decide and why accepting risk is different from verifying a fact.

Audit trails for agent actions

An audit trail should let a reviewer connect the delegation, request, decision, and observed outcome. The agent action definition distinguishes the operation being reviewed from its proposal, attempt, and observed result. The OECD accountability principle calls for traceability across data, processes, and decisions, appropriate to context. A practical record for an agent action can include:

• The initiating identity, workflow owner, session, and request identifier.
• The tool, destination, relevant input parameters, and context available to the decision.
• The policy version, decision, reason, and any scoped approval.
• The attempted execution, reported outcome, timestamps, and known gaps.

This is an editorial example of an evidence structure, not a required universal schema. Retention, access, and data minimization should match the investigation need. Protect the records from unauthorized changes, but do not claim immutability or non-repudiation merely because a log exists.

Keep “requested,” “allowed,” “attempted,” and “completed” distinct. If a result is missing, the outcome remains unknown. Correlation helps reconstruct the sequence; it does not manufacture an event that was never observed.

The AI agent governance architecture guide follows these records across the runtime, tool service, and destination, including cases where a response is lost.

How KonaSense governs AI agents

Kona for Agents connects supported coding-agent workflows to policy evaluation through runtime integrations. The control available depends on the agent, event type, installation, and configuration.

In the PreToolUse path of the Claude Code adapter implementation reviewed for this guide, a policy denial maps to a hook response denying the tool call, and escalation maps to a request for user approval. That implementation falls back to Allow when policy evaluation fails. This behavior should be considered when deciding which actions require an independent control at the destination.

Evaluate the installed runtime, version, hook registration, permissions, and failure behavior for the intended deployment. An integration's ability to receive events should not be treated as proof that it can stop every action. For the underlying terminology, AI Agent provides a complementary reading.

FAQ

Is AI agent governance the same as agent observability?

Observability supplies information about agent activity. Governance also determines authority, responsibilities, approvals, and controls. Observational evidence can support a governance decision without being able to enforce that decision before the action.

Does every tool call need human approval?

Define approval requirements by the action's scope and consequences. Standing policy can cover bounded operations, while requests outside that scope require a designated decision. The approval model should be explicit enough to test and should not depend on the agent's description of its own safety.

How can a team verify that an agent is governed?

Choose a representative workflow and examine a permitted action, a prohibited action, an approval request, and a control failure. Check where each decision took effect and whether its evidence matches the result. Record what was not covered. Passing those checks supports the tested scope, not a claim about every action or runtime.