AI Security Guidelines for Employees: An Acceptable‑Use Policy You Can Enforce

Introduction

An effective AI acceptable-use policy (AUP) should answer a few fundamental questions:

• Which AI tools can employees use?
• What information can and cannot be shared with those tools?
• Which use cases are approved, restricted, or prohibited?
• How should employees validate AI-generated outputs before acting on them?
• What controls exist to detect and prevent policy violations?

The questions above are only as useful as the controls behind them.

What should an AI acceptable-use policy include?

A strong AI acceptable-use policy establishes clear expectations for employees while giving security teams a foundation for enforcement. Effective guardrails scale across different tools, teams, and use cases: broad enough to cover the full AI surface and specific enough to enforce.

Scope: What tools and environments are covered?

One of the most common policy gaps is failing to clearly define what qualifies as an AI tool. Many organizations focus on public chatbots while overlooking AI functionality embedded throughout their technology stack.

An AI AUP should cover:

• Public GenAI applications and chatbots
• Embedded AI assistants in productivity and collaboration platforms
• Developer AI tools and coding assistants
• AI-powered browser extensions and plugins
• Internal AI applications and models
• Autonomous agents and workflow automations connected to enterprise systems

Rather than categorizing tools based solely on vendor or application type, consider the level of access each tool has to enterprise data. A chatbot with access to customer records may present greater risk than a public AI tool used for generic brainstorming.

Roles and responsibilities

AI governance cannot be owned exclusively by security teams, and policies that treat it that way tend to fail at the operational level. Employees need clear guidance on what is acceptable, managers need to know when to escalate, and legal and compliance stakeholders need to be looped in early enough to shape policy. Data owners in HR, Finance, and Engineering understand the sensitivity of their information better than any central team does.

The reason to define this ownership explicitly is not organizational tidiness. When an exception request comes in, or a violation occurs, or a new AI tool appears in traffic that nobody approved, the response depends on knowing exactly who decides, who investigates, and who updates the policy. Ambiguity at that moment is where governance programs stall.

Core policy sections

While every organization’s policy will differ, most enforceable AI AUPs include several foundational components.

• Approved and unapproved tools: Employees should know which AI tools are authorized for business use and how to request approval for new technologies. Ambiguity often leads to shadow AI adoption and inconsistent risk management.
• Prompting and content handling requirements: Define expectations for prompts, uploads, generated outputs, and file sharing. Employees should understand how to handle both information sent to AI systems and content received from them.
• Identity and access requirements: Establish requirements for single sign-on (SSO), multifactor authentication (MFA), managed devices, approved accounts, and other controls designed to reduce unauthorized access risks.
• Logging and audit requirements: Document what activity must be logged, how long records should be retained, and what information may be required for investigations, audits, or compliance reporting.
• Enforcement and escalation procedures: Define how policy violations will be handled, including escalation paths, remediation expectations, and disciplinary considerations when appropriate.
• Training and acknowledgment: Employees should receive regular training on AI risks, acceptable use expectations, and evolving policy requirements. Annual acknowledgments help reinforce accountability and demonstrate governance maturity.

What data must not be shared with AI tools

Most AI security incidents start with an employee pasting internal information into an AI tool without considering how that data may be processed, retained, or reused on the other side.

The categories below follow a red-yellow-green framework. Red data should never enter a public or unsanctioned AI system under any circumstances. Yellow data requires safeguards before use. Green data carries low enough risk that most organizations permit it under standard policy.

Red list: Data that should never be shared with public or unsanctioned AI tools

Certain categories of information create an unacceptable level of risk when shared with unapproved AI services. These data types should be explicitly prohibited unless a documented exception exists and appropriate controls are in place.

Examples include:

• Credentials and secrets
• Regulated and protected information
• Employee information
• Customer information
• Legal and business-sensitive information
• Security information
• Intellectual property and source code

Yellow list: Data that may be used with safeguards

Not all internal information requires a complete prohibition. Some content may be appropriate for AI-assisted workflows when safeguards reduce the likelihood of exposing sensitive information.

Examples include:

• Internal documents that have been appropriately redacted
• Non-sensitive project summaries
• De-identified examples used for writing, analysis, or training purposes
• Approved development use cases operating within sanctioned environments

Before sharing any internal information with an AI system, evaluate whether it is necessary for the task and whether adequate protections exist.

Green list: Generally safe for standard AI use

