AI Acceptable Use Policy vs AI Security Policy

Most organisations now have an AI policy, but many have one document trying to tell staff what they may paste into a chatbot, tell engineers how to secure a model endpoint and tell the board how AI risk is tiered, and it does none of the three well. An AI acceptable use policy (AUP) and an AI security policy answer different questions for different readers, are enforced by different mechanisms and change at different speeds. This guide is a clause allocation guide: it shows which requirements belong in the user-facing AUP, which belong in the AI security policy and its standards, which belong in neither, and who owns and enforces each one. It is for CISOs, AI governance leads, GRC teams and policy owners who are writing or splitting an AI document set. Ready-to-adapt wording is in the AI Acceptable Use Policy Template and the Agentic AI Security Policy Template; this page explains the boundary between them.

Key takeaways

Short answer: the AUP governs people, the security policy governs systems. The AUP tells every member of staff what they may and must not do with AI tools; the AI security policy tells the teams who buy, build and run AI what controls those systems must have.
Enforceability decides placement. A clause that you enforce through HR and acknowledgement belongs in the AUP; a clause that you enforce through architecture review, configuration baselines and audit belongs in the security policy and its standards.
Lists and values live outside both. Approved tools, model versions, data class limits and token lifetimes change monthly, so keep them in a register or standard that the policies reference, not in the approved policy text.
Agents sit on both sides. The AUP covers what a user may delegate to an agent acting with their access; the security policy covers how the organisation's own agents are identified, scoped, logged and stopped.
Frameworks expect both documents. NIST AI 600-1 calls for acceptable use policies for generative AI, ISO/IEC 42001 requires an AI policy and controls on responsible use, and EU AI Act Article 26 places operational duties on deployers that only a security standard can evidence.

Two documents, two audiences

The split mirrors the classic distinction between a rules of behaviour document and a security policy. NIST SP 800-53 Rev. 5 control PL-4 (Rules of Behavior) requires organisations to give people who need access "the rules that describe their responsibilities and expected behavior", to receive a documented acknowledgement before authorising access, and to have people re-acknowledge when the rules change. That is the AUP's job. CSF 2.0 GV.PO-01 asks for a policy for managing cybersecurity risk that is "established", "communicated and enforced", which is the security policy's job.

AI acceptable use policy: written for every employee, contractor and third party who uses AI for work. Plain language, readable in ten minutes, acknowledged on joining and on change, enforced through the disciplinary process. It covers approved tools, data rules, prohibited uses, human review of outputs, disclosure, delegation to agents and reporting.
AI security policy: written for system owners, AI platform teams, developers, procurement and the security function. It sets control objectives for AI systems the organisation acquires, builds or runs: identity and access for models and agents, data protection in pipelines, logging, testing, supplier assurance, incident handling and decommissioning. It is enforced through design review, release gates, configuration baselines and internal audit, and implemented through standards and procedures (see the Policy vs Standard vs Procedure vs Guideline guide for how those layers divide).
AI governance policy (the third document): the board-level statement of principles, risk appetite, roles and the AI risk tiering method. Both the AUP and the security policy sit under it. Wording is in the AI Governance Policy Template.

Side-by-side comparison

Attribute	AI acceptable use policy	AI security policy (with standards)
Primary reader	All staff, contractors, temporary workers	System owners, AI and platform engineers, procurement, security operations
Question answered	What may I do with AI at work, and what must I never do?	What must an AI system have before it goes live, and how do we keep it safe?
Subject of the rules	Human behaviour	Systems, configurations, suppliers and processes
Typical owner	AI governance group or CISO, with HR and legal sign-off	CISO or head of security architecture
Enforcement	Acknowledgement, training, monitoring of use, disciplinary process	Architecture review, release gates, baselines, audit findings, exception register
Change cadence	Annual review, faster when a new class of tool appears	Policy annual; standards whenever technology or threat changes
Worker consultation	Often required (employment law, works councils)	Rarely, unless it introduces staff monitoring
Framework anchor	SP 800-53 PL-4 and PS-6; NIST AI 600-1 GV-1.4-002; ISO/IEC 42001 B.9	CSF 2.0 GV.PO-01; ISO/IEC 42001 clause 5.2 and Annex controls; EU AI Act Article 26

What each document defends against

AUP threat model: the well-meaning or careless user

