AI Policy is Not Agent Policy
Policy, Standard, Procedure, Control. AI policy governs how humans use AI as a tool. Agent policy governs AI as a non-human actor. Conflating them, or conflating the governance layers, is how autonomous software ends up in production with no defensible answer to the questions that matter.
Most enterprises now have an AI policy. They wrote it sometime in the last eighteen months, usually in response to a board question, a regulator nudge, or the day they noticed someone in finance pasting customer data into a public chatbot.
It is a reasonable document. It says reasonable things. Use the approved enterprise model tier. Do not disclose confidential data to third-party models. Disclose AI-generated content where required. Get security review before training on customer data.
And it is almost completely insufficient for the thing that is already happening inside the same enterprise.
Because an AI policy governs how humans use AI. It does not govern what AI does on its own.
Those are not the same problem. The controls are not the same. The accountability model is not the same. And the document that covers one does not cover the other.
Before going further, it is worth being precise about what a policy actually is, because part of what makes this topic confusing is that "AI policy" gets used to mean four different artifacts at four different altitudes.
A Quick Note on Governance Hierarchy
Mature governance programs distinguish between four layers. They are not interchangeable, and the words matter.
Policy is the highest-altitude document. It states principles, scope, and accountability. It is approved by senior leadership and changes rarely. A policy is something like: "All non-human identities operating in the enterprise environment must have a registered owner, an approved scope, and an auditable record of actions." It does not name systems. It does not specify thresholds. It does not tell anyone how to do the work.
Standard is the next layer down. It is mandatory and specific, but still vendor-neutral. A standard takes a policy principle and translates it into measurable requirements. "All non-human identities must use cryptographic credentials rotated at intervals no greater than ninety days, must be enrolled in the enterprise identity provider, and must be tagged with owner, business purpose, and data sensitivity classification." Standards are where "shall" language lives. They are usually owned by a control function like Security, GRC, or Identity.
Procedure is the operational layer. It tells a specific team how to comply with the standard inside a specific system. "To onboard a new agent in the AP environment, the Finance Operations team must submit a registration request via the Agent Registry, attach a scope of authority document signed by the agent owner and the InfoSec reviewer, and complete pre-production review checklist AGT-PROC-014." Procedures name systems, owners, and steps. They are owned by the team that operates the thing.
Control is the enforcement mechanism. The actual technical or process check that proves the procedure is followed. A required field in the registry. A scheduled audit. A blocking gate in the deployment pipeline. A SIEM rule. Controls are what an auditor tests, and what survives the inevitable "show me" moment.
A policy is short. A standard is specific. A procedure is operational. A control is enforced.
Confusing these layers is the most common reason governance documents are simultaneously too vague to be useful and too detailed to be approved. Knowing which layer you are writing at is half the work.
With that in mind, the rest of this article uses "policy" in its precise sense: the principles and accountability statements that everything else hangs from. The detail belongs downstream.
Where AI Policy Stops
A typical enterprise AI policy is an acceptable-use policy with AI-specific clauses bolted on. It assumes a human in the driver's seat. A person opens a chat window, types a prompt, reads the output, decides what to do with it. The policy tells that person what is in bounds.
The control surface is the human. You train them. You audit their behavior. You revoke their access if they misuse it. The model itself is mostly passive, a tool the human picks up and puts down. The principles the policy sets are about how that human exercises judgment.
A well-formed AI policy typically establishes principles in these areas:
- Approved model tiers for different data classifications
- Data handling expectations when interacting with AI tools
- Intellectual property and training data considerations
- Disclosure expectations for AI-assisted output
- Vendor and model approval accountability
- Acceptable-use boundaries and prohibited applications
This is real work. It is the right work. It is just not the only work, because none of these principles describe a non-human actor that takes its own actions in your environment.
What Changes With Agents
An agent is not a person using AI. An agent is software that uses AI to decide what to do next, and then does it.
That distinction sounds small. Operationally it is enormous.
The moment you put an agent into production, three things change in ways your AI policy does not address.
First, the agent has its own identity. It logs into systems. It holds credentials. It makes API calls. It is, for practical purposes, a non-human user of your stack. It needs to be enrolled, attributed, and lifecycle-managed like any other identity, which is something an AI policy does not typically address because AI policies do not assume the AI is the actor.
Second, the agent takes actions, not just produces output. It moves data. It creates records. It updates systems. It sends communications. It invokes other tools, sometimes other agents. The thing it does is not a recommendation for a human to consider; it is a change to the state of the world. The accountability model for "the AI suggested this and a human chose to act" is different from "the AI acted."
Third, the agent operates without a human in the loop on every step. That is the entire value proposition. If a human had to approve every action, you would not need an agent, you would need a workflow tool. The whole point of agentic systems is that they exercise some degree of bounded autonomy. The boundedness has to come from somewhere, and "the human's good judgment" is not available, because the human is not in the loop.
An acceptable-use policy aimed at humans cannot govern any of this. There is no human at the keyboard to discipline. There is no prompt to review. There is no "did the employee follow the policy" question to answer, because there is no employee.
You need a different policy. And, downstream from that policy, you need standards, procedures, and controls that look fundamentally different from the ones you already wrote for AI.
What an Agent Policy Actually Says
A well-formed agent policy is closer in spirit to a non-human identity policy than to an acceptable-use policy. It establishes principles about something that acts in your environment, not about how humans use a tool.
At the policy layer (high altitude, principles only, no system names, no thresholds), an agent policy typically establishes the following:
Identity and ownership. Every agent operating in the enterprise environment must have a registered, attributable identity, an accountable human owner, a documented business purpose, and a defined lifecycle from onboarding to decommissioning. There is no such thing as an unowned production agent.
Authority and scope. Every agent operates within an explicitly approved scope of authority. The scope defines what the agent is permitted to do, not merely what it is technically capable of doing. The principle is that capability is not consent.
Proportionality of oversight. The degree of human oversight required for an agent's actions must be proportional to the consequence of those actions. Actions with material business, financial, regulatory, or customer impact require human-in-the-loop checkpoints. The specifics of where those checkpoints sit are defined in the standard, not in the policy.
Attribution and audit. Every action taken by every agent must be attributable. The record must identify the agent, the human owner accountable for the agent, the system acted upon, the action taken, the time, and the basis for the decision. The record must be sufficient to satisfy regulatory, legal, and customer inquiries without reconstruction.
Inter-agent accountability. When one agent invokes another, or when multiple agents operate against shared systems, accountability for the resulting actions must remain clear. No action may be taken in a manner that obscures which agent and which human owner are responsible.
Lifecycle and decommissioning. Every agent has a defined end state. Agents that are no longer in active use must be retired in a manner that revokes credentials, preserves audit records, and resolves in-flight work without ambiguity.
Change governance. Material changes to an agent's scope, identity, or behavior require review and approval through documented governance processes. Agents do not silently grow new capabilities.
That is roughly what the policy layer looks like. Notice what is not there: no system names, no specific thresholds, no procedural language. A policy that says "all agents handling invoices over fifty thousand dollars must flag for review" is not a policy. It is a procedure that got promoted by mistake.
The Same Use Case Across the Hierarchy
To make this concrete without re-collapsing the layers, here is how a single use case (an agent that processes inbound vendor invoices) is governed at each layer.
At the policy layer: All agents operating in finance systems must have a registered identity, an approved scope of authority, defined human-in-the-loop checkpoints proportional to action consequence, and complete audit attribution.
At the standard layer: Agents operating in accounts payable systems must (a) be enrolled in the Agent Registry with owner, business purpose, and data sensitivity classification; (b) authenticate with rotated cryptographic credentials; (c) be restricted to read and draft operations on invoice records, with all approval and payment-initiation actions reserved to human users; (d) flag for human review any action exceeding the materiality threshold defined in the AP Materiality Standard; (e) log every action to the enterprise audit pipeline with full attribution.
At the procedure layer: To onboard a new accounts payable agent, the Finance Operations team submits an Agent Registration form to the Agent Governance Board, attaches a Scope of Authority document signed by the agent owner and the InfoSec reviewer, completes the AP Pre-Production Checklist, and routes the request through the standard change advisory process. Post-deployment, the agent's actions are reviewed weekly against the AP Agent Operational Dashboard, and quarterly by the Agent Governance Board.
At the control layer: The Agent Registry enforces required fields at registration time. The identity provider blocks authentication for any agent not enrolled in the registry. The AP system's API gateway rejects requests from agents whose scope does not include the requested operation. The audit pipeline flags any agent action lacking attribution metadata. The change advisory tool blocks deployments that have not completed the AP Pre-Production Checklist.
Four layers, one use case, four different artifacts. The policy is principle and accountability. The standard is mandatory specificity. The procedure is operational. The controls are enforced.
If your "agent policy" tries to do all four jobs in one document, you will end up with something that the board cannot approve (because it is too detailed) and the engineering team cannot use (because it is too vague). The whole point of the hierarchy is to let each layer do its own job.
Why This Distinction Matters Now
A large share of agents already running inside enterprises today are governed by default under an AI policy, which is to say, not really governed at all. The AI policy was written for humans typing into chat windows. The agent is doing something completely different. The mismatch is not yet visible because nothing has gone catastrophically wrong. That is a fragile equilibrium.
The moment an agent takes an action that produces a meaningful consequence (a wrong payment, a leaked record, an inappropriate communication, a deleted ticket, an unintended escalation), the questions arrive in a specific order: what was this thing, who owned it, what was it allowed to do, what did it actually do, and where is the record. Those questions are not answered by an acceptable-use policy. They are answered by an agent policy, the standards that flow from it, the procedures that operationalize it, and the controls that enforce it.
"The AI policy covers it" is not a serviceable answer to a regulator, a customer, an auditor, or a board. The honest answer is one of two things. Either: yes, here is the agent's registered identity, here is its approved scope, here is the human owner, here are the controls that should have prevented this, here is what we found in the post-incident review. Or: we did not have any of that, because we treated this autonomous software as if it were a person using a chatbot.
Only one of those answers preserves the program.
Where to Start
If your organization has an AI policy and does not yet have a distinct agent policy, the practical first moves are sequenced, not parallel.
Start by inventorying the agents that already exist. Most enterprises have more than they realize. The inventory typically includes purpose-built agents engineering has shipped, agentic features inside existing SaaS products (anything marketed as "autopilot," "auto-resolve," "auto-action," or "agent"), low-code automations that have been extended with LLM calls, and a long tail of department-built tools that nobody has formally registered. The inventory itself is the first useful artifact, because you cannot govern what you cannot see.
Once the inventory exists, the second move is ownership. Every agent on the list needs an accountable human owner. Not a team. Not a shared inbox. A named person who is responsible for the agent's behavior and its lifecycle. Where no owner can be identified, the agent should be a candidate for retirement.
The third move is the policy itself. Short. Principle-based. Approved at the right altitude. The policy should establish that agents are non-human actors, that they require registered identity, approved scope, proportional oversight, complete audit attribution, lifecycle discipline, and accountable ownership. The policy should not name systems, thresholds, or procedures.
The fourth move is the standard. This is where the specificity arrives, but still in a vendor-neutral form. The standard translates each policy principle into measurable requirements. It is owned by the function that will be asked to certify compliance.
The fifth move is procedure. Specific teams write specific procedures for the specific agents they operate, in the specific systems they operate in. This is the layer where reality intrudes, and it should.
The sixth move is controls. The technical and process enforcement that makes the procedures real. A registry that blocks unenrolled agents. An identity provider that refuses unauthenticated ones. An audit pipeline that flags missing attribution. A change process that gates scope expansion.
This sequence matters. Trying to start with controls (the temptation, because they are tangible) produces enforcement for which there is no governing principle. Trying to start with a single all-encompassing document (also a temptation, because it feels efficient) produces something nobody can approve and nobody can use.
The work is not glamorous. It is not the part of AI that ends up in press releases. But it is the difference between agents that quietly do useful work and agents that quietly create the next incident, the next regulatory finding, the next board-level question that no one in the room can answer.
An AI policy got the organization to the starting line. An agent policy, with the standards, procedures, and controls that flow from it, is how the organization actually runs the race.