AI introduces security risks that traditional enterprise security frameworks were not designed to address. A model trained on your proprietary data can be made to reveal that data through adversarial prompting. A model that drives a critical business decision can be manipulated through data poisoning that was introduced months before the attack manifests. A third-party AI service that handles sensitive customer information may have data processing terms that create regulatory exposure your legal team has never reviewed.

Most enterprise security teams are alert to AI as a tool used by attackers. Far fewer are managing the security of AI as an asset being attacked. This guide covers both dimensions: how to secure your AI assets and how to govern the use of AI in your security operations.

73%
Of enterprises using generative AI tools have not completed a formal data processing review of those tools' terms of service, according to our 2025 enterprise survey. Most are unaware that their inputs may be used for model training by default on standard subscription tiers.

The AI-Specific Threat Landscape

AI security threats span two categories: attacks on AI systems (your AI assets being targeted) and attacks using AI (adversaries using AI to attack your infrastructure). This guide focuses primarily on the former — the category that most enterprise security programs have not yet addressed.

Attack Type
Prompt Injection
Malicious instructions embedded in content that an LLM processes, causing the model to execute attacker-controlled actions rather than follow system instructions. Particularly dangerous in agentic AI deployments with tool access.
Impact: Data exfiltration, unauthorized actions, system compromise via AI agent
Attack Type
Data Poisoning
Deliberate introduction of adversarial examples into training data to cause models to make specific errors, exhibit biased behavior, or create backdoors that activate under attacker-controlled conditions.
Impact: Compromised model behavior, biased outputs, persistent backdoors that survive retraining
Attack Type
Model Extraction
Systematic querying of an AI model to reconstruct its behavior, effectively stealing the model's intellectual property through its API. Proprietary models built on large training investments are at risk.
Impact: IP theft, competitive intelligence, creates a replica model for adversarial use
Attack Type
Adversarial Inputs
Carefully crafted inputs designed to cause models to produce incorrect outputs — misclassifying images, generating incorrect decisions, or bypassing content filters — while appearing normal to human observers.
Impact: Classification errors, bypassed safety controls, fraudulent decisions passing automated checks
Attack Type
Training Data Exfiltration
Extraction of sensitive information that was memorized by a model during training — including PII, proprietary data, or confidential documents included in training corpora.
Impact: PII exposure, regulatory violations, confidential data disclosure
Attack Type
Supply Chain AI Attacks
Compromise of third-party AI models, datasets, or tools that your organization uses. A malicious model published on an open-source repository and adopted without security review creates a persistent backdoor.
Impact: Persistent compromise via trusted third-party models and datasets

The Five-Layer AI Security Control Framework

Securing enterprise AI requires controls across five layers that map to the AI lifecycle. Controls applied only at the model layer while ignoring the data, infrastructure, and deployment layers leave significant exposure. The OWASP Top 10 for LLM Applications provides a useful starting taxonomy, but enterprise AI security requires a more comprehensive framework that covers the full lifecycle.

Layer 1
Data
Training Data Security and Provenance
Controls governing what data enters training pipelines, who can introduce new training data, how training data is validated for integrity, and how provenance is tracked. Data poisoning attacks begin at this layer. Organizations without controlled training data ingestion have no defense against supply chain data attacks. Implement cryptographic signing of training datasets, access controls on data labeling pipelines, and anomaly detection for training data distributions.
Layer 2
Model
Model Integrity and Access Controls
Controls governing model storage, access, versioning, and integrity verification. Model artifacts should be stored with integrity checksums that detect unauthorized modification. Access to model weights should be role-controlled with the same rigor as production database access. Model registries should maintain a complete audit trail of who accessed, modified, or deployed each model version. Third-party models should undergo security review before production deployment.
Layer 3
Inference
Input Validation and Output Filtering
Controls applied at the model inference boundary. Input validation detects and blocks known adversarial patterns, prompt injection attempts, and anomalous input distributions. Output filtering screens model responses for sensitive data exposure, policy violations, and unexpected behavior patterns. For LLM applications, implement a dedicated prompt injection detection layer — do not rely solely on system prompt instructions, which can be overridden by sufficiently crafted adversarial inputs.
Layer 4
Application
Agentic AI and Tool Use Security
Controls specifically for AI systems with action capabilities — models that can browse the web, execute code, write to databases, send emails, or take other real-world actions. Agentic AI dramatically expands the attack surface: a successful prompt injection against an agent with email access can exfiltrate data or send phishing messages at scale. Apply minimal privilege principles: agents should have access only to the specific tools and data required for their defined task, not to general organizational systems.
Layer 5
Operations
Monitoring, Detection, and Response
Continuous monitoring of model behavior for adversarial patterns, distribution shift, and anomalous output rates. AI security incidents require specialized playbooks distinct from traditional security incident response — a model producing systematically biased outputs is an AI security incident that requires model investigation, not network forensics. Establish baseline behavioral metrics for production models and alert on statistically significant deviations.

Third-Party AI Risk Management

The third-party AI risk problem is larger than most security teams recognize. The average enterprise now uses AI tools embedded in dozens of SaaS applications, often without explicit procurement approval or security review. Employees adopt AI-powered browser extensions, writing assistants, and productivity tools that process sensitive corporate information under consumer-grade data handling terms.

"We completed a shadow AI audit for a Fortune 500 financial services client and found 47 distinct AI tools in active use across the organization, of which only 6 had been through any form of security or legal review. Several were processing client financial data under terms that created regulatory exposure."

