AI agents are getting easier to build. Control is becoming the hard part.

OpenAI’s Agents API entered public beta this month with a managed harness for long-running agents, tool use, context and subagents. Other platforms are making the same broader shift from agent experiments toward managed execution, identity and tool infrastructure. The engineering work required to make an agent capable of reaching a system is becoming easier to buy or configure. OpenAI · Agents API

The harder question begins after the connection works.

An agent that can read an order, update a case, send a message or issue a refund has technical capability. A business still has to decide whether that action is permitted in this situation, under whose authority it is taken, what limit applies, when a person must intervene and what evidence survives afterwards. Those decisions are not supplied by the model. They are part of the operating system around it.

The gap is already visible in enterprise adoption. Deloitte’s 2026 survey of 3,235 business and technology leaders across 24 countries found that 74% of organizations planned to deploy agentic AI within two years, while only 21% reported a mature governance model for it. The numbers do not prove that every company needs the same governance stack. They do show that deployment is moving faster than many organizations’ ability to define and oversee it. Deloitte · State of AI in the Enterprise 2026

74%

plan to deploy agentic AI within two years

21%

report mature governance for agentic AI

The hard question begins after the tool connects

Microsoft’s current Agent 365 guidance makes a useful distinction: an agent that can retrieve a document is not equivalent to one that can send mail, delete records or update a customer system. The risk sits in what the connected tool can touch and what actions it permits. Microsoft therefore treats tool approval, permissions and function-level control as part of the enterprise boundary, not as an afterthought. Microsoft · Governing agent tools

OWASP describes the same problem from a security perspective. Its Excessive Agency guidance separates three failure modes: giving the model functions it does not need, granting those functions permissions broader than the task requires, and allowing consequential actions to happen with too much autonomy. The remedies differ. Tool scope is a design choice. Permissions belong in the connected systems. Human approval belongs where the consequence warrants it. OWASP · LLM06:2025 Excessive Agency

This is why an agent should not receive one blanket autonomy setting. Authority has to be designed at the level of the action.

For an operations leader, these frameworks are useful less as technical architecture to memorize than as leverage when working with IT, engineering and security. They turn vague assurances into concrete questions: Where is this rule actually enforced? Which system can refuse the action? Who can change the permission? What happens when the agent reaches the boundary?

Design authority action by action

Businesses already use a familiar idea for human decision-making: Delegation of Authority (DoA). A manager may approve spending up to one threshold, while a larger commitment requires a different level of sign-off. An agent needs the same clarity before it touches a live queue. The point is not to copy a human DoA table mechanically, but to make delegated authority explicit action by action.

Consider an illustrative refund desk for a distributor. The agent receives a customer request and can retrieve the order history, check delivery status, draft a response, add a note to the case, issue a small store credit, send a reply and, in some circumstances, return money to the customer’s card.

Those actions sit inside one workflow, but they do not carry the same consequence.

Reading an order is different from changing it. Drafting a reply is different from sending one under the company’s name. A capped store credit that can be reversed is different from a card refund that moves money outside the business. Deleting case history is different again because it removes evidence other people may need later.

A useful production design starts by making those differences explicit.

Action	Authority	Operational consequence
Read order and delivery history	AllowAgent may act	Read-only, task-specific access
Draft customer reply	AllowAgent may act	No external effect yet
Add internal case note	BoundedAgent may act within defined fields	Internal change with bounded scope
Issue store credit up to a stated ceiling	BoundedAgent may act within a hard limit	Financial effect is capped and reversible
Send customer reply	ApprovalNamed person approves exact action	External communication under company name
Refund customer card	ApprovalNamed person approves exact action	Money leaves the business
Delete case history	Not grantedNot granted	Destructive action removes evidence

This is an illustration, not a universal policy. A real threshold depends on the workflow, regulatory obligations, reversibility, data sensitivity, fraud exposure and the organization’s own tolerance for error. The important point is that the boundary is written before the workflow becomes routine.

Put hard limits where the action is enforced

Prompts are useful for telling an agent how to behave. They should not be the only place a consequential business limit exists.

OpenAI’s Workspace Agents documentation makes the distinction concrete. Agent instructions do not themselves grant access to an app. Access is configured separately. Write actions default to asking for confirmation, and builders can add connector constraints that narrow what particular actions may do. OpenAI · Workspace Agents

OWASP goes further and recommends that authorization be enforced in downstream systems using the minimum permissions necessary. In the refund example, a sentence in the instructions saying “never refund more than 200” can help guide the model. A payment service that refuses any agent-initiated refund above the approved ceiling is the actual control.

A simple production test is useful here:

Behavioral instruction	Operational control
“Do not refund more than the limit.”	The payment system rejects requests above the agent’s configured ceiling.
“Ask before sending a customer message.”	The send action is held until an authorized reviewer approves the exact message and recipient.
“Only use the records needed for this case.”	The agent identity and connector are scoped to the permitted records and actions.

The prompt still matters. It improves behavior and can reduce unnecessary attempts. It simply should not be confused with authorization.

Identity is part of the delegation

Every live action is taken under an identity, and that identity changes what the action means.

For operations, the practical demand is simple: the identity should make the scope of delegation clearer, not obscure it. A team should be able to tell who initiated the work, which agent acted, what permissions it carried and who remains accountable for the result.