Data leakage through prompts and uploads: a user pastes customer records, source code or a contract into an unapproved tool whose terms allow training or retention.
Unvetted tools and delegated grants: a user signs up for a consumer AI app with a corporate account and grants it mailbox, drive or calendar scopes. The Vercel Context.ai OAuth breach began this way: an employee granted a consumer AI office suite broad access with a corporate Google account, the vendor was later breached and the stolen token gave the attacker the account.
Unsafe delegation: a user lets an agent send email, approve payments or change records with the user's own permissions.

Security policy threat model: the AI system as an attack surface

Prompt injection and tool misuse against applications and agents the organisation builds, including indirect injection through retrieved content.
Over-privileged machine identities: agents and model integrations holding long-lived API keys or broad OAuth scopes with no owner. See the Agent Identity and Access Guide.
Supply chain: third-party models, model hosting and plugins changing without notice; NIST AI 600-1 names "Value Chain and Component Integration" as one of its 12 generative AI risks.

A useful test: if the control fails because a person chose to break it, it belongs in the AUP. If it fails because a system was built or configured badly, it belongs in the security policy or a standard.

Clause allocation: which requirement goes where

The table allocates the clauses that most often end up in the wrong place. "Register" means the AI register or approved tools list, a controlled record outside both policies; see the AI Register and AI Inventory Template.

Topic	In the AUP	In the AI security policy or standard	In a register or other document
Data classes	Which classification may go into which tool status, in a simple matrix users can follow (for example Public and Internal into approved tools, Restricted nowhere without approval)	Technical enforcement: DLP or gateway inspection of prompts and uploads, tenant restrictions, retention and training opt-out settings per service	Classification definitions in the Data Classification Policy Template; per-tool data ceiling in the register
Approved tools	Use only tools in the register, under a corporate account; how to request a new one	Assessment criteria a tool must pass: SSO, logging, data residency, contractual no-training terms, admin consent for OAuth scopes	The tool list itself, with status (approved, approved with conditions, not approved)
Prohibited uses	Behaviour-level bans: no restricted data in unapproved tools, no AI decisions about people without review, no impersonation, no bypassing controls	Prohibited system designs: no autonomous action above a set risk tier without a human approval step, no shared credentials for agents	Legal list of prohibited practices under applicable law, maintained by legal
Human review of outputs	User duty to check accuracy, licensing and suitability before use or publication	Required oversight points and override mechanisms designed into systems by risk tier	Role assignments for oversight in the register entry
Agents acting for a user	What a user may delegate, which actions need their confirmation, never sharing their credentials with an agent	Agent identity, scoped and short-lived credentials, tool allowlists, action logging, kill switch	Agent entry in the register with owner and sponsor
Organisation-built models and agents	Not covered beyond "follow the AI security policy if you build AI"	Full lifecycle: threat modelling, red teaming before release, change control for model and prompt updates, decommissioning	Model and system cards, test evidence
Risk tiering	One line: some uses need approval first, with a link to the request route	Control baselines per tier (what a high-tier system must have)	The tiering method and criteria in the AI governance policy
Logging and monitoring	Transparency notice that AI use is monitored, what is logged and why	What systems must log, retention periods, who can access logs, alert use cases	Privacy notice and data protection impact assessment
Incidents	Report suspected misuse, leakage or harmful output, and how	AI incident classification, response playbooks, regulator notification triggers	Incident response plan
Enforcement	Consequences of breach, aligned with the general Acceptable Use Policy Template	Exceptions process, risk acceptance authority, audit	Exception register

Two clauses need care. Shadow AI handling straddles both: the user rule ("use only approved tools") sits in the AUP, while discovery, triage and blocking sit in the security side; many organisations give it a dedicated document, as in the Shadow AI Policy Template. Monitoring of staff use is a security control, but the notice to staff belongs in the AUP because transparency to the individual is what makes the monitoring fair and defensible under employment and data protection law.

Ownership and enforcement