The third-party AI risk assessment process should cover four dimensions. Data processing terms must be reviewed by legal and security together: where is the data processed, who can access it, is it used for model training, and what are the data retention and deletion terms? Security architecture should be reviewed for how the tool authenticates, what data it accesses, and whether it stores conversation history. Regulatory alignment must confirm the tool's data handling is compatible with GDPR, CCPA, HIPAA, or other applicable regulations. Business continuity requires assessment of what happens if the vendor experiences an outage, raises prices significantly, or is acquired.

47
Distinct AI tools found in active use at a Fortune 500 financial services organization during a shadow AI audit. Only 6 had completed security and legal review. This pattern is consistent across the enterprises we advise: AI tool proliferation is running far ahead of governance processes.
Download the AI Security Red Team Guide
Our comprehensive guide for testing enterprise AI systems against the OWASP LLM Top 10, adversarial input attacks, and prompt injection vulnerabilities. Designed for security teams conducting internal AI security assessments.
Access the Guide

Addressing Shadow AI in the Enterprise

Shadow AI — the use of AI tools outside of sanctioned organizational processes — is the fastest-growing security risk category for enterprises. The risk vectors are data exposure (employees pasting sensitive content into consumer AI tools), compliance violations (regulated data processed in non-compliant environments), and intellectual property risk (proprietary code, strategies, or client data submitted to tools with training-use terms).

The response to shadow AI should not be outright prohibition. Prohibition without substitution increases rather than decreases risk, as employees find more creative ways to access AI tools while hiding that usage. The effective response is to provide well-governed AI tools that meet employee productivity needs, combined with policy clarity on what data categories may not be submitted to AI tools, and technical controls that monitor and alert on high-risk data exposure events.

The Shadow AI Control Stack

Technical controls should operate at the network, endpoint, and data layer simultaneously. Network-layer controls can block access to unauthorized AI services from corporate networks and devices. Data loss prevention tooling, when updated to recognize AI service upload patterns, can alert on or block sensitive data submission. Browser extensions and endpoint agents can provide employees with real-time guidance on data sensitivity before submission. These controls are most effective when combined with a clear organizational AI policy and training that helps employees understand both the risks and the approved alternatives.

AI Security Governance Structure

AI security is not solely a CISO problem. The intersections with legal (data processing terms, regulatory compliance), risk management (model risk governance), and business units (operational decisions driven by AI) require a cross-functional governance structure.

Effective AI security governance has three components. First, an AI security policy that addresses training data handling, model storage and access, inference environment security, third-party AI procurement requirements, and employee AI use guidelines. Second, a review process for new AI tools and models that includes security, legal, and risk management — with clear criteria for approval, conditional approval with remediation requirements, and rejection. Third, an AI security incident response playbook that addresses the specific nature of AI security incidents: model compromise, data exfiltration via AI, and adversarial manipulation of AI decisions.

The AI Governance framework we have documented elsewhere covers the broader governance structure. The security layer sits within that framework as a specialized domain requiring dedicated attention from both the AI team and the security organization.

AI Security Implementation Checklist

Complete a shadow AI audit: Identify all AI tools currently in use across the organization, regardless of approval status. Network traffic analysis and employee surveys together provide the most complete picture.
Review data processing terms for all AI tools: Every AI tool that processes company or customer data should have its terms reviewed by legal and security jointly before continued use.
Implement prompt injection controls for LLM applications: Any LLM application that processes external content (emails, documents, user inputs) requires dedicated input validation and output filtering.
Establish model registry with access controls: All production AI models should be stored in a secured registry with role-based access controls, integrity verification, and a complete audit trail of access and modifications.
Apply minimal privilege to agentic AI systems: AI agents with tool access should be scoped to the minimum access required for their specific function. Audit agent tool access permissions quarterly.
Implement AI-specific monitoring: Production models should have behavioral monitoring that detects adversarial input patterns, output anomalies, and distribution shift. This is distinct from infrastructure monitoring.
Train employees on AI data handling: Every employee using AI tools needs to understand which data categories can and cannot be submitted to AI tools, and why. Policy without training is not a control.
Develop AI incident response playbooks: AI security incidents require different investigation and remediation approaches than network security incidents. Develop playbooks before an incident, not during.
Resource
AI Security Red Team Assessment Guide
Our structured guide for conducting internal AI security red team assessments against the OWASP LLM Top 10. Covers prompt injection testing, adversarial input evaluation, and third-party model security review.
Access Tools and Resources

EU AI Act Security Requirements

The EU AI Act creates specific security obligations for organizations deploying high-risk AI systems in the EU market. High-risk AI in the Act's definition covers credit scoring, hiring decisions, educational assessment, law enforcement applications, and several other categories. Organizations in these categories must implement cybersecurity measures appropriate to the risk, maintain logging sufficient to detect and investigate security incidents, and demonstrate security during conformity assessment.

The Act does not specify technical controls in detail, instead requiring that security measures be proportionate to the risk and consistent with the state of the art. This gives organizations flexibility but requires documented rationale for the security architecture choices made. Organizations subject to the Act should conduct a formal security assessment as part of their conformity assessment process, not as an afterthought.

Building AI Security Capability

AI security is a maturing discipline. The frameworks, tools, and expertise that existed for traditional cybersecurity took decades to develop. AI security is compressing that timeline, but gaps remain. Most organizations need to build AI security capability from a base of traditional security expertise combined with AI technical literacy.

The most important first step for most organizations is the shadow AI audit and third-party tool review. These address the most immediate and pervasive risks with relatively modest effort. The model security controls and adversarial testing programs are important but require more specialized capability that takes time to build.

Our AI Governance practice includes AI security assessment as a component of our governance framework engagements. Our free assessment can identify your organization's most significant AI security gaps and prioritize remediation based on the specific AI tools and applications in your environment.