AI Agent Security Policy: What Yours Is Missing

You do not need a new AI agent security policy so much as an honest read of the one you already have. It was probably written for a world where a person opens a tool, types something, and decides what to do with the answer, and its clauses assume, without saying so, that a human is the one acting.

Agents break that assumption without announcing it. Nothing in the document is wrong, exactly. It just stops describing what is happening.

Why your security policy does not cover AI agents

Pull up your current policy and read it looking for the actor. Acceptable use, data classification and incident reporting usually name a person, or imply one, and the controls hang off that person’s judgment and that person’s account. Access control is the exception, and a useful one: if you already have a service account or machine identity section, there is somewhere to put an agent, which is further along than a lot of small teams. The rest of the document still assumes a human.

Now add software that holds credentials, reads untrusted content, chains several steps together, and takes actions between the moment you ask and the moment you see a result. (AI agent security risks covers what goes wrong at that point; this post is about the paperwork that has not caught up.) Practitioners describing this gap online keep landing on the same phrasing, that policies still read like it is 2023, humans using tools, nothing about semi-autonomous software acting on someone’s behalf.

The useful move is not to start over. It is to walk the policy you have and mark the places where “the user” is doing something an agent now does instead. Four sections carry most of the drift:

Existing clause	What it assumes	What it has to account for once agents act
Acceptable use	A person chooses what to put into a tool	Software that ingests content nobody chose, including web pages and documents it was pointed at
Access control	Accounts belong to employees, contractors or services	A non-human identity that either borrows a person’s authority or holds its own, and needs a stated ceiling either way
Data classification	Data is handled by someone who can be told the rules	Data pulled by a process that follows instructions found inside the data
Incident reporting	A human notices and reports	Actions that complete without anyone seeing them, so the log is the only witness

Who owns the agent when it goes wrong?

Ask this before anything technical, because in most organisations the answer is a pause. The recurring complaint in practitioner discussion is an ownership vacuum: is an agent a development problem, a security operations problem, an application security problem? Everyone can name a team that is adjacent. No one has been handed it.

This is not a new problem and it has a standard answer. NIST’s AI Risk Management Framework asks that “roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization,” and separately that “executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment.” The framework is voluntary, so treat those as a description of what good looks like rather than a rule you are breaking.

For a small team the practical version is one line in the document naming a person, not a function. A named owner who can be wrong beats a committee that cannot be found. Above that size the usual objection applies and it is a fair one: people change teams and leave, and a policy you have to reopen every time is a policy that goes stale. The standard answer is to put the role in the document and the current holder in a register you can update without an amendment. What you are avoiding either way is the department as owner, because “IT owns it” is how a thing ends up owned by no one.

An AI agent security policy needs an identity clause

Here is where an existing policy tends to run out of room. Your access control section probably covers employees, contractors and service accounts, and in practice an agent runs as the third: a service account, a workload identity, or a delegated user token. So the category already exists. What is missing is anything that separates an agent from a cron job, because this particular service account chooses what to do next based on text it just read.

Practitioners working on this describe the fix as treating each agent as its own identity with scoped, short-lived credentials rather than as a feature of the product it sits inside. That has three consequences your policy can state plainly:

Each agent gets its own credential, not a shared key, so access can be revoked without collateral damage.
Its permissions are scoped to the task, with a ceiling written down. Where it acts for a person, that ceiling is their access. Where it runs on the organisation’s behalf, there is no user to inherit from, so the ceiling has to be named outright.
Its credentials are short-lived, and somebody owns the decision to keep renewing them.

If you want the mechanics behind that, limiting AI agent permissions covers how to draw the lines. The policy layer only has to say that agents are identities and that someone reviews the list.

Four clauses of an AI agent security policy checked against the runtime, two backed by a real control, one only partially, and one with nothing behind it at all

Run your own policy through this and the interesting row is the bottom one. A clause with nothing on the right-hand side is a statement of intent.

How to tell if your AI policy is enforced or just filed

This is the part that separates a policy that changes outcomes from one that gets filed. The sharpest version of it in practitioner discussion is that a policy document only matters if the runtime turns it into behaviour: tool limits, approval thresholds, data scope, and stop conditions. A rule that nothing checks is a preference.

Two consequences follow, and both belong in the document rather than in someone’s head.

First, decide where each rule is enforced. “Agents may not touch production data” is a sentence in a file until a credential cannot reach production. Write the rule and, next to it, the place it is enforced. Where the honest answer is “nowhere yet,” that is a finding, not a failure, and it is more useful written down than left implied.