Element	Accountable owner	Consulted before approval	Enforcement mechanism	Evidence
AI governance policy	Board or executive risk committee	CISO, legal, privacy, data, business leads	Management review	Approval minutes, review record
AI acceptable use policy	AI governance group (or CISO where none exists)	HR, legal, privacy, worker representatives	Acknowledgement, training gate, monitoring, disciplinary process	Acknowledgement records, training completion, case files
AI security policy	CISO	AI platform lead, enterprise architecture, procurement, privacy	Architecture review, release gate, audit	Review records, exceptions, audit reports
Approved tools register	AI governance group, operated by security	Procurement, privacy, legal	Access provisioning only for approved tools; blocking or coaching for others	Register history, assessment records
Exceptions	Risk owner at the level set by the risk appetite	CISO	Time-limited approval with compensating controls	Exception register with expiry dates

HR should approve the consequences clause and consultation route, not the technical controls; equally, an AUP issued by security without HR and legal review often cannot be enforced.

How the documents fit together

Described as an architecture, the set has four layers and one shared record:

Top: the AI governance policy sets principles, risk appetite, roles and the tiering method. It sits beside, or under, the Information Security Policy Template top-level policy.
Two topic policies: the AI AUP (people) and the AI security policy (systems).
Standards: AI security standards carry measurable values: credential lifetimes for agents, required log fields, pre-release test coverage, supplier assessment criteria. The AUP has no standards layer of its own; its "standard" is the data class matrix and the register.
Procedures: tool request, agent onboarding, red team sign-off, incident handling, exception requests.
The register: the shared record both policies point to. It holds tool status, data ceilings, owners and tier. NIST AI RMF GOVERN 1.6 asks for "mechanisms ... to inventory AI systems", and NIST AI 600-1 GV-1.6-002 asks organisations to define inventory exemptions in policy for generative AI embedded in application software, which is a governance policy decision the register then applies.

Worked scenario: one request, three documents

A sales team asks to use an AI meeting assistant that joins customer calls, transcribes them and drafts follow-up emails it can send from the salesperson's mailbox.

Governance policy: the tiering method rates the use. Customer personal data, external communication and an agent that can send email on a person's behalf place it in a higher tier needing AI governance group approval and a data protection impact assessment.
Security policy and standards: the security assessment applies the tier's baseline: SSO, admin-approved OAuth scopes limited to calendar and send-as for the named users, no vendor training on customer data, transcript retention set to the records schedule, audit logs exported to the SIEM, and a supplier assessment. The register entry is created as "approved with conditions" with a Confidential data ceiling and named owner.
AUP: nothing is rewritten. The existing clauses already say: use only tools in the register within their conditions, tell call participants when AI transcription is in use, review drafted emails before sending, and never connect the tool to a personal account. The salesperson's obligations come from the AUP; the tool's configuration comes from the standard.

With one combined policy naming tools and settings, this request would need a committee-approved amendment; with the split, it is a register change.

When to merge and when to separate

Small organisation (under about 250 staff, no in-house AI development): one AI policy with two clearly headed parts is acceptable, "Rules for staff" and "Rules for systems we buy", plus the register. Keep the staff part short enough to acknowledge separately.
Mid-size, buying AI and building integrations: separate AUP and AI security policy, with a combined AI standard covering identity, data and logging. Add agent clauses as soon as anyone connects an agent to business systems.
Large or regulated, building models and agents: AI governance policy, AUP, AI security policy, several AI standards (agent identity, model lifecycle, testing, supplier), and a separate shadow AI policy if discovery and blocking are active. Map each to ISO/IEC 42001 if you are pursuing certification; see the ISO/IEC 42001 Guide.
Separate AI security policy or annex? If existing standards already cover application security, identity and suppliers, add AI-specific standards instead. Create a separate policy when agent delegation, model change control and pre-release evaluation cannot be expressed in them.

Restructuring a combined AI policy

Inventory the statements. Extract every "must" and "must not" from the current document into a spreadsheet and tag each as person, system, list or principle.
Allocate. Person statements go to the AUP, system statements to the security policy or a standard, lists to the register, principles and tiering to the governance policy. Use the allocation table above.
Rewrite for the reader. Rewrite AUP clauses in second person plain language; rewrite security clauses as control objectives with a named responsible role.
Keep traceability. Record the old clause number against the new location so audit evidence collected under the old policy still maps. Auditors test the chain from requirement to evidence.
Consult. Run the AUP through HR, legal, privacy and, where required, worker representatives. Run the security policy through platform and procurement leads.
Pilot. Issue the AUP to one business unit with the acknowledgement flow and measure questions raised; apply the security policy to two live AI systems as a dry-run review.
Cut over. Approve both, retire the combined document, and collect fresh acknowledgements. PL-4 expects people who acknowledged a previous version to re-acknowledge.
Roll back if needed. Keep the combined policy available as superseded for one cycle so its rules can be reinstated if AUP consultation stalls.

