The Data Layer Behind Every AI Security Gap

AI security best practices are the technical, procedural and governance controls organizations use to protect AI models, the infrastructure that runs them and the data they touch, at each stage from training through deployment. They cover three layers most security programs treat separately: the model layer (training data integrity, supply chain risk, adversarial inputs), the infrastructure layer (access controls, identity, audit trails) and the interaction layer (every prompt, upload, connector and AI-generated output that creates a new path for sensitive data to move).

Most security programs run controls on one of these layers while the other two stay largely unmanaged. This checklist covers all three, organized into eight practice areas, with one thread running through each: the highest-leverage AI security investments start with data, not the 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.

The distinction that matters most in scoping this work is between generative AI security and agentic AI security. Generative AI security governs what data flows into and out of AI tools through user interaction, prompts, uploads, outputs, and is largely manageable with classification, DLP and shadow AI discovery. Agentic AI security is a harder problem: agents that take actions rather than generate text operate with persistent access, chain tool calls and can act on a prompt injection they never identify as malicious. Both matter. This checklist addresses both, and calls out where the controls diverge.

The urgency is not theoretical. IBM's newly released 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, a 12% year-over-year increase and a record high. AI-driven attacks rose 56% over the prior year. Organizations using AI and automation extensively in security operations saved an average of $1.93 million per breach compared to those using none.

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 introduce a risk profile broad enough to warrant their own dedicated treatment. Scoping agent permissions, brokering credentials instead of issuing them outright, gating high-consequence actions behind human approval and treating multi-agent communication as its own trust boundary each deserve more depth than a checklist entry allows. Refer to my agentic AI security best practices post for a more detailed overview on the topic. 

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 through vendor APIs, SaaS platforms and embedded copilots, with no say over how those models were trained or how they behave under adversarial input. What they do control is their own data: where it lives, how it's classified and who or what can reach it. That's the one variable in this entire equation an organization actually owns end to end, which is why it has to be the starting point, not an afterthought bolted on after the AI rollout.

The case for this isn't theoretical. IBM and Ponemon Institute research on AI-related breaches found that 97% of organizations that experienced an AI-related security incident lacked proper AI access controls at the time of the breach. Not sophisticated model attacks. Not novel exploits. Access controls that were never scoped in the first place, on data that an AI system should never have been able to reach.

That statistic maps directly onto every domain in this checklist. A prompt injection that reaches only properly classified, access-scoped data does limited damage, because the attacker inherits whatever restrictions already applied to that data before the model ever touched it. A compromised third-party model matters far less if it was never granted broad access to unclassified repositories. An overpermissioned agent is a materially bigger problem than the same agent operating against a well-governed data environment. The vulnerability doesn't disappear when data is governed first. Its blast radius does.

This is where Forcepoint DSPM and Forcepoint DLP do different, complementary work. DSPM answers the question upstream: what sensitive data exists, where does it live and who or what is overexposed to it, before an AI tool or agent ever connects. DLP answers it downstream: once a prompt, upload or AI-generated output tries to move that data, does it match a policy that says it shouldn't. Running both against a shared classification layer, rather than treating each as a standalone tool, is what closes the gap the IBM research points to. Access controls fail most often not because the control logic was wrong, but because nobody had classified the data closely enough to write the right rule for it.

The organizations that get furthest with AI security aren't the ones bolting point solutions onto every new risk category as it appears, prompt injection tools here, agent monitoring there, a shadow AI scanner somewhere else. They're the ones that classified their data first, scoped access second and let policy enforcement extend outward from that foundation, whether the AI system in question is a sanctioned platform like Microsoft 365 Copilot or a tool nobody in IT has reviewed yet. Every practice in this checklist gets easier to operationalize once that sequence is right, and considerably harder to sustain if it isn't.

Frequently Asked Questions

What are the most important AI security best practices?

The highest-leverage practices are the ones that reduce blast radius rather than address a single attack type: classifying data before it enters an AI pipeline, applying least privilege to every AI integration, and building an AI tool inventory before writing policy. Organizations that get these three right make every other control on this list more effective.

What is the difference between generative AI security and agentic AI security?

Generative AI security governs data moving into and out of AI tools through prompts, uploads and outputs. Agentic AI security governs autonomous systems that take real-world actions, such as sending messages, modifying files or calling APIs, which creates consequences beyond a single interaction.

Which framework should my organization use for AI security governance?

The NIST AI RMF is the most widely adopted baseline for U.S. organizations and is framework-agnostic enough to adapt across industries. ISO/IEC 42001 serves the same function for organizations that need an internationally recognized management system standard. Most mature programs align to NIST or ISO at the governance level and layer OWASP's LLM Top 10 on top for application-specific risks.

How does shadow AI affect AI security best practices?

Shadow AI, meaning AI tools employees use without IT evaluation or approval, is one of the largest sources of ungoverned data exposure. Best practice is to build a usage inventory before writing policy, since approved tool lists reflect intent rather than actual usage.

Do AI security best practices differ by industry?

The core practices, data classification, least privilege, continuous monitoring, apply across industries. What changes is regulatory context. Healthcare and financial services carry additional compliance obligations under HIPAA, GDPR or sector-specific rules that shape how AI data governance gets documented and audited.