> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up.md).

# G.6 Write an AI Acceptable Use Policy that holds up

A reusable AUP template covering approved tools, data classes, personal accounts, connectors, agents, coding tools, mobile apps, and incident duties.

*Last reviewed: August 18, 2026*

{% hint style="info" %}
An AI acceptable use policy should tell employees what they can use, what data they can enter, what actions need approval, and what to do when something goes wrong. It should match the controls security can actually enforce.
{% endhint %}

This page gives a policy template. Adapt it with legal, HR, privacy, compliance, and works-council review where required.

## Draft policy

### AI acceptable use policy

### 1. Purpose

This policy defines how employees, contractors, and approved third parties may use artificial intelligence tools for company work. It applies to chat tools, coding assistants, browser and desktop agents, AI features inside SaaS applications, AI connectors, plugins, MCP servers, low-code agents, hosted agents, APIs, and mobile AI applications.

The goal is to let teams use approved AI tools while protecting company data, customer data, credentials, intellectual property, regulated information, and business operations.

### 2. Scope

This policy applies when a person uses AI for company work, whether the tool is provided by the company, embedded in another application, accessed through a browser, installed on a device, connected through an API, or used through a personal account on a company device.

This policy also applies to AI agents that can read files, call tools, browse websites, write code, send messages, update records, or take actions through connected systems.

### 3. Approved tools

Employees may use only AI tools approved by the company for company work.

Approved tools are listed in the company AI tool catalog. The catalog identifies:

* Approved users or groups.
* Approved data classes.
* Allowed connectors and integrations.
* Allowed model or agent features.
* Required approvals.
* Owner and support path.
* Review date.

Employees must not use unapproved personal AI accounts for company work.

### 4. Account requirements

Company work must be performed through managed company accounts when an approved enterprise account exists.

Employees must not:

* Use personal AI accounts for company work.
* Upload company data to a personal AI account.
* Connect personal cloud storage, email, chat, calendar, code repositories, or productivity accounts to AI tools for company work.
* Share company AI accounts.
* Use another employee's AI account or API key.

### 5. Training and AI literacy

Employees must complete the AI training assigned to their role before using approved AI tools for company work. Training should cover the approved tools, data rules, output review, prompt injection, agent actions, incident reporting, and any use-case-specific legal or safety duties.

People who approve, monitor, or conduct human review of higher-risk AI workflows need additional training and authority appropriate to that role.

### 6. Data handling rules

Employees must follow the data classification rules for AI use.

| Data type                                              | Default rule                                                                                                                  |
| ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| Public information                                     | Allowed in approved tools.                                                                                                    |
| Internal business information                          | Allowed in approved tools unless restricted by team policy.                                                                   |
| Confidential company information                       | Allowed only in approved enterprise tools with approved retention and logging.                                                |
| Customer confidential information                      | Allowed only when the tool and workflow are approved for that data class.                                                     |
| Regulated personal data                                | Requires legal, privacy, and security approval before use.                                                                    |
| Secrets, passwords, API keys, tokens, and private keys | Not allowed in prompts, files, tools, logs, or agent environments unless a security-approved workflow explicitly requires it. |
| Source code                                            | Allowed only in approved coding tools and repositories under the required controls.                                           |
| Legal, HR, finance, health, and employment data        | Requires function-owner approval and may require privacy or legal review.                                                     |

When in doubt, do not enter the data into an AI tool. Ask the data owner or security team.

### 7. Connectors, plugins, MCP servers, and integrations

Employees may use only approved connectors, plugins, MCP servers, browser extensions, desktop extensions, and AI integrations for company work.

New integrations require review before use. Review must cover:

* What data the integration can read.
* What actions it can take.
* Which identity it uses.
* Where data is sent.
* What logs exist.
* How access is revoked.
* Who owns the integration.

Employees must not install or enable integrations that bypass company identity, DLP, logging, or approval controls.

### 8. Agents and autonomous actions