Low-risk activities using approved tools and public or non-sensitive information can typically proceed under standard policy without additional review.

Examples include:

• Brainstorming and ideation using publicly available information
• Drafting generic content that does not require confidential inputs
• Summarizing non-sensitive documents, meeting notes, or research materials
• Translation of non-sensitive content using approved tools

Minimum de-identification requirements

Many employees assume removing a name is enough to anonymize information. In practice, de-identification requires a more deliberate approach.

Before sharing information with an approved AI system, employees should:

• Replace names, account numbers, and other direct identifiers with placeholders
• Remove unnecessary customer, employee, or business-specific details
• Eliminate unique contract terms, locations, or references that could reveal identity
• Use representative excerpts instead of full reports, spreadsheets, or database exports

It’s important to recognize that de-identification reduces risk, and it does not guarantee anonymity. Security teams should establish clear standards for when de-identified information is acceptable and when additional controls are required.

Approved tools and safe usage patterns

An AI policy should do more than tell employees what they cannot do. It should also define approved ways to use AI safely and productively. Providing clear guidance helps reduce shadow AI adoption, encourages consistent behavior, and enables employees to benefit from AI without introducing unnecessary risk.

Approved tools policy

Employees should use approved corporate AI tools whenever possible. Approved tools have typically undergone security, legal, compliance, and procurement reviews. They may also include contractual protections, data-handling commitments, logging capabilities, and other safeguards that are not available with consumer-grade services.

Organizations should establish a documented process for requesting new AI tools. Without a clear approval process, employees often resort to unauthorized solutions when existing tools do not meet their needs.

Policies should also prohibit the use of personal AI accounts for work-related activities unless explicitly approved. Personal accounts can create visibility, retention, and governance challenges that make enforcement difficult.

Safe usage patterns

Not every AI interaction carries the same level of risk. Organizations can often approve low-risk activities while restricting more sensitive use cases.

Examples of generally acceptable activities include:

• Brainstorming with public information: Employees can use AI to generate ideas, explore concepts, create outlines, or support planning activities that rely solely on public information.
• Drafting generic content: AI can help create first drafts of emails, presentations, documentation, or communications that do not require confidential inputs.
• Summarizing non-sensitive information: Employees may use approved AI tools to condense lengthy reports, meeting notes, or research materials that do not contain protected information.
• Translation assistance: Approved AI tools can support translation of non-sensitive content when business needs require multilingual communication.
• Development assistance in approved environments: Developers may use approved coding assistants to accelerate tasks such as debugging, documentation, testing, and code generation, provided they follow established policies governing source code and intellectual property.

The key principle is simple: The lower the data sensitivity, the lower the associated risk.

Prompt hygiene rules

Prompt hygiene is one of the most effective ways to reduce AI-related data exposure. Even when employees use approved tools, poor prompting practices can increase organizational risk. Employees should follow several core guidelines:

• Do not include sensitive information unless the use case has been approved.
• Replace identifiers with placeholders whenever practical.
• Share only the information necessary to complete the task.
• Avoid uploading raw files unless policy permits the activity.
• Review prompts before submission to ensure unnecessary information has been removed.

Small changes in prompting behavior can significantly reduce the likelihood of exposing sensitive data while still allowing employees to benefit from AI-assisted workflows.

How to validate AI outputs

Organizations often focus on what employees enter into AI systems while paying less attention to what comes out. That gap creates its own category of risk. For example, inaccuracies, unsupported claims, insecure code, compliance issues, and biased recommendations can all surface in responses that appear entirely credible. Employees who act on AI outputs without verification are making decisions on unaudited information.

Output validation checklist

Before relying on AI-generated content, employees should verify:

• Accuracy: Confirm factual claims, statistics, technical recommendations, and references against authoritative sources.
• Confidentiality: Ensure outputs do not expose customer data, proprietary information, or other protected content.
• Compliance: Review content for legal, regulatory, or policy concerns, especially in regulated industries and customer-facing communications.
• Security: Evaluate code, scripts, configurations, and technical recommendations for vulnerabilities, unsafe practices, or malicious content. AI-generated code should never be considered production-ready without review.
• Bias and fairness: Check for discriminatory language, unfair assumptions, or recommendations that could create ethical, legal or reputational risks.

High-risk scenarios requiring human review

Some use cases should always require human oversight, including:

