AI Agent Governance Architecture: From Prompt to Action

An AI agent governance architecture defines the components, trust boundaries, and contracts that connect a proposed agent action to policy evaluation, enforcement, and evidence of what happened. It identifies where a decision can be made, which component can apply it, and what must pass between them.

This guide uses a conceptual architecture to examine those handoffs. It is not a required design for every agent or a diagram of a deployed KonaSense system. The AI agent governance pillar establishes the broader question of delegated authority; the architecture makes that authority actionable at specific boundaries.

Start with a concrete change to another system

Hypothetical example: an employee asks a service-desk assistant to add an on-call contractor to the current incident-response workspace as a viewer. The assistant proposes a workspace.add_member operation with a workspace identifier, a contractor account identifier, and the role viewer. The tool name and workflow are illustrative, not a real integration or customer case.

The proposed design requires the account to match the organization's directory record, the contractor to be assigned to the incident, and the workspace owner to approve the membership. It does not authorize administrator access through this workflow. These are policy choices for the example, not universal rules for incident response.

Keep three identities separate: the employee making the request, the contractor receiving access, and the service identity used by the executor. The executor's credential might technically permit broader membership changes than this task authorizes. Neither possession of that credential nor a clear employee request establishes the workspace owner's approval.

The architectural problem is to carry those distinctions to the component that submits the membership change. If the policy service sees viewer while the executor sends administrator, a correctly evaluated proposal has not governed the operation that followed.

Trace the proposal before drawing the action

The sequence follows a user or trigger through the agent runtime, model, decision-context assembly, tool selection, proposed tool call, policy decision, and permitted action. Its branches matter: Deny ends without the protected action; Require Approval leaves the action pending. Decision evidence exists on those paths even when no operation is attempted.

Context also exists before model inference. The runtime supplies instructions, the user's request, and whatever other material the application permits. Context Assembly in this sequence means gathering facts for the action decision, such as the resolved account and workspace. It does not mean the model ran without context. Implementations may gather these facts earlier or enrich them as a tool proposal becomes concrete.

Likewise, Tool Call before Policy Decision means a proposed or intercepted invocation whose protected effect has not occurred. It does not require sending a request to a remote tool before evaluating policy. If the evaluation happens inside a tool service, the request may have arrived there while the membership change remains withheld.

The stages are logical responsibilities, not a requirement for a separate service at each step. A runtime can combine several stages or repeat the cycle. What matters is locating the boundary before the effect being controlled and specifying which facts and decisions cross it.

Where can policy be evaluated?

Policy can be evaluated wherever the architecture exposes a relevant request and can connect the result to an effective control. Different locations have different authority and context.

At the runtime, a check can examine the proposed tool, the task, and the arguments before dispatch. This is useful for identifying a request outside the delegation, such as administrator access in the hypothetical viewer workflow. It governs only paths that pass through that check.

At a tool wrapper or service, evaluation can use the resolved resource and the identity that will call the destination. That location may know more about the actual request than the model does. Its contract must still identify whether the service can withhold the external change and whether other callers bypass it.

At the destination, access controls determine whether the executing identity can change that resource. The OWASP Authorization Cheat Sheet recommends validating permissions on every request and placing access checks where client-side manipulation cannot decide resource access. A runtime policy result does not replace those destination checks.

In the workspace example, the runtime can limit the proposed role, the tool service can verify the account and approval, and the destination can authorize the service identity. This distribution is one design option. Document which component owns each check and which result the next component must respect; do not assume that placing checks in several locations makes them consistent.

What context should a decision use?

Use the facts needed to decide the specific action, together with their sources and limits. A full conversation is not a substitute for resolving the account that would receive access.

Crossing a trust boundary changes what a component may rely on. A model-generated account name is a candidate to resolve, not a verified directory identity. A note saying “approved by the owner” is not an approval record. Define how the receiving component verifies each claim, including authenticated communication where appropriate; a field name alone supplies no assurance.

Bind the evaluation to the request the executor will use. If account resolution, the workspace, the role, or the executing identity changes, determine whether the earlier decision still applies. Runtime AI governance examines this validity contract in more depth. A shared request identifier helps locate records, but does not itself prevent a request from changing.

What changes when MCP is involved?

MCP introduces a host, client, and server into the path used to obtain context or invoke a tool. Its architecture documentation separates the protocol from how the application uses models and manages context. The policy and execution responsibilities still need an implementation.

For an MCP version of the hypothetical workflow, identify the configured server, selected tool, concrete arguments, and identity presented to that server. A tool name is not a complete destination identity. The MCP tools specification scopes tool-name uniqueness to a server and warns that tool annotations are untrusted unless supplied by trusted servers. Descriptive metadata does not establish the workspace owner's authorization.

The MCP authorization specification defines an authorization flow for HTTP transports; authorization support is optional for MCP implementations, and that flow does not apply to STDIO. Access to a protected MCP server and authority for a particular membership change remain separate questions. Review the server's downstream credential and access checks rather than inferring them from the connection.

The tools specification also requires server input validation and access controls. In the example, the service must assess the requested workspace and account before making the protected change. Whether it evaluates policy itself or relies on an upstream decision, specify how it receives and validates the applicable authorization. Do not place the only effective check after the membership update.

What is visible before execution, and what comes later?

