AI Security Best Practices: A Practitioner's Checklist

AI security best practices cover a wider surface than most organizations plan for when they start. There is the model layer: training data integrity, supply chain risk, API security and adversarial inputs. There is the infrastructure layer: access controls, identity, least privilege and audit trails. And there is the interaction layer: every prompt, upload, connector and AI-generated output that creates a new path for sensitive data to move.

Most security programs are running controls on one of these layers while the other two are largely unmanaged. This checklist covers all three, with a consistent thread running through each section: the highest-leverage AI security investments start with your data, not your model. Organizations that know what data their AI systems can reach, and control it, reduce blast radius across every other risk category on this list.

Why the AI Attack Surface Is Different

Traditional security threats are relatively predictable. They target networks, code and infrastructure. Defenders can respond by patching, hardening and closing known vectors.

AI systems introduce a different kind of attack surface because they learn and adapt. A model can be manipulated through its inputs, not just its infrastructure. Training data can be poisoned before a model is deployed. An agent with overly broad permissions can expose data that was never intended to surface. And because AI compresses data movement into a single interface, a single ungoverned interaction can reach more sensitive data faster than almost any traditional exfiltration method.

The other dimension that makes AI security harder is speed. Shadow AI adoption consistently outpaces governance. Employees are using tools that IT has not evaluated, on devices that may not be managed, against data that is not classified. The controls organizations built for endpoints, SaaS and email were not designed for this environment.

Training Data and Model Integrity

Security risks in AI systems often originate before a model is ever deployed. The data used to train or fine-tune a model determines what that model knows, how it behaves and what it might reproduce. Most organizations do not treat training data with the same classification and access rigor they apply to production systems, which is where the exposure starts.

Best Practices for Training Data Security

• Classify training data before fine-tuning begins. If sensitive data enters a training pipeline unclassified, the model becomes a retrieval mechanism for information it was never intended to surface. Scope training data to the minimum necessary for the use case.
• Establish data provenance. Track every dataset used in training: its source, handling history and any transformations applied. Tamper-evident logging creates the audit trail that compliance and incident response both require.
• Scan for poisoning before training runs. Adversarial examples injected into training data can teach a model bad behaviors that only surface later under specific conditions. Validate dataset integrity before each training cycle, not just at initial ingestion.
• Restrict access to model artifacts. Trained model weights are sensitive intellectual property. Apply the same access controls to model artifacts — including checkpoints and fine-tuned variants — that you apply to production source code.

Supply Chain and Third-Party Model Risk

Organizations rarely build AI systems from scratch. They pull models from public hubs, use third-party libraries, integrate plugins and consume AI capabilities through APIs. Each of those dependencies introduces risk at the infrastructure layer that is difficult to detect without deliberate controls.

Best Practices for AI Supply Chain Security

• Verify model provenance before deployment. Public model hubs offer limited guarantees about what a model has been trained on or whether it has been tampered with. Prefer models from verified publishers and validate checksums where available.
• Treat AI plugins and extensions as privileged integrations. Browser extensions and AI-native plugins often request broad permissions. Evaluate them with the same rigor you apply to third-party SaaS tools, not as convenience features.
• Monitor AI library dependencies continuously. A compromised dependency in your AI stack can affect model behavior in ways that are hard to detect without runtime monitoring. Include AI libraries in your software composition analysis workflow.
• Map your AI bill of materials. Know every model, library, API and plugin your AI systems depend on. You cannot respond to a supply chain incident involving components you cannot name.

Access Controls and Identity at the AI Layer

Access control failures are the most common mechanism behind real-world AI data exposure incidents. The pattern is consistent: a model or agent inherits permissions that are broader than the task requires, retrieves content the user was not entitled to see and returns it in an output that looks like a normal response. This is not a model failure. It is an access control failure expressed through an AI interface.

Best Practices for AI Access Control

• Apply least privilege to every AI integration. AI assistants and agents should not inherit the full access scope of the user or service account they operate under. Scope permissions to the minimum required for the specific workflow.
• Enforce retrieval boundaries in RAG pipelines. Retrieval-augmented generation systems should return only content the requesting user is authorized to access, not everything in the connected knowledge base. Authorization checks need to happen at retrieval time, not just at the application layer.
• Require human approval for irreversible agent actions. Agents that can send messages, modify files, change permissions or trigger external workflows need deterministic gates on high-consequence actions. Autonomous execution without human approval is a blast radius problem.
• Log connector scope and retrieval activity. Treat AI connector activity as first-class audit evidence. What did the agent retrieve? From where? On whose behalf? That trail is what incident response needs when something goes wrong.

