The Missing Control for AI Agents Is an Execution Policy
AI agents are getting easier to deploy. In the past week, the market has reinforced that direction: new agent-building APIs, new enterprise observability products, and more investment in agent security infrastructure. The practical consequence for security leaders is not that every organisation suddenly needs an agent strategy. It is that more teams will be able to create agents before governance teams have decided what those agents may actually do.
That is the wrong order.
Most enterprise AI governance still starts with a model question: which model is approved, where is data stored, and what prompts are acceptable? Those are useful controls. They are not enough once a system can retrieve data, call a tool, update a record, send a message, or trigger a workflow. An agent can make a perfectly policy-compliant request to a model and still create an unacceptable business outcome through the action it takes next.
The missing control is an execution policy: a clear, enforceable answer to what an agent may do, with which identity, against which systems, under what conditions, and with what evidence afterward.
The real risk begins after the model responds
Consider a procurement assistant. A conventional chatbot drafts a vendor comparison for a human to review. An agentic version may search contract records, contact a vendor, update a procurement system, and prepare a purchase request. The language model is only one component in that chain. The risk lives in the chain of decisions and side effects.
This distinction matters because existing security controls can create false confidence. A data-loss prevention rule may prevent an employee from pasting a tax file into a public chatbot. It cannot decide whether an internal agent with legitimate access should create a supplier record, change payment details, or send commercially sensitive information to the wrong recipient. Identity controls may authenticate the agent. They do not by themselves establish whether a particular action is appropriate in a particular context.
That is why agent governance cannot be reduced to an AI policy PDF or a vendor questionnaire. It must operate where action happens.
Define an execution policy before production access
An execution policy should be specific enough for a system to evaluate, not merely a principle that sounds sensible in a workshop. For every production agent, document and enforce five things.
1. A named business owner and a named technical owner
An agent cannot be owned by "the business". The business owner accepts the outcome risk: what the agent is intended to achieve, which errors are tolerable, and when human review is required. The technical owner is accountable for the integration, credentials, monitoring, and change process. If those names are missing, the agent is not ready for production.
This sounds basic, but it cuts through a common shadow AI pattern: a capable employee connects a new agent to a shared workspace or SaaS tool because it removes a manual step. The workflow may be useful. Without an owner, there is no one to approve scope expansion or respond when the tool behaves unexpectedly.
2. A narrow action allowlist
Start with the smallest useful set of actions. "Can access Salesforce" is not a permission model. "Can read open opportunities in the assigned territory and create a draft follow-up task" is a permission model.
Make the allowlist explicit at the tool and operation level. Separate read, draft, create, update, approve, send, and delete. Default to read-only access where possible. Require a human approval step for irreversible actions, external communications, payments, identity changes, and high-impact record updates. The goal is not to make agents useless. It is to prevent a broad integration from quietly becoming a broad delegation.
3. Context conditions, not just static permissions
A permission that is safe at 10am may be unsafe during an incident. A customer-support agent may be allowed to draft a response but not send it when a case contains legal, health, financial, or regulated information. An execution policy needs conditions such as data classification, system environment, customer tier, time window, transaction value, and confidence threshold.
Static roles are necessary. Context is what turns them into a defensible control.
4. An agent identity with short-lived credentials
Do not run an agent through a shared employee account or a permanent API key copied into a workflow tool. Give it a distinct identity, least-privilege access, scoped tokens, and a credential expiry process. This makes actions traceable and makes revocation practical.
It also protects the organisation from a familiar failure mode: an employee leaves, a connector remains, and an automation continues to act with access nobody remembers granting. For agentic systems, identity lifecycle is not a back-office task. It is part of runtime governance.
5. Evidence that connects intent to action
Logging a prompt is not sufficient. A useful audit trail records the request, the source data used, the model or policy version, the tool call proposed, the approval outcome, the action taken, and the result. Security and GRC teams need enough context to answer three questions after an incident: what did the agent know, why was it allowed to act, and what changed?
This is where observability becomes more than a dashboard. It is the evidence layer for accountable autonomy.
Treat change as a new risk decision
An approved agent is not permanently approved. A new connector, a broader data source, a model change, an altered prompt, or a new action type can materially change risk. Governance should distinguish between a small configuration change and an expansion of the agent's authority.
A practical rule: if a change lets the agent see new sensitive data, act in a new system, communicate externally, or make an irreversible decision, trigger a lightweight reassessment. That reassessment should review the execution policy, test failure paths, confirm controls, and update the owner sign-off.
This approach is faster than a heavyweight committee for every tweak and safer than treating all changes as routine engineering work.
Start with discovery, not a ban
The hard truth is that many of the most consequential agents will not arrive through the formal AI programme. They will appear in workflow platforms, browser extensions, copilots, low-code tools, and SaaS add-ons. If the organisation only governs registered agents, it is governing a fraction of actual behaviour.
Start by discovering AI use and agent-capable integrations across the enterprise. Then classify them by data access and action capability. A read-only research assistant and an agent that can modify customer records should not have the same review path. This risk-based view gives teams a safe path to bring useful automations into the open instead of hiding them to avoid friction.
Aona helps organisations make that transition through AI usage discovery, real-time guardrails, and employee coaching. If you are defining your first agent controls, begin with a 90-day Gen AI Risk Discovery Trial to find the AI activity you need to govern before it becomes an incident.
The point of agent governance is not to slow down automation. It is to ensure every automated action has an owner, a boundary, and a record. That is how enterprise AI becomes scalable rather than simply fast.
