OPERATIONS BRIEF · 2026.09.30 · AI AGENTS

Three Boundaries for AI Agent Operations: Approval, Execution Rights, and Audit Evidence

Once an AI agent enters a business workflow, model-answer quality alone cannot define the operating boundary. Teams need to decide which actions require approval, how a small team can deploy an execution environment with appropriate cost and permissions, and what evidence will establish the facts after a problem. This brief connects approval, segmented access, and execution history into one accountability flow.

Today’s operating view: retain the basis for actions before focusing on agent answers

An AI agent may do more than interpret a request and call a model. It can select tools to find documents, query internal systems, save data, or request changes in external services. Operators therefore need to explain not only what an agent said, but also who initiated the request, which policy allowed the action, and what result was recorded in the actual target system.

This article does not claim that a particular product includes security, deployment, or audit capabilities by default. It uses public repositories and documentation as starting points and proposes operating criteria that a team can check in its own environment. The published scope of a source remains separate from approval procedures, network segmentation, retention policies, and recovery processes that an organization must define for itself. It also does not present unverified capabilities or the cause of a particular incident as fact.

The three topics are not independent. If permission control is weak, a harness can manage an execution sequence while the possible impact remains broad. If a runtime is deployed quickly but approval evidence and invocation history are absent, responsibility and outcome become difficult to establish after an incident. When approval, permissions, and records are connected as the before, during, and after stages of one request, teams can define automation scope and stop conditions more concretely.

1. AI agent security and permission control: design approval, auditability, and segmented network boundaries together

The first security question for an agent is not “Is this agent useful?” but “Which actions can this request lead to?” A user request, model suggestion, tool input, and external-system response can all enter the execution flow. When they are mixed under the same authority, it becomes easy to lose the boundary between where input arrived and where an actual change occurred. That is why requesting principal and execution principal, tool permission and target scope, need to be examined separately.

Approval does not mean showing the same confirmation dialog for every request. First distinguish actions that may run automatically, actions that may run only after human confirmation, and actions that must never run. Retrieval from a pre-bounded public source does not need to be treated in the same way as sending material to an external recipient or changing business state. Where approval is required, the reviewer should be able to see more than a tool name: the real target, anticipated change, recipient, scope, validity period, and whether recovery is possible.

SECURITY PROJECTGitHub - OWASP/www-project-top-10-for-large-language-model-applications: OWASP Top 10 for Large Language Model Apps (Part of the GenAI Security Project)The OWASP GenAI Security Project repository for LLM-application security materials. Use it as a reference point for reviewing agent inputs and tool use as distinct boundaries.

Approval should attach to concrete execution content, not simply to the wording of a request. If the recipient, target document, retrieval scope, or input changes after approval, the earlier approval should not be reused without review. Approval limits and expiry reduce the risk that one confirmation remains open for unrelated later work. Even automatically permitted actions need an explicit target scope, invocation limit, execution window, and result-verification condition.

An audit record does not end with a screenshot of an approval screen. It links the request identifier, requester, agent or service execution identity, applied policy, approval result, tool invocation, target, and outcome state. This does not mean retaining every internal model thought. It means preserving observable evidence that can later establish who requested what, what was allowed, and what was actually executed.

AUTHORIZATION REFERENCEGitHub - cerbos/cerbos: Cerbos is an open-core authorization management platform for authorizing every identity and governing every action across applications, gateways, workloads, and AI agents.A public project for authorizing identities and governing actions across applications, gateways, workloads, and AI agents. It is a reference for reviewing policies built around actions and targets rather than broad role names.

Permissions are better defined by actions than only by broad labels such as “support team,” “operator,” or “agent.” Separate the customer set that may be queried, the fields that may be read, the records that may be created, and the destinations to which material may be sent. Search, summarization, draft creation, saving, and external delivery remain different actions even when they occur in one user request. Permission to perform an earlier step should not automatically permit the next one.

Segmented network operations are part of this boundary as well. Development and validation environments should use prepared data and isolated accounts, while production should reach only approved live targets. Avoid allowing validation tools to call production endpoints by default, or copying credentials merely because environment-variable names match. Network separation alone does not narrow authority, so the available tools and reachable targets need separate review in each environment.

