AI Agent Security Policy: What Yours Is Missing

Start an AI agent security policy review with the rules you already have. Service-account, automation and data-handling policies may already cover much of the work. The question is whether they cover the specific actions, data access and approvals your agents use.

Check whether your security policy covers AI agents

Read each clause looking for the actor and the control. If it relies on a person reviewing every step, check whether that still happens when software acts on their behalf. Existing machine-identity controls are a useful starting point, but their presence does not settle every agent-specific risk.

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.) The review should identify where untrusted content could influence actions and which controls limit those actions.

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. These four sections are useful places to start:

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 a person may not have reviewed, 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 may mistake embedded instructions for authority
Incident reporting	A human notices and reports	Actions that may complete between human reviews, requiring reliable logs and incident escalation

Who owns the agent when it goes wrong?

Name who can approve deployment, change permissions and stop the agent. If several teams are involved, document how they divide those decisions.

NIST’s voluntary AI Risk Management Framework calls for clear, documented responsibilities and communication for AI risk, and assigns executive leadership responsibility for development and deployment risk decisions. It does not prescribe a particular person’s name in each policy.

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. A department can own a process if its decision-maker and escalation route are clear; avoid an assignment that leaves nobody authorized to act.

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.

My recommended identity clause covers three decisions:

Give each agent or workflow a distinct, attributable identity where supported. Separate revocation should be possible without unnecessarily disabling unrelated work.
Scope its permissions to the task. For delegated access, apply both the user’s authority and the narrower task policy. For organization-owned automation, document an explicit ceiling rather than inventing a user to inherit from.
Prefer short-lived credentials where the service supports them. Define renewal, revocation and rotation for the credentials actually in use.

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

Illustrative mapping, not a product audit. Test each listed control; an enabled setting alone does not prove complete enforcement.

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

A policy needs a way to influence behavior. For each rule, identify whether it is enforced by a credential, a tool restriction, an approval gate, monitoring or a human procedure. These controls have different failure modes; the document should make them visible.

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, protect audit records from alteration or deletion by the agent being audited. Legitimate log reading and append-only event submission are compatible with that goal. Keep authoritative records and retention controls outside the agent’s ability to rewrite them, and test that the events needed for an investigation are recorded.

Do you need ISO 42001 certification for AI agents?

You do not have to invent the risk list. These three sources offer useful starting points for different parts of the review.

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 focuses on risks in systems that plan and act across workflows. It complements the LLM application list. Read it as a checklist of things your policy should have an opinion about.

NIST AI RMF also addresses third-party AI risks and contingency processes for failures in high-risk third-party data or systems. Include those dependencies even when you build the agent yourself.

ISO/IEC 42001 covers AI management systems. Its free explainer describes the scope; consult the standard when you need its full requirements. Certification is voluntary under the standard and is performed by independent bodies, not ISO. A customer contract or applicable obligation can still make certification relevant to your organization. Vetting AI vendors explains why certificate scope matters.

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 sensitive disclosures or 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?

Manage it as software operating through an identity: a service account, workload identity or delegated user access. Whether it is privileged depends on its permissions and data access. Read-only access to sensitive records can still be privileged. Give it an accountable owner, task-scoped access and a credential lifecycle. Then limit how untrusted content can influence the actions it requests.

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?

Existing security controls can apply to AI systems, but their assessed scope matters. SOC 2 is an attestation report on controls, not a general AI-safety certification. ISO/IEC 42001 addresses AI management systems; it does not replace laws or prove that an individual agent is safe. Review the controls covering your actual deployment.

How have companies that banned AI outright fared?

This article does not establish a measured outcome for companies that ban AI. A restriction can be appropriate, but it needs a defined scope, enforcement and an exception process. Consider whether a permitted alternative is available and check actual usage instead of assuming either that the ban worked or that everyone bypassed it.

Sources

NIST AI RMF and ISO/IEC 42001 are voluntary frameworks, not regulation, and ISO does not itself certify organisations. The policy recommendations here are editorial guidance; the personal example is not a test of a product’s permission enforcement.

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