Detection and measurement

Acknowledgement coverage: percentage of active users with access to approved AI tools who have acknowledged the current AUP version (target 100% before access).
Unapproved tool use: distinct unapproved AI services seen in proxy, CASB or OAuth consent logs per month, and the trend after each awareness push.
Register coverage: share of AI systems and agents found by discovery that have a register entry with owner and tier.
Security review coverage: share of production AI systems and agents with a completed review against the AI security standard for their tier.
Request cycle time: median days from a new tool request to a decision. A long cycle predicts shadow AI.

Common failure patterns

One policy doing all three jobs. Board principles, staff rules and engineering controls in one document. Staff do not read it, engineers cannot find the values and every tool change needs committee approval.
AUP with no technical backstop. A rule against restricted data in unapproved tools, with no consent controls or gateway inspection, relies entirely on memory. The Vercel Context.ai case shows how a single consented OAuth grant outlives the user's intent.
Security policy written for models only. Controls for model endpoints but nothing on agent identity, delegated access or tool permissions, so agents run on shared service accounts.
No consultation on monitoring. Monitoring of AI prompts introduced through the security policy without a notice in the AUP or a data protection assessment, which undermines enforcement when a case reaches HR.

Framework mapping

Framework	Requirement	AUP	AI security policy and standards
ISO/IEC 42001	Clause 5.2 AI policy; B.2.2 AI policy guidance	Reflects the AI policy for users	Reflects the AI policy for systems
ISO/IEC 42001	B.9.3 objectives for responsible use of AI systems	Primary home	Supports through oversight design
ISO/IEC 42001	B.4.2 to B.4.6 resource documentation; B.10.2 and B.10.3 third parties	No	Primary home, with the register
EU AI Act	Article 4 AI literacy (as amended by Regulation (EU) 2026/1744)	Literacy measures for staff using AI	Competence for operators and oversight staff
EU AI Act	Article 26 deployer obligations for high-risk systems: instructions for use, competent human oversight, input data, monitoring, logs kept at least six months, informing workers	Worker information (26(7)) and user duties	Oversight assignment, data, monitoring, log retention
NIST AI RMF	GOVERN 1.2, 1.6, 2.1, 6.1	1.2 and 2.1	1.2, 1.6, 2.1, 6.1
NIST AI 600-1	GV-1.4-002, GV-3.2-003, GV-6.1-010 acceptable use policies	Primary home	Informs system design limits
NIST CSF 2.0	GV.PO-01, GV.PO-02, GV.RR-02, PR.AT-01, PR.AA-05	GV.PO, PR.AT-01	GV.PO, GV.RR-02, PR.AA-05
NIST SP 800-53 Rev. 5	PL-4, PL-4(1), PS-6, AT-2, AC-20, SA-9	PL-4, PL-4(1), PS-6, AT-2	AC-20, SA-9
ISO/IEC 27001:2022	Annex A 5.1 policies; 5.10 acceptable use of information and other associated assets	5.10	5.1 topic-specific policy

Article 26 applies to deployers of high-risk systems. Under Article 113 as amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force 27 July 2026), the high-risk rules apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems, while Article 4 has applied since 2 February 2025. If you are unsure whether you are a provider or deployer for a given system, see the EU AI Act Provider vs Deployer Obligations Guide.

Practitioner checklist

Tag every clause in your current AI policy as person, system, list or principle, and move it to the matching document.
Keep the AUP short enough to read in ten minutes and get a documented acknowledgement before granting AI tool access.
Move tool names, data ceilings and model versions out of policy text into the register.
Write a data class to tool status matrix in the AUP and enforce it technically through consent controls and gateway or DLP inspection.
Add agent clauses to both documents: delegation rules for users, identity and scoping rules for systems.
Define control baselines per risk tier in the AI security standard and reference the tiering method in the governance policy.
Put the monitoring notice in the AUP and complete a data protection assessment before monitoring prompts.
Assign an owner, consultees and an enforcement route for each document, and an exception authority with expiry dates.

AI Acceptable Use Policy vs AI Security Policy: Which Clauses Go Where and Who Enforces Them