Shadow AI and Ungoverned Tool Adoption

Shadow AI is rarely malicious. It is a productivity response to friction. Employees find tools that help them work faster and use them, regardless of whether IT has evaluated or approved them. The risk is not intent — it is that ungoverned usage creates data exposure paths that existing controls were never built to reach.

The objective is not to lock everything down. It is to make the approved path easier than the risky one, then enforce at the boundary for everything else. A practical starting point for building that visibility layer is covered in more depth in the AI security tools post, which walks through the SWG and CASB capabilities that make shadow AI discovery operationally feasible.

Best Practices for Shadow AI Control

• Build an AI tool inventory before writing policy. Map actual usage across web traffic, endpoint activity and SaaS environments. Approved tool lists reflect intent, not reality. Start with what is actually running.
• Create allowlists with tenant specificity. "ChatGPT is approved" is not a control. Specify the approved enterprise tenant, approved clients and approved integrations. Consumer accounts and enterprise accounts are different risk surfaces.
• Block and redirect, not just block. If you block an AI tool without offering an approved alternative, users route around the control. Use granular access controls that steer users to sanctioned tools rather than simply denying access.
• Centralize enforcement through inspectable control points. Route AI access through control points where you can apply consistent policy, generate audit logs and measure outcomes. Distributed enforcement produces uneven coverage.

Prompt, Upload and Output Controls

Most real-world AI data leakage happens at the moment users share context with a model. A user pastes a contract for summarization. An employee uploads a spreadsheet to get formatting help. A developer drops API credentials into a prompt to debug an integration. These are not sophisticated attacks — they are normal productivity behaviors that create data exposure events when the wrong tool or tenant is involved.

Effective AI security best practices treat prompts, uploads and outputs as policy-enforced data egress paths, not training topics.

Best Practices for Prompt and Data Egress Controls

• Apply inline prompt inspection. Detect sensitive content before a prompt is submitted, then block, coach or require justification based on policy. Keyword blocking is brittle — classification-driven policy scales because it answers "what data is this" before deciding whether it is allowed here.
• Enforce upload controls at the interaction layer. Prevent sensitive files from being uploaded to AI tools unless the tool, tenant and use case are explicitly approved. The same classification logic that governs email and endpoint egress should extend to AI file upload paths.
• Apply policy to AI-generated output. Outputs that aggregate, summarize or reformat sensitive data can be just as risky as the inputs. Apply policy to AI-generated content before it is downloaded, pasted into other systems or shared externally.
• Define data tiers that map to enforceable actions. At minimum: what is never allowed in any GenAI tool (credentials, regulated identifiers, unreleased financials, source code); what is allowed only in approved enterprise tools; and what is generally permissible with logging. Policy without tiers produces inconsistent enforcement.
• Maintain consistency across channels. Apply the same control logic across web, endpoint and SaaS so users cannot bypass guardrails by switching devices or applications. Inconsistency in enforcement is the gap that gets exploited.

Prompt Injection Containment

Prompt injection is not a problem you can train users out of. It is a design problem that requires containment controls. The safest operating assumption is that untrusted content will eventually influence an AI system's behavior — whether through a user's own prompt, a document the model retrieves or a web page an agent processes.

Indirect prompt injection is particularly dangerous because malicious instructions are embedded in retrieved content that the model processes automatically. The user never sees the instruction. The model acts on it anyway.

Best Practices for Prompt Injection Defense

• Treat untrusted content as potentially adversarial. Any content the model retrieves from external sources — documents, web pages, emails, database records — should be handled as potentially hostile input. Design system prompts and retrieval pipelines to minimize how much retrieved content can influence model instructions.
• Separate instruction context from data context. Where possible, distinguish between what the model is instructed to do and what it is processing as data. Architectural separation reduces the surface area for injection.
• Align your review checklist to the OWASP Top 10 for LLM Applications. The OWASP framework provides a structured taxonomy of LLM-specific risks, including prompt injection, insecure output handling and training data poisoning. Map each risk to a specific control before deploying a new AI system or workflow.
• Test for injection in pre-deployment security reviews. Prompt injection resistance should be part of your standard AI application security testing, not an afterthought. Red-team AI systems specifically for injection scenarios before they reach production.