Handling a blocked request also belongs in policy design. Automatically retrying with a broader account because access is missing can collapse the approval and segmentation boundaries. Without exposing sensitive internal policy detail, show the user an available next step and route necessary work through a designated approver or business process. Policy denial, user denial, tool error, and an unverified external-system state should be recorded as distinct outcomes so that follow-up responsibility is clear.

2. Open-source AI agent runtimes: small teams read Strands Harness through cost, permission, and deployment criteria

When a small team reviews an open-source agent runtime, the first question is not whether it can attach a new framework quickly. It is whether the team can carry the resulting execution responsibility. A harness can be understood as the operating layer that receives a request, assembles execution, connects models and tool calls, and returns a result. Understanding that layer makes it easier to distinguish what changed among the model, prompt, tool, policy, and deployment environment, and which changes need renewed validation.

The public repository title for the Strands Harness SDK describes an open-source SDK for building and controlling production AI-agent harnesses end to end in Python and TypeScript. That description does not guarantee a particular deployment model or organization-specific security arrangement. When reviewing public code and documentation, a team still needs to verify the model connections, tool definitions, permission checks, and operating-environment constraints required for its own work. It is important not to treat the execution structure provided by a harness as identical to the business policy for which the organization is responsible.

OPEN-SOURCE SOURCEGitHub - strands-agents/harness-sdk: Build an agent harness and control it end-to-end. Open-source SDK for production AI agents in Python & TypeScript - any model, any cloud.A public SDK repository for building and controlling production AI-agent harnesses in Python and TypeScript. Use it as a starting point for reviewing execution structure and control points.

Cost is not only model-call cost. Tool invocations, failure handling, retries, record retention, time spent waiting for approval, and operator investigation time all belong to the actual operating path. A small team is better served by selecting one workflow with a clear target scope and recovery method than by automating every task at once. Defining which requests finish automatically and which transfer to a person makes both invocation volume and operational burden easier to assess realistically.

For permissions, separate the fact that a harness can invoke a tool from the fact that the invocation is permitted. Even when a model suggests a tool name or parameters, they still need to pass an allowlist, input schema, target-scope check, and current approval state. Sentences inside search results, external documents, or tool outputs do not create new execution authority. Data can inform a decision, but it should not become a basis for expanding access scope.

PUBLIC IMPLEMENTATION REFERENCEGitHub - strands-labs/benchmark-harnesses: Strands-based agents and harnesses for agentic benchmarks.A public repository containing Strands-based agents and harnesses for agentic benchmarks. It is a reference for examining a harness as a unit that assembles task-specific execution conditions.

Deployment criteria should also begin small. Write down which model settings, tool lists, credentials, and network targets are reachable from development, validation, and production. Even when those environments use the same code version, there is no reason to grant them the same authority. A successful validation call should not authorize access to production data or external delivery. Before production deployment, test not only normal requests but also out-of-scope tool calls, malformed input, expired approval, and stop requests.

Tool registration is closer to contract management than developer convenience. For every tool, document its name, input schema, output schema, eligible caller, target, expected side effect, and where to check when it fails. A broad label such as “document processing” does not reveal whether a tool only reads, creates a file, or changes an external system. The gap between what a tool description says and the change it can actually cause must be reduced for approval and auditing to have meaning.

Failure handling should not retry reads and mutations in the same way. When a timeout or network error leaves the final effect of an external change unknown, sending the same request again can create a duplicate execution. Link the original business-request identifier to the individual invocation identifier, verify the prior invocation’s final state, and then decide whether retry is allowed. The fact that some operations must not be retried automatically should be explicit in deployment criteria.

A small team’s operating document need not be complex, but it must retain who changed what. For every harness revision, record model settings, system instructions, tool definitions, policy version, deployment environment, and the denial cases checked. This is not a claim that an SDK requires those fields; it is the team’s own basis for explaining change scope. A successful demonstration matters less than whether allow, deny, and recovery outcomes can be explained again after deployment.

3. AI-agent incident investigation and audit logs: bind execution history, accountability, and approval evidence into one case