AI agents must be approved before they are used for company work if they can:

* Read or write files.
* Browse websites.
* Use signed-in sessions.
* Call connectors or APIs.
* Send messages.
* Create, edit, or delete business records.
* Run commands or code.
* Access customer, employee, or regulated data.
* Continue running without a person actively supervising the task.

High-impact or irreversible actions require human approval unless security, legal, and the business owner approve a documented exception.

Agents must have a named owner. The owner is responsible for access, instructions, data use, monitoring, and incident response.

### 9. Coding assistants

Coding assistants may be used only in approved development environments and repositories.

Developers must not:

* Paste secrets or credentials into prompts.
* Use unapproved MCP servers, plugins, hooks, or skills.
* Allow agents to run commands outside approved sandbox and approval settings.
* Accept generated code without review.
* Add dependencies suggested by AI without normal dependency review.

Generated code must follow the same review, testing, licensing, and security requirements as human-written code.

### 10. AI-generated output

Employees are responsible for reviewing AI-generated output before relying on it or sharing it.

Review is required for:

* Customer-facing content.
* Legal, HR, finance, security, or compliance work.
* Code, configuration, scripts, and infrastructure changes.
* Summaries of contracts, policies, or regulated records.
* Decisions that affect customers, employees, applicants, students, patients, borrowers, insureds, or other individuals.

AI output must not be treated as authoritative unless the workflow includes approved validation.

### 11. Prohibited uses

Employees must not use AI tools to:

* Bypass access controls, monitoring, DLP, or security policy.
* Create malware, credential theft, evasion, or exploitation content outside an authorized security-testing or research process.
* Make employment, lending, housing, insurance, healthcare, education, legal, or other consequential decisions without approved governance.
* Impersonate another person without authorization.
* Create deceptive synthetic media for company work.
* Upload data the company is not allowed to share with the tool.
* Process regulated data in an unapproved system.
* Connect AI tools to personal accounts for company work.

### 12. Incidents and reporting

Employees must report AI-related incidents promptly through the security reporting channel.

Report if:

* Sensitive data was entered into an unapproved AI tool.
* An AI tool exposed, retained, or sent data unexpectedly.
* An agent took an action the user did not intend.
* A connector, plugin, MCP server, or extension behaved unexpectedly.
* A prompt injection or suspicious instruction affected the AI workflow.
* Credentials, code, customer data, or regulated data may have been exposed.
* A user finds an unapproved AI tool used for company work.

Do not delete evidence unless security instructs you to do so.

### 13. Exceptions

Exceptions require approval from the business owner, security, and any required legal, privacy, or compliance reviewer.

Each exception must include:

* The approved tool and use case.
* The data class.
* The users or groups.
* The reason for the exception.
* Compensating controls.
* Expiration date.
* Owner.

### 14. Enforcement

Violations may result in tool access removal, incident review, disciplinary action, contract remedies, or other action allowed by company policy and law.

## Implementation controls

The policy should be paired with:

* SSO and SCIM for approved AI platforms.
* Tenant restrictions or domain controls where available.
* RBAC for sensitive AI features.
* DLP and secrets detection.
* Connector and extension allowlists.
* Sandbox, approval, and egress controls for agents.
* Compliance exports and SIEM routing.
* A living AI inventory.
* Role-based AI literacy and use-case training.
* Quarterly review.

## Common AI acceptable use policy security failures

* The policy bans risky behavior that the organization cannot detect or enforce.
* The policy names tools but not data classes.
* The policy covers chat but not agents, coding tools, mobile apps, browser control, or connectors.
* Exceptions never expire.
* Employees are told to "be careful" without examples.
* Legal approves the policy, but identity, DLP, and logging controls are not deployed.

## Frequently asked questions about AI acceptable use policy

### Should the policy list every approved AI tool?

The policy should point to a maintained catalog rather than hard-code every tool. Tool lists change too often for a static policy.