• Legal agreements and policy language
• HR decisions and performance-related communications
• Financial reporting, forecasting, and pricing decisions
• Customer communications in regulated industries
• Security guidance, scripts, configurations, and remediation recommendations
• Medical or health-related content

In these cases, AI may assist with drafting or analysis, but humans should make the final decisions.

Citation and traceability requirements

Organizations should establish expectations for documenting AI-assisted work and retaining records when required for audits, investigations, or compliance purposes.

Depending on the use case, employees may need to:

• Retain supporting sources and citations
• Document prompts and outputs used in regulated processes
• Follow disclosure requirements for AI-assisted content
• Preserve records needed for audits, investigations, or legal review

Maintaining traceability improves accountability and makes it easier to validate decisions and investigate issues when they arise.

How to enforce and audit AI acceptable-use policy

Creating an AI acceptable-use policy is only the first step. To be effective, organizations must enforce it consistently across users, applications, and data while maintaining visibility into AI activity and risk.

• Translate policy into enforcement controls: Convert policy statements into specific technical and administrative actions based on risk. Clearly define what is allowed, warned, restricted, isolated, or blocked, while also documenting exception workflows and assigning ownership for updates, approvals, enforcement decisions, and long-term governance accountability.
• Monitor AI usage and policy violations: Build monitoring that shows not only which AI tools employees use, but whether those tools are approved, what data is being shared, and which violations happen most often. Pair violation data with sanctioned adoption trends so teams can identify gaps in tooling, training, or policy clarity.
• Respond to AI-related incidents: Handle AI incidents through existing security, privacy, and data protection processes to ensure consistency and speed. Investigate what was shared, which service was involved, the potential exposure and compliance impact, and what immediate steps are needed to contain further unauthorized use.
• Maintain audit readiness: Keep clear, accessible records that demonstrate AI governance is active and enforceable in practice. This includes approved application inventories, policy histories, training completion, exception approvals, activity logs, enforcement actions, and evidence of regular reviews to support internal oversight and external regulatory inquiries.
• Continuously improve policy effectiveness: Treat AI governance as an ongoing program that adapts to changing technologies, business needs, and regulatory expectations. Regularly review new use cases, violation patterns, employee feedback, and emerging requirements so policies and controls stay useful, relevant, and aligned with real-world adoption.

How Zscaler maps policy to controls

Policy documents create accountability, and technical controls make that accountability real. Most AI governance programs break down at exactly that transition, when the underlying platform was not built to inspect AI traffic, classify prompt content, or apply context-aware decisions at the session layer.

Aligning policy requirements with enforcement

Effective enforcement depends on context. Security teams need visibility into who is using AI services, what data is involved, and whether activity aligns with policy. Controls can then be applied based on identity, application risk, data sensitivity, and business requirements. Common enforcement objectives include:

• Verifying user identity and context
• Applying risk-based policies
• Monitoring AI activity
• Protecting sensitive data
• Supporting investigations and audits

Example capability areas

Organizations often look for capabilities that support both AI adoption and governance. Zscaler addresses each layer of the enforcement challenge through four capability areas: 

1. AI Asset Management: Gives security teams visibility into the full AI footprint: approved applications, shadow AI, embedded AI in Software-as-a-Service (SaaS) platforms, developer tooling, and autonomous agents. You cannot enforce a policy against tools you cannot see.
2. AI Access Security: Applies zero trust access controls to AI SaaS, embedded AI in enterprise platforms, and developer environments, with inline inspection of prompts, responses, and file uploads. Allow, warn, restrict, and block decisions are applied based on user identity, device posture, and data sensitivity — at the session layer, not just the URL.
3. AI Red Teaming: Continuously tests internally built AI applications against real adversarial conditions: prompt injection, jailbreaks, context poisoning, and data leakage. It identifies exploitable weaknesses before they reach production.
4. AI Guardrails: Translates red teaming findings directly into runtime protection policies, closing the loop between testing and enforcement. Detectors run continuously against production AI interactions, covering jailbreak attempts, prompt injection, and sensitive data leakage.

The Zero Trust Exchange™

Every capability above runs on the Zscaler Zero Trust Exchange™ platform, which applies zero trust principles to AI interactions by continuously verifying identity, evaluating context, and enforcing policy at the session layer. Organizations get a unified enforcement layer across the full AI lifecycle, from shadow AI discovery through runtime protection, without adding point solutions that create new visibility gaps.

To see how Zscaler maps these controls to your environment, visit zscaler.com/ai-security.