Before execution, an integration may see the requested tool, arguments, task context, selected identity, policy result, and approval state. Its actual visibility depends on where it sits. These facts describe a proposal and the conditions for attempting it; they do not establish that the destination accepted the change.

For the workspace request, the pre-execution record can identify the intended contractor and role. Only observations after an attempt can establish the response to that attempt and any resulting state. A tool-service response may report an API error, success, or a missing response. The receiver must understand what that report means before turning it into a conclusion about membership.

An authorized read of the workspace might later show the contractor as a viewer. That establishes the observed state at that time. Without evidence linking the change to the attempted request, it does not prove which attempt created the membership or whether it existed beforehand. Keep state observations and causal conclusions distinct.

MCP's tool error reporting distinguishes protocol errors from tool-execution errors. Preserve the distinction between a rejected request, a reported execution error, and an absent result. None should be silently rewritten as “the requested change did not occur” without evidence supporting that conclusion.

When is human approval useful?

Human approval is useful when a designated person has relevant judgment and authority that the standing policy does not supply. In this example, the workspace owner decides whether the contractor should receive access for the incident. A generic confirmation from the employee who requested access would not satisfy that requirement.

The review should show the resolved contractor account, workspace, proposed role, incident assignment, and identity that will perform the change. Identify any missing fact. An approval interface that only asks whether the agent may continue hides the decision the owner is supposed to make.

While review is pending, the executor withholds the membership change. Rejection ends that proposal. Valid approval permits a subsequent attempt only if it still covers the request and the remaining policy conditions hold. A role changed to administrator is a different proposal, not a continuation licensed by the viewer approval.

The approval path must also specify how the executor learns the outcome. An approval written to a store but never received by the waiting component cannot be assumed applied. Conversely, receipt of an approval message does not prove that the destination accepted the membership change. Keep review completion, permission to attempt, and execution outcome separate.

Design for failures between components

A failure matters according to the boundary it crosses. If policy evaluation fails before dispatch, the executor needs a defined failure response. In the hypothetical workflow, required owner authorization is still required; a timeout does not create it. Record the unavailable check and what the executor did.

If a decision was emitted but its response was lost, the waiting component may not know the verdict. Correlation can help recover the decision, but recovery must establish that it applies to the same request. An AI control plane can coordinate decisions without making communication loss impossible.

A lost response after dispatch is a different problem. Suppose the membership API receives the request but the tool service times out. The membership might have changed. Before retrying, determine what can be established through authorized status or state checks and what the API guarantees about repeated requests. Do not assume that retrying is harmless, atomic, or idempotent merely because the operation is called add_member.

Changes made during recovery also need evaluation. Switching credentials, choosing another workspace, or routing through a different server can change the authority under which the attempt operates. The failed path's approval must not silently authorize a materially different request.

What should be logged across the handoffs?

Record enough to connect the proposed action, decision, executor behavior, and observed result. Define who emits each record and what the record establishes. A decision event comes from the evaluator; a dispatch event must come from a component that actually observed dispatch.

For this example, preserve a reference to the initiating task, the relevant identities, workspace, role, context sources, applicable policy, verdict, and approval state. If an attempt occurs, connect the executor's handling to the destination response and any later state observation. Denied and pending requests still need their own decision evidence, with no fabricated action event.

Keep secrets out of the record. Identify the executing credential by an appropriate reference rather than copying its token, and retain only the input content needed for review. Restrict access to approval and activity records. Define retention and protection against unauthorized changes without claiming that an ordinary log is immutable.

Record timestamps with their source and correlate requests across components. Ordering by wall-clock time alone cannot repair missing events or prove causal order across unsynchronized systems. When the result is not known, preserve that state and the reason. A trace that ends at an adapter response should not imply an acknowledgment from the destination.

Use the AI agent audit trail guide to specify each record's source, relationships, and limits for investigation.

Review the architecture with explicit outcomes

Use a controlled environment and synthetic accounts to examine the handoffs before relying on them. For the hypothetical workspace, the review should include a viewer request with valid owner approval, an administrator request outside the workflow, a pending approval, an evaluation failure, and a lost result after dispatch. These are proposed validation cases; no such tests were executed for this guide.

For each case, inspect what the executor actually sent or withheld and compare it with the proposed request and decision. Establish which alternative paths were examined. A successful case supports the tested configuration and operation, not universal control of every tool or agent.

How KonaSense fits into these boundaries

The reviewed Claude Code PreToolUse path for Kona for Agents connects a proposed tool operation to policy evaluation. The adapter can return a tool-use denial, a request for user approval, or updated tool arguments. Those are adapter responses, not proof that the host applied them or that an external action succeeded.

The reviewed implementation falls back to Allow when evaluation fails. Other hooks map decisions differently: escalation does not always become an approval request, and added context is not necessarily a replacement of the original input or output. The workspace-owner review in this guide is a conceptual requirement, not a claim about an available KonaSense approval workflow.

The reviewed Browser submission paths and OTLP ingestion paths occupy different boundaries. A supported Browser path can participate before submission, subject to its mode and failure behavior. The reviewed OTLP paths analyze exported activity without returning an intervention decision to the emitting application. The runtime governance pillar explains those limits by mechanism.

For an implementation review, identify the installed version, event, response contract, destination authorization, and evidence of application.