### Should employees be allowed to use personal AI accounts for work?

The default should be no. Personal accounts weaken identity, retention, DLP, audit, and legal control. If a business unit needs an exception, document the data class, user group, duration, and compensating controls.

### Who approves new AI tools?

At minimum: the business owner, security, privacy or legal where data or affected-person risk exists, procurement for vendor terms, and platform or IT for deployment and support.

### How often should the policy be reviewed?

Review quarterly during active rollout and after major vendor feature changes, incidents, new regulation, or new AI deployment models.

## Applicable handbook articles

These links are limited to controls that the policy template expressly requires or uses to enforce its account, integration, agent, data, monitoring, and incident rules.

| Handbook area                            | Applicable articles                                                                                                                                                                                                                                                                                                                                                     | Why they apply                                                                           |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| 1. Identity & access                     | <p>1.1 SSO & SCIM for AI platforms<br>1.2 RBAC across AI platforms<br>1.3 Tenant restrictions: blocking personal accounts<br>1.4 Domain claiming: bringing shadow accounts into enterprise<br>1.5 Agent and non-human identity<br>1.6 API keys and service accounts governance<br>1.7 Human-in-the-loop and approval policies</p>                                       | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |
| 2. Connectors, extensions & supply chain | <p>2.1 Connectors and apps: the integration backbone<br>2.2 MCP servers: securing the protocol<br>2.3 MCP gateways and allowlisting<br>2.4 Analyzing skills for risk<br>2.5 Plugins and marketplaces<br>2.6 Hooks and lifecycle scripts<br>2.7 The supply-chain review workflow<br>2.9 SaaS agent-building supply-chain<br>2.10 Hosted-agent framework dependencies</p> | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |
| 3. Runtime, sandboxing & autonomy        | <p>3.1 Sandbox and isolation models<br>3.2 Approval policies and least-privilege autonomy<br>3.3 Network egress control<br>3.4 Internet access and browser automation<br>3.5 Computer Use / desktop control risks<br>3.6 Scheduled and background tasks<br>3.8 File and filesystem access controls<br>3.9 Central hosted-agent runtime hardening</p>                    | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |
| 4. Data protection                       | <p>4.1 DLP for GenAI<br>4.2 Data classification for AI prompts and outputs<br>4.4 Retention and Zero Data Retention<br>4.6 Cross-app data flow and live artifacts<br>4.7 Secrets and credential hygiene in prompts and tools</p>                                                                                                                                        | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |
| 5. Threats & adversarial testing         | <p>5.1 Prompt injection: the connective risk<br>5.2 Data exfiltration via tools and connectors<br>5.3 Supply chain attacks and notable CVEs<br>5.4 Agent-specific threats: tool poisoning and confused deputy<br>5.6 Incident response for AI systems</p>                                                                                                               | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |
| 6. Observability, audit & evidence       | <p>6.1 The audit gap: what you can and can't see<br>6.3 Compliance APIs by platform<br>6.5 Routing AI telemetry to your SIEM<br>6.6 Evidence by surface and investigation paths<br>6.7 Continuous review cadence</p>                                                                                                                                                    | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |
| 7. Rollout & operations                  | <p>7.3 The security team checklist<br>7.4 The vendor-neutral control matrix</p>                                                                                                                                                                                                                                                                                         | Turns acceptable-use requirements in this domain into enforceable controls and evidence. |

## Further reading

The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page.

* [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
* [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework)
* [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng), including Article 4 on AI literacy and deployer obligations in Article 26
* [Colorado SB26-189](https://leg.colorado.gov/bills/SB26-189). The law's ADMT definition excludes specified natural-language tools when they are not intended for consequential decisions and an acceptable use policy prohibits generated content from being used in such decisions.

## Related handbook guidance

* [Governance & Frameworks](/reference/governance-and-frameworks.md)
* [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts.md)
* [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone.md)
* [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs.md)
* [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.