Current enterprise platforms are converging on this problem in different ways. OpenAI supports user-connected and agent-owned access patterns; Microsoft distinguishes agents acting as themselves, on behalf of users or through agent-specific accounts; Google ties agent identities into access policy and audit logging. Microsoft · Agent 365 identity Google Cloud · Agent Identity

These are product implementations, not universal rules. What matters is the operating question they expose: whose authority is being exercised when this action occurs?

A shared service account with broad rights may be convenient, but it can make scope and accountability harder to reconstruct. A person’s credentials preserve user context, but they may also expose permissions much broader than the agent’s task. A dedicated agent identity can be scoped more deliberately, but it still needs an accountable owner and a clear reason for existing.

NIST’s National Cybersecurity Center of Excellence opened a 2026 project around exactly these issues. Its concept paper asks how agents should be identified, authorized, audited and tied back to human authorization, including how least privilege and delegation should work when an agent acts on someone’s behalf. The paper is exploratory rather than finished guidance, which is itself informative: agent identity and authority are now infrastructure questions, not only prompt-design questions. NIST NCCoE · Software and AI Agent Identity and Authorization

Human review should follow consequence

Putting a person into every step does not automatically make a workflow well controlled. If a reviewer approves dozens of harmless actions every hour, the approval can become routine rather than thoughtful. If the reviewer sees only a vague “continue?” prompt, they may not know what they are authorizing.

A human gate also has to work operationally. If, for example, an agent escalates 30% of cases into a queue without the context needed to decide them, the workflow may be safer on paper while becoming slower in practice. Escalations need owners, routing rules, enough context to make the decision and service expectations for how quickly they are resolved. Otherwise the automation has moved work into a bottleneck rather than removed it.

Escalation without design

1. Agent
2. Escalate
3. Human queue

No owner · Incomplete context · No decision expectation

Designed for flow

1. Agent
2. Reason + evidence + proposed action
3. Named owner
4. Decision window
5. Resume / stop

OWASP recommends human approval for high-impact actions rather than treating approval as a substitute for scoped permissions. That is the better design principle: use deterministic boundaries for what the system can enforce, and reserve human judgment for actions where consequence, ambiguity or irreversibility genuinely changes the decision.

The EU AI Act illustrates this principle in a specific regulatory context. For systems the Act classifies as high-risk, Article 14 says human oversight should be proportionate to risk, autonomy and context. It also requires the people responsible for oversight to understand system limitations, remain aware of automation bias, and be able to disregard, override, reverse or interrupt the system. Those requirements do not apply to every business agent, but they make one point clear: a human gate is meaningful only if the person has enough information, authority and practical ability to change the outcome. EU AI Act · Article 14

For the refund desk, the reviewer should not be asked merely whether the agent may continue. They should see the customer, amount, reason, source records, proposed external effect and the rule that caused the escalation. The approval should bind to that action, not become a blank permission for whatever the agent does next.

The record has to reconstruct the delegation

After a consequential action, a useful audit trail should make the event understandable without asking the model to explain itself after the fact.

At minimum, the organization should be able to reconstruct:

• who or what initiated the task;
• which agent identity acted;
• which tool and target system were involved;
• the exact action and material parameters proposed;
• which permission or policy allowed, blocked or escalated it;
• whether a person approved it and who that person was;
• what actually happened in the downstream system;
• whether the action was later reversed, corrected or revoked.

Microsoft’s agent identity model exposes sponsors and differentiated audit logs. Google integrates agent identity with audit logging whether an agent acts as itself or on behalf of a user. NIST’s concept work explicitly includes auditing and non-repudiation among the unresolved identity questions. OWASP’s new Agent Control Standard is also aimed at runtime inspection, policy enforcement and traceability, although its current v0.1.0 work should be treated as an emerging open standard rather than a mature universal control layer. OWASP · Agent Control Standard

The common direction is more important than any single vendor architecture: once software can act, organizations need evidence of what authority existed at the moment of action.

Seven questions before an agent reaches production

Before a business gives an agent standing access to a live workflow, it should be able to answer seven questions in plain language:

Production gate

1. 01

   What exact actions may the agent take?

   List actions, not broad job descriptions such as “manage refunds” or “handle support.”

2. 02

   Under whose identity does each action run?

   Distinguish the requester, the agent and any shared or delegated account.

3. 03

   Where are permissions enforced?

   Know which system actually allows or refuses each action.

4. 04

   Which limits survive a model mistake?

   Financial ceilings, destinations, data boundaries and destructive actions should not depend only on a prompt.

5. 05

   Which consequences require human judgment?

   Tie approval to the exact action and show the reviewer the information needed to decide.

6. 06

   What evidence survives the run?

   Keep enough context to reconstruct authority, action, approval and outcome.

7. 07

   How is authority withdrawn?

   Define how to stop the run, revoke access, disable a tool and recover from an incorrect action.

If a team cannot answer these questions, the agent may be technically functional without being operationally ready.

The goal is deliberate delegation

The next phase of enterprise agents will not be defined only by better models. The surrounding infrastructure is already expanding into agent identities, tool registries, scoped permissions, runtime policy, approval mechanisms and audit trails. That is happening because useful agents are increasingly able to touch systems where actions have consequences.

The operating question is therefore not how autonomous an agent can become. It is how precisely a business can delegate authority to it.

An agent can be useful precisely because it acts. Before it does, the organization should be able to state what it may do, how far that authority extends, where the boundary is enforced and who remains accountable when the action matters.