When AI Agents Became a Governance Control Problem
Date: 2026-09-10 (Asia/Bangkok)
Category: Analyst Article
Classification: DGCP™ / AI Governance
Framework: DGCP™ — Data Governance & Continuous Proof
Mode: Observation • Structural Analysis • Evidence Context • No Prediction • No Advice
Location: Earth System
Observation
AI governance has often concentrated on generated content: what a model produced, whether an output was reliable, whether protected information was exposed, and how a person used the result. Tool-enabled systems add another observable object. They can request actions in browsers, software, files, code environments, and connected services.
Current technical documentation makes that shift visible. OpenAI documents tools that can fetch data, run code, call external APIs, and use computers, while distinguishing model requests from work performed by an application or execution environment. Anthropic similarly documents computer-use requests that an application executes in an environment it controls. Microsoft documents software identities for agents that can receive rights directly or use rights delegated by a human user. These records establish action-capable system architectures. They do not establish unrestricted authority or universal operational autonomy. [1][2][3][4]
The governance question changes when AI-mediated requests can move beyond generated information and become actions in an external environment.
The evidence supports a shift in what must be governed. It does not establish that every AI agent is autonomous, that every tool call is consequential, or that documented safeguards are effective in every deployment.
Core Question
What changes when AI systems move from generating outputs to taking actions through tools, permissions, and operational processes?
The relevant environment includes the tools exposed to the system, the identity or credential used, the permissions attached to that identity, any approval point imposed by the application, the execution layer that performs the operation, and the evidence retained afterward.
Evidence Context
The sources used here have different evidentiary limits. Product and technical documentation can establish that a capability, architecture, or control is documented and available. It does not by itself prove that every deployment enables the control, configures it correctly, or achieves the intended result.
OpenAI's Agents SDK states that tools can let agents fetch data, run code, call external APIs, and use computers. It distinguishes hosted tools from local or runtime tools, and documents approval gates, conditional tool enabling, and environments in which only explicitly allowed tools can be called. [1]
OpenAI's computer-use documentation and SDK architecture distinguish a model-generated computer request from the external execution of that request. The surrounding application or configured execution environment performs the actual work and returns the resulting state to the model. [1][2]
Anthropic documents a comparable boundary for computer use: Claude produces tool-use requests, while the application runs those calls in an environment it controls and returns tool results. Anthropic also recommends measures including isolated environments, minimal privileges, restricted internet access, and human confirmation for decisions with meaningful real-world consequences. [4]
Microsoft Entra Agent ID provides evidence from the identity layer. Microsoft distinguishes agent identities from human identities and documents both rights assigned directly to an agent identity and delegated rights derived from a human user. It also documents agent authentication activity in Microsoft Entra ID. [3]
NIST AI RMF 1.0 provides broader risk-management context. NIST identifies the framework as voluntary and applicable to the design, development, use, and evaluation of AI systems. NIST also states that AI RMF 1.0 is being revised in 2026. Its Generative AI Profile remains a risk-management resource rather than an agent-specific legal obligation. [5][6]
From Output Governance to Action Governance
A generated answer can influence a later human decision. A tool-enabled system can additionally produce a request that an execution layer translates into an external operation. Depending on the implementation, that operation may involve navigating an interface, reading or changing a file, calling a service, running code, transmitting information, or interacting with another system.
The existence of this capability does not mean that the model itself owns the authority. OpenAI's documentation places local execution outside the model response itself: the model can decide to call a tool, while the application or configured environment performs the work. Anthropic likewise states that the application runs computer-use calls in an environment it controls. [1][4]
This creates governance questions that output review alone cannot answer. Which tools were exposed? Which identity or credential was used? What permission scope applied? Was additional approval required? Was the requested action executed? What external state changed? What evidence remains afterward?
These are operational governance questions. They do not require a claim that the model possesses independent institutional authority.
Capability, Access, and Authority
Capability is not access. A model may be capable of selecting a tool or generating valid parameters without being connected to the relevant resource. OpenAI's documentation makes tool availability dependent on what the application or execution environment exposes. [1]
Access is not unlimited authority. Tool availability can be constrained by explicit tool selection, environment restrictions, credential scope, approval requirements, and other controls. OpenAI documents explicitly allowed tool surfaces in programmatic tool calling, while Anthropic recommends minimal privileges and restricted access for computer-use environments. [1][4]
Technical permission is not necessarily organizational authorization. A service may technically accept a valid credential even where an organization's internal process requires additional approval. Public technical documentation can establish the technical permission model; it generally cannot establish whether a particular organization's internal authorization was valid in a specific event.
Microsoft's distinction between direct and delegated rights illustrates why identity matters. An agent identity can receive access rights directly, or an agent can act using rights delegated by a human user. Those are different authorization relationships even when the resulting external action appears similar. [3]
Tool capability does not, by itself, establish operational authority.
Execution and Human Oversight
A requested action is not an executed action. OpenAI documents local runtime tools as operating outside the model response: the model decides when to call them, while the application or configured environment performs the work. Anthropic similarly describes tool-use requests followed by application-side execution and returned results. [1][4]
This distinction creates several observable states: a request may be generated, permitted or rejected, attempted by an execution layer, accepted or rejected by an external system, and then verified or left unverified. Those states should not be collapsed into a single claim that the AI “did” something.
Human involvement also has several possible meanings. A person may initiate a task, approve a consequential action, monitor execution, interrupt a run, or review the result afterward. The presence of a human therefore does not by itself establish effective control.
At the same time, current documentation provides counter-evidence to the claim that action-capable AI necessarily removes human control. Anthropic recommends human confirmation for decisions with meaningful real-world consequences and describes confirmation behavior in response to detected prompt-injection risk. OpenAI's Agents SDK documents approval gates for tool use and pause-and-resume behavior around approval-sensitive calls. [1][4]
Action Traceability and Evidence Integrity
When an AI system can affect an external environment, a transcript of model output may be insufficient to reconstruct the event. It may show what the model requested without establishing whether the request was executed, which identity was used, what the external service returned, or whether the resulting state matched the intended outcome.
OpenAI's Agents SDK includes tracing for events such as model generations, tool calls, handoffs, guardrails, and custom events. Traces and spans can contain identifiers, timing information, relationships, and operation-specific data. The same documentation states that tracing can be disabled and is unavailable for organizations using OpenAI APIs under a Zero Data Retention policy. [7]
Microsoft documents authentication records for supported agent identities, including records identifying activity as performed by an AI agent. [3] Such identity records can contribute to traceability, but they do not by themselves establish a complete chain from human intent through authorization, execution, external response, and verified outcome.
The existence of a log therefore does not establish complete evidence. Evidence quality depends on what was recorded across the relevant systems, whether those records accurately represent the event, and whether they are sufficient to reconstruct the material action.
Selected Evidence Cases
Computer Use: Request and Execution Are Separate
OpenAI's computer-use architecture provides direct evidence of a boundary between model-generated requests and external execution. Local runtime tools execute outside the model response itself, and the application or configured environment performs the requested work. [1][2]
This establishes that governance of computer use extends beyond model behavior into the execution environment. It does not establish that every implementation uses the same controls or that documented controls are effective in every deployment.
Computer Use: Environment Restrictions and Human Confirmation
Anthropic documents computer use as a developer-operated process in which tool requests are executed by the application in an environment it controls. Its security guidance recommends a dedicated virtual machine or container with minimal privileges, limiting access to sensitive information, restricting internet access, and obtaining human confirmation for decisions with meaningful real-world consequences. [4]
The documentation establishes that environment design and approval mechanisms are relevant control layers. It does not prove that those measures are enabled or effective in every implementation.
Enterprise Identity: Direct and Delegated Rights
Microsoft Entra Agent ID provides a structurally different case. Microsoft documents agent identities as software identities capable of accessing services, receiving rights directly, or acting through rights delegated by a human user. Microsoft also documents security-policy application and agent authentication records. [3]
The case shows that the identity through which an agent acts can be separated from a human identity and that the source of access rights can differ. It does not establish that identity records alone capture the complete operational meaning or outcome of an action.
Tracing: Observability With Explicit Limits
OpenAI's Agents SDK tracing provides an implementation example of workflow observability. It can record generations, tool calls, handoffs, guardrails, and custom events. However, tracing can be disabled and is unavailable under OpenAI's Zero Data Retention policy. [7]
This supports a narrower conclusion: action-capable workflows can produce structured operational records, but the availability of a tracing feature does not establish that a trace exists for every run or that a trace alone constitutes complete evidence.
Counter-Evidence
The reviewed evidence does not support a claim that action capability inevitably produces an uncontrolled system.
- Applications can limit which tools are available to a model. [1]
- Execution environments can be isolated and access can be restricted. [4]
- Approval gates can interrupt selected tool operations. [1]
- Human confirmation can be required for consequential decisions. [4]
- Agent identities can receive direct or delegated rights rather than inheriting unrestricted access by default. [3]
- Agent runs can produce structured traces, subject to configuration and retention limits. [7]
These mechanisms show that action can be bounded. They do not prove that controls are universally enabled, correctly configured, or effective. The narrower evidence-supported conclusion is that governance increasingly depends on the relationship between capability, access, authorization, execution, and retained evidence in the specific operating environment.
What the Evidence Does Not Establish
The reviewed evidence does not establish that AI agents possess independent legal or institutional authority. It does not show that all tool-enabled systems are autonomous or that every AI-mediated action creates material operational risk.
It does not demonstrate that every safeguard works in every deployment, nor does the absence of public implementation evidence establish that a safeguard is absent.
The evidence does not support treating a log as complete proof, human approval as proof of informed understanding, or a successful tool response as proof of a verified operational outcome.
It also does not assign legal liability among model providers, application developers, system operators, administrators, credential owners, users, tool providers, or external services.
NIST AI RMF 1.0 is voluntary guidance and is being revised in 2026. It is not presented here as an agent-specific legal requirement. Vendor documentation is used to establish documented technical capabilities, controls, and limitations, not regulatory compliance or organizational effectiveness. [5][6]
Closing Observation
AI-agent governance becomes operationally relevant where model capability meets an external environment. At that boundary, the surrounding system determines which tools are available, which identity is presented, which permissions apply, whether additional approval is required, how an action is executed, and what evidence remains afterward.
The evidence does not show that AI agents eliminate human governance. It shows that governing generated content alone may be insufficient when AI-mediated requests can be translated into external actions.
The question is no longer only what the AI model can generate. It is what the surrounding system permits, what action actually occurred, what evidence remains, and where accountable control sits.
Evidence Discipline
Evidence was reviewed through 2026-09-10. Product and technical documentation is used to establish documented capability, architecture, control availability, and stated limitations. It is not treated as independent proof of universal implementation or control effectiveness.
Legal requirements, voluntary standards, technical guidance, and vendor controls are not treated as interchangeable. NIST AI RMF 1.0 is identified as voluntary and currently under revision. No finding in this article resolves legal liability or asserts that a specific deployment complies with law.
Claims about access, authority, execution, traceability, and control are limited to what the cited public evidence establishes. No inference of operational autonomy is made from model capability alone.
Sources
[1] OpenAI. Tools — OpenAI Agents SDK. Accessed 2026-09-10.
https://openai.github.io/openai-agents-python/tools/
[2] OpenAI. Computer Use — OpenAI API Documentation. Accessed 2026-09-10.
https://developers.openai.com/api/docs/guides/tools-computer-use
[3] Microsoft. What Are Agent Identities? — Microsoft Entra Agent ID. Updated 2026-06-15.
https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities
[4] Anthropic. Computer Use Tool — Claude Platform Documentation. Accessed 2026-09-10.
https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool
[5] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
[6] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. 2024.
https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
[7] OpenAI. Tracing — OpenAI Agents SDK. Accessed 2026-09-10.
https://openai.github.io/openai-agents-python/tracing/
Framework Notice
This public article presents verified public evidence, structural observations, counter-evidence, and evidence-bounded interpretation.
Protected internal DGCP™ methods, governance procedures, evaluation mechanisms, analytical workflows, and non-public research structures are outside the scope of this publication.
Observation Only • Structural Analysis • No Prediction • No Advice
Author
P’Toh
System Architect — DGCP™
License
DGCP | MMFARM-POL-2025
This work is licensed for public reading, citation, and reference with attribution to the author and framework.
Commercial reuse, modification, dataset extraction, model training, republication as another work, or removal of attribution requires prior written permission.