Agentic AI and Autonomous Workflow Risk

Agentic AI systems — tools that can take actions, not just generate text — create a qualitatively different risk profile from standard generative AI. An agent that can send messages, query databases, modify files or trigger external API calls has real-world consequences for any action it takes, including actions triggered by a prompt injection attack it never identified as malicious.

Organizations running insider risk programs are increasingly extending that framework to cover AI agent behavior, because the risk profile is similar: an entity with privileged access that may take actions outside its intended scope.

Best Practices for Agentic AI Security

• Scope agent permissions to the minimum viable access for each task. Agents should not carry persistent broad access across sessions. Scope permissions to the specific workflow, then expire them.
• Gate high-consequence actions behind human approval. Define irreversible or high-impact actions — external sharing, permission changes, payments, record deletion — and require explicit human approval before execution.
• Monitor agent behavior continuously, not just at deployment. Agents can behave differently as the context they receive changes. Continuous monitoring of agent actions, data access and output is required to catch drift before it becomes an incident.
• Treat multi-agent architectures as a trust boundary problem. When agents can invoke other agents, trust does not automatically transfer. Each agent-to-agent communication is a potential injection or privilege escalation vector. Apply authentication and scope controls between agents, not just at the perimeter.

Governance Frameworks and Continuous Monitoring

Governance is what keeps AI security from degrading as adoption accelerates. Static policy does not hold in environments where new tools, new agents and new data connections are added faster than security teams can manually review them. The organizations that manage this well treat AI security as a continuous program, not a one-time deployment checklist.

Frameworks Worth Aligning To

For U.S. organizations, the NIST AI Risk Management Framework (AI RMF 1.0) is the standard reference. It organizes AI risk governance around four functions: Govern, Map, Measure and Manage. It is framework-agnostic and designed to be adapted across industries and AI maturity levels. ISO/IEC 42001:2023 serves a similar function internationally as the standard for AI management systems. Organizations with EU exposure also need to account for EU AI Act obligations, which introduce tiered requirements for high-risk AI systems. Google's Secure AI Framework (SAIF) is a useful implementation reference at the design level. For application-layer risks specifically, the OWASP Top 10 for LLM Applications is the most operationally useful starting point.

Best Practices for Ongoing Governance

• Review your AI tool inventory quarterly. Adoption moves faster than annual reviews can track. A quarterly cadence catches shadow AI, newly approved tools and expanded integrations before they create unmanaged exposure.
• Extend DLP policy to AI channels without rebuilding from scratch. The classification taxonomy and policy logic organizations have already built for endpoints, email and SaaS should extend to AI interaction layers. DLP for AI works when the same classifiers govern traditional channels and AI tool interactions from a shared policy platform.
• Run continuous data exposure discovery. The biggest driver of AI risk in most environments is not a novel exploit — it is accumulated exposure drift. New SaaS connections, new sharing patterns and new AI connectors create blind spots faster than point-in-time assessments can find them. Data security posture management closes that gap by making exposure discovery continuous rather than periodic.
• Assign ownership across security, data and product teams. AI governance fails when responsibility is split without clear ownership at each layer. Define who owns model security, who owns data policy for AI and who owns the AI tool approval workflow — then hold each accountable to a specific set of controls.

The Data-First Argument for AI Security

Most organizations deploying AI do not control the models they use. They consume them. That means the highest-leverage security investments are not at the model layer — they are at the data layer.

If sensitive data is properly classified, access is scoped to least privilege and policy is enforced at the point where AI systems interact with data in motion, the blast radius of every other failure on this list gets smaller. A prompt injection that can't reach sensitive data does limited damage. An agent with overpermissioned access to unclassified data is a far bigger problem than an agent with scoped access to a well-governed data environment.

That is the thread connecting every section of this checklist. Build visibility into what data your AI systems can reach. Classify it. Control access. Enforce policy consistently across every channel where AI operates. The AI security hub post covers the broader threat landscape and how these controls fit into a full program if you want more context before diving into implementation.

Put These Practices into Action

Knowing the checklist is the easy part. The harder part is enforcing it consistently across the tools, tenants, devices and data environments your organization is already running. Forcepoint's approach to safely enabling AI starts with data visibility and builds toward adaptive policy enforcement across every channel where AI operates — without requiring organizations to rebuild what they already have.