Investigating an agent-related problem requires more than reading the final answer. Teams need to connect, in time order, the initiating principal, the service identity that executed the work, the applied permission policy, approval status, selected tool, actual input and target, external-system response, and final confirmed state. This does not mean storing every conversation or every internal judgment. It means preserving the observable execution evidence needed to reconstruct actual actions.

A shared identifier is essential to that record. One user request can pass through several agents, model invocations, tool calls, approval stages, and human interventions. Linking the original request identifier, parent-work identifier, individual invocation identifier, start and finish times, requester, execution identity, policy result, and status makes an event path easier to establish across distributed records. If identifiers break in the middle, even a large collection of logs cannot reliably establish which result came from which request.

OBSERVABILITY CONVENTION REFERENCEMoved: Generative AI semantic conventionsDocumentation for semantic conventions for generative AI. Use it as a reference for considering how records from several execution stages can be handled with consistent names and relationships.

Audit logs need both investigability and data protection. Rather than copying every raw input and output by default, retain the target identifier, action type, policy decision, error category, and outcome state needed for review while redacting sensitive values. Check that tokens, passwords, authorization headers, and personal data do not appear in error messages or diagnostic output. The people who can read logs and the retention period also need their own policy, just like execution authority does.

Status requires more than success and failure. Distinguish an accepted tool request whose final effect remains unverified, a request with a delayed or absent response, a policy denial, a user denial, and a result repaired manually. In particular, when a connection breaks after an external change request, do not conclude failure solely from an error message in the agent interface. Verify whether the target system actually changed before assigning a final status.

OBSERVABILITY DOCUMENTATIONAgent Graphs - LangfuseDocumentation for visualizing and analyzing complex agent workflows as aggregated views or as-executed DAG views. It is a reference for reviewing execution sequence and branching relationships.

An execution history should reveal relationships rather than merely list log lines. Connect parent and child work, agent handoffs, model invocations, tool calls, approval events, retries, and human interventions. A graph or timeline can be a useful way to make those relationships readable. The more important test is not the appearance of the screen, but whether a concrete result can be verified against the request, policy decision, approval, and calls that produced it.

When an incident occurs, the first step is not to declare a cause. Stop tools or connections that may continue producing impact within the necessary scope, then define the relevant execution identifiers and evidence-preservation boundary. Next, reconstruct the path from request time to the target system’s final state. If the agent answer, invocation record, and external system’s change history disagree, do not immediately treat one as definitive; read each as separate evidence.

Post-incident review should not end with the statement that “the model made a bad decision.” Separate missing input validation, overbroad permission scope, unclear approval targets, retry rules that caused duplicate execution, and missing links in the record. Assign every change an owner, implementation location, validation method, and completion condition. A preventive control becomes a real operating control only when it can be verified in the next execution history.

Operator memo: compare one request against the approval table and execution record from end to end

Today, select one frequently used business request. A request with several actions is suitable, such as finding material, producing a summary, saving it in an internal record, or delivering it externally. Write down in order the requester, execution service, tools used, accessible target, approval status, and final result. If any point does not connect, do not defer it as something to check later; assign an owner and a time for confirmation.

The review output can be as small as three document fragments. In the permission table, identify which actions and targets are automatic, require prior approval, or are prohibited. In the deployment record, identify which tools and credentials operate in which environment. In the execution record, retain identifiers that connect the actual request, approval, invocation, and result. A small team can keep all three in one document as long as they can be found through the same request.

Define review completion as an actual check, not document creation itself. In a prepared environment, test one request that should be permitted and one that should be denied, then confirm that the approved content and actual invocation target match. If the result remains unknown, leave it as unverified rather than presenting it as success or failure. The minimum standard for today is whether accountability and outcome can be explained without recording sensitive values.

Explain approval before execution, authority during execution, and evidence after execution as one case

Trustworthy AI-agent operations do not come from tool count or model capability alone. Before execution, a team must explain which actions are allowed and who approves them. During execution, it must explain which authority reaches which target in which segmented environment. After execution, it must explain which evidence establishes the actual result and responsibility. Trace one request from beginning to end today and identify the gaps. Those gaps are the operating boundaries to repair before the next automation.