Second, keep the audit trail out of reach of the thing being audited. A point made repeatedly by people running these systems is that an agent able to alter or delete its own audit trail has already defeated the audit. Reading its own logs can be perfectly legitimate, for a health check or a retry decision. Write access is where the line sits, and it is a small architectural note with an outsized effect on whether an investigation is possible later.

Do you need ISO 42001 certification for AI agents?

You do not have to invent the risk list. Three published sources will do most of the work, and two of the three are free to read.

OWASP published a Top 10 aimed specifically at agentic applications on 9 December 2025, badged as the 2026 edition. It is peer reviewed and was assembled with more than a hundred contributors, and it exists precisely because the earlier LLM list did not cover what happens when a model gains goals, tools, and memory. Read it as a checklist of things your policy should have an opinion about.

NIST’s AI RMF gives you the governance scaffolding, including a third-party clause that is easy to leave out: it asks for “policies and procedures … that address AI risks associated with third-party entities” and for contingency processes covering failures in third-party AI systems. Even an agent you built and host yourself is usually calling somebody else’s model.

ISO/IEC 42001 is the management-system standard, and it is the one to be careful about. It is the paid one: the standard itself sells for a few hundred dollars, while ISO’s own explainer page is free and covers enough to work from. Certification is voluntary, ISO does not issue it, and the useful question is what a certificate’s scope covers, which vetting AI vendors goes into. For your own policy, the standard is more useful as an outline than as a goal.

My own rule is one line: the agents I run may read anything in the project, and have to ask before they modify or delete a file. Then I ran the test above on it and got a less comfortable answer than I expected. I remember approving file changes, so something is asking. What I cannot tell you is whether that is the tool enforcing a permission or the agent following an instruction I gave it, and those are the two sides of the distinction this section is about. Not being able to say which one you have is itself the finding.

Test your AI agent policy with one question

Take the policy you just marked up and try to answer this: last month, which agents ran, what did each one have access to, and who approved the actions that could not be undone?

If the document tells you where to look, it is doing its job. If answering means asking around, the gap is not in the writing. Everything above is a way of closing the distance between what a page claims and what a system permits, and one honest attempt at that question will show you which clauses to fix first.

FAQ

Should an AI agent be managed like an employee, an application, or a privileged account?

Closest to an application, and specifically to a service account or workload identity. Whether it is also a privileged-account problem depends on what it can reach: a read-only research agent is not one, an agent holding production credentials is. Either way it needs its own identity, scoped permissions, an owner and short-lived credentials. What separates it from an ordinary service account is that it acts on natural-language instructions found in content it reads, so it also needs limits on what it may act upon, not only on what it may reach. The employee model is the weakest of the three, because the thing that makes it work for people, that they weigh a situation and answer for the outcome afterwards, has no equivalent here. Consequences still exist; they land on you and on the credential rather than on the agent.

Is anyone enforcing AI governance, or just writing policies?

Both exist, and the split is visible in one question: for any rule in your policy, can you name the system that would stop a violation? Where the answer is a person noticing, the rule is guidance. That is not automatically wrong, since a small team may reasonably accept guidance for low-risk cases, but it should be a decision you made rather than one you discover during an incident.

Is AI compliance a real concern or just SOC 2 with more paperwork?

The overlap is real but partial. General security certifications cover how an organisation runs, and they were not written with model behaviour or agent autonomy in mind, which is why ISO/IEC 42001 exists as a separate AI management standard. Treat existing certifications as the baseline they are, then ask the questions none of them ask, starting with what your agents can reach without a human.

How have companies that banned AI outright fared?

What practitioners describe most often is a ban moving the activity rather than stopping it, toward personal accounts and devices where there is no logging at all. Read that as a recurring account rather than a measured outcome, because how far it holds depends on what else is in place: network controls and a sanctioned alternative change the result. A ban is also the right call in some regulated settings. Either way it needs the same enforcement question as any other clause, plus somewhere legitimate for the work to go, or it mostly converts a visible risk into an invisible one.

Sources

NIST AI RMF and ISO/IEC 42001 are voluntary frameworks, not regulation, and ISO does not itself certify organisations. Descriptions of ownership gaps and enforcement practice reflect ongoing practitioner discussion rather than survey data; no claim is made here about how many organisations have updated their policies.

Written by Grace

I test AI tools and agents in my own workflow, and write down what I find, including the settings that surprised me. About Grace and how posts are verified