What should an AI security policy contain?

Scope and definitions, approved providers and endpoints, prompt data classification, identity binding, role-scoped authorization, autonomous agent constraints, response handling, logging and retention, third-party AI requirements, incident response, and an exception process with expiry. The structure matters less than whether each clause names the system that observes it.

How is an AI security policy different from an acceptable use policy?

An acceptable use policy addresses how people may use AI tools and is governed by HR and training processes. A security policy addresses the technical controls on AI traffic, including identity, authorization, data classification, logging, and provider constraints, and most of its clauses should be enforceable by systems rather than by employee behavior.

Can an AI security policy be technically enforced?

The clauses covering approved endpoints, prompt data classes, identity binding, role-scoped authorization, agent call budgets, and logging are enforceable at the AI request layer. Clauses covering procurement, training, definitions, and exception governance stay administrative. Marking which is which before publishing prevents the document from claiming controls that do not exist.

Who owns the AI security policy?

Security owns the control clauses, and legal or compliance owns the regulatory mapping, with a named executive accountable for exceptions. The failure mode is joint ownership with no single approver for exceptions, which is how a temporary carve-out for one team becomes the operating standard within two quarters.

AI Security Policy: The Eleven Clauses That Have to Be Enforceable

Netwrix found that 97% of organizations that suffered an AI-related breach lacked proper access controls for AI services, while only 37% have any detection or governance policy for AI usage at all (Netwrix). Read those two numbers together and the picture is a set of organizations that mostly wrote nothing, and a subset that wrote something and still had no control behind it.

I have read enough of these documents to notice the pattern in the ones that fail. They are well organized, they cover approved tools and prohibited data, they get signed by three executives, and every clause is stated as an expectation of human behavior. Nothing in the environment can tell whether any clause held on a Tuesday afternoon in March.

The test I apply to each clause is one question: what system observes this, and what record does it write. A clause that answers with "the employee's judgment" is a training item. A clause that answers with a named control and a record is a policy.

The eleven clauses

1. Scope and definitions

Name what the policy governs. Employee use of external AI assistants, application code calling model APIs, autonomous agents, vendor SaaS features with embedded models, and self-hosted inference each behave differently and each needs to be in or out by name. A scope written as "artificial intelligence" leaves every argument for later.

Evidence: administrative. This clause is definitional and that is fine.

2. Approved model providers and endpoints

An explicit list of provider endpoints applications and staff may call, with an approval path for additions. Vague approval of "enterprise-tier tools" produces a list nobody can act on.

Evidence: enforceable. Constrain egress so the only route to any model endpoint runs through a control point, then the allow-list is a configuration rather than a hope. Without that constraint every other clause degrades to an honor system, which is why this one sits so early.

3. Data classification for prompts

State which data classes may appear in a prompt, by class, per provider tier. Customer PII, regulated health or financial data, credentials, source code, and unreleased commercial material each need a named position. 77% of employees using unauthorized AI admit to pasting sensitive business data into unsanctioned models (Cloud Radix), so the clause covering this is the one doing the most work.

Evidence: enforceable at the request layer. Classification has to run on the assembled prompt, because that is where the exposure sits. A data source labeled once at rest tells you nothing about what a user pasted into a context window at 4pm.

4. Identity binding for every call

Every model call is attributable to a person or a named non-human identity. Shared API keys across multiple services or agents break attribution before any incident occurs.

Evidence: enforceable. The failure mode is documented: with several agents on one key, forensic reconstruction stops at the credential and nobody can say which agent did what. The mechanism is in AI agent identity.

5. Authorization scoped by role

Policy references identity, not just content. A support agent may reference an account number in a prompt where a marketing agent may not, and that distinction cannot be expressed by a content filter alone.

Evidence: enforceable at the request layer, where the caller identity and the prompt content are both available in the same decision.

6. Autonomous agent constraints

Agents get their own clause: per-step authorization rather than a session grant, a ceiling on model calls per task, scoped tool credentials, and named human approval points for actions with external effect.

Evidence: split. Call budgets and per-step policy are enforceable at the request layer. Tool credential scoping lives in the database grants, cloud IAM, and filesystem permissions, and no HTTP control substitutes for those. Say so in the policy so the ownership is written down.

7. Response handling

Model output that flows into another system needs constraints: schema validation before parsing, no direct execution of returned code or commands, and policy on responses that carry regulated content back to a user.

Evidence: partly enforceable. Response-side policy at the request layer can evaluate what comes back. Whether the application then executes it is application code, covered by OWASP LLM02 insecure output handling.

8. Logging and retention

Specify what gets recorded per model call, where records are written, how long they are kept, and who can alter them. Retention driven by the strictest applicable regime rather than the most convenient one.

Evidence: enforceable, and this clause determines whether the other ten can ever be demonstrated. A record written by the application that made the call is an attestation from the party being audited. A record written outside it is evidence. Retention specifics are in AI audit log retention period.

9. Vendor and third-party AI

Requirements for procuring AI features and for vendors embedding models in products: data handling terms, sub-processor disclosure, retention and training-use commitments, and evidence obligations.

Evidence: administrative at procurement, observable in operation. When a SaaS vendor's embedded assistant calls a model from your users' browsers, that traffic is visible at the request layer even though the contract is a document.

10. Incident response for AI events

Define what counts as an AI security incident, who is paged, and what evidence gets collected. A prompt carrying regulated data to an unapproved endpoint is an incident with a named owner, or it is nothing.

Evidence: enforceable in the sense that the evidence has to exist before the incident. Mandiant's M-Trends 2026, built on more than 500,000 hours of frontline incident response, found the median time from initial access to handoff to a secondary threat group collapsed from over 8 hours in 2022 to 22 seconds in 2025 (Help Net Security). At that tempo, evidence gathered after the fact is a post-mortem, not a response.

11. Exceptions and review

A named exception process with an owner, an expiry date, and a review cadence. Exceptions without expiry become the policy within about two quarters.

Evidence: administrative, and worth instrumenting anyway. An exception recorded as a policy rule at the request layer expires when its rule expires, which beats a spreadsheet.

The clause I would add that nobody asks for

Write down what the policy does not cover, by name. Local model execution on a developer machine, code running inside a notebook with weights loaded in-process, an engineer's personal account on their own hardware. Those sit outside anything the network sees, and a policy that quietly implies coverage there is worse than one that says the boundary out loud and assigns those risks to endpoint controls. The uncomfortable clause is the one that makes the rest credible.

From document to control

The migration path is short and most teams skip the first step. Take the finished policy and, clause by clause, write the name of the system that observes it and the record it produces. Any clause where both columns are empty is a training item, and it should be moved to the training document rather than left in the policy pretending to be a control. What remains is a policy an assessor can test. Related structure for the acceptable-use side is in AI acceptable use policy template and the governance frame in AI governance policy.

DeepInspect

This is exactly what DeepInspect does. Six of the eleven clauses above resolve to a decision on an HTTP request between an authenticated caller and a model endpoint, and DeepInspect sits inline at that boundary.

For every request, DeepInspect binds the call to the identity the caller presents, classifies the prompt against your own data classes, evaluates identity-aware policy, and returns a deterministic fail-closed decision before the request reaches the provider. Approved-endpoint rules, data-class rules, role-scoped authorization, and agent call budgets become configuration that executes rather than text people are asked to remember. Every decision commits a signed audit record on a write path the calling application never controls, which is what turns clause 8 into evidence. DeepInspect governs the model traffic and leaves endpoint controls, IAM grants, and procurement to the systems and teams that own them. If your AI security policy is signed and nothing in your environment can tell you whether it held last Tuesday, book a demo today.