AI Security Controls Explained: What They Are, How They Work, and How to Evaluate AI Security Platforms

Stop pretending AI security is some mystical puzzle. It’s the simple act of slamming the door before a model does something stupid. Governance writes the rules, monitoring watches the fire, and compliance saves the receipts. Security stands in the room when the bad prompt hits.

Shoving every buzzword into a single "risk" bucket is a recipe for failure. Teams wonder why things still break despite the expensive dashboards. Real security lives at the runtime level where actions actually happen. Prioritize execution over paperwork.

AI improvises and hallucinates far more than static software. Standard firewalls are about as useful as a screen door on a submarine in this environment. You need controls that manage behavior under pressure. Prompt injections and data leaks don't wait for a quarterly audit.

Governance handles the policy while monitoring handles the alerts. Compliance deals with the reporting later. Security handles enforcement at the exact moment of execution. Documenting damage is a poor substitute for preventing it.

Imagine a user dumping customer secrets into a public LLM. Governance said don't do it, and monitoring caught it five minutes too late. Compliance has the log of the failure for the regulators. Security should have killed the connection before the model ever read the first sentence.

Buyers keep ignoring the exact spot where the damage happens. They’re busy shopping for platforms that solve problems that aren't the real risk. Throwing good money into a hole is easy when you can't stop the leak at the source. Stop the bleeding.

This updated version of the article incorporates three material changes from the April version. Agentic endpoint security has been added to Layer 04 as a formally recognized control category following Palo Alto's April 2026 Koi acquisition, which was the first time a major enterprise security platform defined autonomous AI agents as a distinct endpoint class requiring dedicated controls. AI Bill of Materials has been added to Layer 06 as a supply chain control that the Shai-Hulud attack in May 2026 demonstrated was missing from most organizations' pipeline security programs. And the MAESTRO threat modeling framework from the Cloud Security Alliance has been integrated into Layer 03, where it belongs, rather than treated as a standalone addendum at the end of the article.

From HiddenLayer's 2026 AI Threat Landscape Report: One in eight reported AI security breaches now involves agentic systems. 73 percent of organizations report internal conflict over who owns AI security controls. 31 percent cannot determine whether they experienced an AI breach in the past twelve months. Survey of 250 IT and security leaders, published March 18, 2026.

Why AI Security Controls Exist

Traditional enterprise security was built around a relatively stable assumption: software does what its code says it will do, and protecting the system means controlling access to that code and the data it touches. Firewalls, antivirus, and intrusion detection systems were designed for an environment where behavior was predictable and deviations from expected behavior were the signal to investigate.

AI systems broke that assumption. A language model does not follow a fixed code path — its output depends on the specific combination of model weights, system prompt, conversation context, and user input at the moment of inference. A prompt that produces a safe response on Monday may produce a policy-violating response on Tuesday if the surrounding context has changed. This is not a bug in the model; it is how these systems work. The security implication is that controlling the code is no longer sufficient. You have to control the behavior, and behavior monitoring requires different instrumentation than code analysis.

The input layer is now the primary attack surface. Prompt injection — the technique of embedding instructions in user input that override a model's system prompt or behavior constraints — moved from a theoretical concern to an operational reality that enterprise security teams encounter regularly. Unlike SQL injection or cross-site scripting, prompt injection exploits the model's core capability: it is designed to be helpful and follow instructions, so it complies with instructions embedded in inputs even when those instructions come from an attacker rather than the system designer.

Autonomous agents introduced a second category of risk that conventional security frameworks were not built for. An agent with write access to a CRM system, an email client, and an external API can take consequential actions faster than any human can review them. When an agent is compromised or behaves unexpectedly, the damage accumulates across multiple systems simultaneously, and the action log required to reconstruct what happened often does not exist because the organization was not tracking agent behavior at the granularity needed for investigation.

Enforcement Layers (03, 04, 05)

These three layers stop attacks at the moment they occur. Layer 03 blocks threats before they reach the model. Layer 04 controls what models and agents can execute in real time. Layer 05 sanitizes what enters and leaves the model at the interaction boundary. A control in these layers that only observes and alerts without blocking is not performing the security function the layer exists for.

Support Layers (01, 02, 06, 07)

These four layers create the conditions under which enforcement is possible. Layer 01 establishes what exists. Layer 02 defines who can access what. Layer 06 ensures the foundation the model was built on is secure. Layer 07 produces the evidence that compliance teams, legal counsel, and regulators require. None of these layers stop an attack directly, but enforcement controls without them are operating without the information they need to function correctly.

The NIST Cyber AI Profile, published as preliminary draft NIST IR 8596 in December 2025, organizes AI security considerations across three focus areas that map onto this structure: "Secure" addresses cybersecurity challenges in integrating AI systems (Support Layers), "Defend" covers using security tooling to protect AI systems (Enforcement Layers), and "Thwart" addresses resilience against AI-enabled attacks. The seven layers below align to that structure. The profile is still in draft form, but it represents the first NIST-level acknowledgment that AI security requires a different framework than the existing cybersecurity guidance was designed to provide.

AI Security Control Frameworks

Stop treating security controls like a boring checklist and start looking at the actual choke points. Seven distinct layers emerge when you look at where the AI lifecycle actually breaks down in production. Platforms usually sell you a slice of this stack, so you better know where your biggest exposure lives before you sign a check.

Getting the alignment right means the tool actually does its job. Messing this up means you're just paying for a high-definition dashboard that watches your data disappear.

Asset and Discovery Controls –– You cannot secure what you cannot see.

Every other control layer in this article depends on knowing what AI systems are running in your environment. Identity controls need a list of what they are protecting. Threat defenses need to know what model surfaces are exposed. Audit systems need a registry of what they are logging. Asset and discovery controls are the foundation that makes all of that possible, and in most organizations they are also the layer with the largest gap between what teams believe they have and what is actually running.

The discovery problem in AI is more severe than in conventional software because the barrier to deploying an AI system is now a browser extension and a credit card. A marketing team member can integrate an AI writing tool with access to internal documents in an afternoon, and that integration will not appear in any IT-approved software inventory, will not have gone through a security review, and will be generating outbound traffic that looks indistinguishable from normal web browsing. Tenable's Cloud and AI Security Risk Report 2026 found that 70 percent of AI workloads are externally exposed in ways the organization's security team did not know about at the time of assessment.

AI Security Posture Management is the continuous practice that makes discovery operational over time rather than a point-in-time exercise. The core principle is that discovery has to run continuously, not quarterly, because the rate at which new AI tools appear in enterprise environments outpaces any scheduled audit cycle. ARMO's March 2026 AI-SPM guide and Wiz's May 2026 analysis both describe it as a practice combining vulnerability scanning, configuration management, and risk scoring specifically tuned for AI workloads — separate from general cloud security posture management because AI systems have distinct exposure patterns that general cloud scanning does not surface.

Shadow AI Detection

Scanning of browsers, endpoints, network traffic, and cloud tenants for AI tools and model integrations that employees are using outside the formal IT procurement and approval process. Shadow AI detection works by monitoring outbound connections to known AI API endpoints, examining browser extension installations on managed devices, and analyzing authentication patterns that indicate AI service usage. When it identifies shadow AI activity, it attributes it to specific users or devices and flags the connection for review.

The practical scope of this problem tends to surprise organizations when they run a first scan. LayerX's browser-level security work, before Akamai acquired them in May 2026, documented that enterprise employees were regularly pasting material from internal documents into external AI tools without any awareness that this constituted a data exposure. The tool works as intended, the output is useful, and nobody in the interaction realizes that the internal content has now been processed by an external model provider's infrastructure.

AI Inventory and Registry

A continuously updated, searchable record of every AI system operating in the environment, whether sanctioned by IT or discovered through shadow AI scanning. The registry captures model identity, version, ownership, access scope, deployment date, usage volume, and the business function the system serves. It is the document an organization needs to answer "what AI systems do we have and who is responsible for each one?" in a form that does not require a week of manual research to produce.

The financial services context makes this particularly concrete. SR 26-2, which replaced SR 11-7 in April 2026, requires banking organizations to maintain model inventories with documentation covering intended use, known limitations, and ownership. Organizations that had been treating AI inventory as a project for later found that SR 26-2 examination cycles were already underway with that requirement active. An AI registry that can produce that documentation on demand is the difference between a clean examination and a supervisory finding.

Data Provenance Tracking

Logging of where data entered an AI system, how it moved through the pipeline, and what transformations it underwent. Provenance tracking creates a map from any output back to its source material, which is the record needed when a model produces a problematic output and the investigation requires identifying where the problem originated. In retrieval-augmented generation systems, provenance tracking also surfaces when a specific document or data source is driving a disproportionate share of the model's outputs, which can indicate either a data quality issue or a manipulation of the retrieval index.

Identity and Access Controls –– Every model and agent needs permissions, and those permissions need limits.

Identity and access management for AI systems follows the same principle as identity and access management for human users — least privilege, with access granted only to the specific resources a system needs to perform its defined function — but the implementation is more complex because AI systems can be assigned permissions by multiple teams, their effective access scope can grow implicitly as they are connected to new tools, and the human who approved their initial permissions may have left the organization long before anyone reviews whether those permissions still make sense.

The agent identity problem makes this layer more urgent than it was eighteen months ago. An autonomous agent that has been granted write access to a CRM system, an email platform, and an internal database is a privileged user in the identity management sense, and it needs to be treated as one: with a unique identity, documented permissions, regular access review, and rotation of the credentials it uses to authenticate to external systems. Most organizations do not yet have identity governance programs that explicitly cover non-human AI agent identities, which is why HiddenLayer found 73 percent of organizations reporting internal conflict over who owns AI security controls.

Model and API Access Control

Enforcement of role-based access rules governing which users, service accounts, and systems can call specific model endpoints or AI APIs. This control ensures that model access is tied to documented roles and reviewed regularly rather than granted broadly by default. The default configuration of most AI API integrations is permissive — any authenticated service account in the organization can call the endpoint — and moving from that default to documented, role-scoped access requires explicit configuration work that most teams defer until after an incident prompts the review.

Agent Permissions and Least Privilege

Hard limits on what autonomous agents can read, write, query, or trigger across connected systems, with session scopes that prevent agents from accessing resources outside their defined task boundaries. The principle here is the same as for human users: access should be scoped to what the agent needs to complete its specific function, and that scope should be reviewed when the agent's function changes. An HR agent that needed read access to a benefits database when it was deployed may have accumulated additional access over time as developers added capabilities, and without a formal permission review cycle those accumulations go unnoticed.

The blast radius concept is what makes this control worth implementing carefully. An agent with broad permissions that behaves unexpectedly — whether because of a prompt injection attack, a goal drift issue, or a software defect — can affect every system within its access scope simultaneously. Narrow permissions limit the scope of damage that a single agent failure can produce.

Third-Party and Vendor Access Control

A structured process for evaluating, approving, and monitoring the access that external AI vendors and tools have to organizational data. Every AI integration with a third-party provider represents an access relationship that carries data exposure risk if the provider's security practices are inadequate, if the vendor's terms allow them to use customer data for model training, or if the integration is not revoked when the vendor relationship ends. Third-party access controls route those integrations through a proxy or gateway that can inspect, restrict, and revoke access, and that strips sensitive information from outbound requests before they reach external endpoints.

Non-Human Identity Credential Management New

Tracking and governance of the API keys, service account tokens, and credentials that AI agents use to authenticate to external systems — including rotation schedules, scope audits, and detection of anomalous credential usage. This control applies identity security principles to the non-human actors that AI deployments create. Agent credentials that are never rotated, that have broader scope than the agent's documented function requires, or that show authentication patterns inconsistent with the agent's normal operation represent a persistent security exposure that conventional identity programs were not designed to surface.

Vendors including Opal Security and Defakto built their product lines specifically around this control category. The Q1 2026 funding rounds in this space — Opal at $23 million for AI agent identity governance and Defakto at $30.75 million for machine identity governance — reflect institutional recognition that agent identity management is a distinct requirement that general identity management programs do not cover..

Threat and Vulnerability Controls –– Blocking attacks before they reach the model and finding vulnerabilities before attackers do.

Threat and vulnerability controls operate at two points in time. Before deployment, they test the model's resilience against known attack patterns through adversarial simulation. During runtime, they sit between incoming requests and the model and block those that match known threat signatures or anomalous patterns. Both functions are necessary because pre-deployment testing finds the vulnerabilities that exist when the model ships, and continuous runtime defense catches new attack patterns that emerge after deployment.

Enforcement Layer

The controls in this layer are enforcement controls. A prompt injection defense that flags suspected attacks and sends an alert is performing a monitoring function. A prompt injection defense that blocks the request before the model processes it is performing a security function. The distinction matters because alerts require a human to act on them within a time window, and at inference speeds that window is often too short to prevent damage. The evaluation question for every control in this layer is whether it blocks or alerts — and which of those behaviors applies in your deployment.

Prompt Injection Defense

Detection and blocking of input content that contains instructions designed to override a model's system prompt, redirect its behavior, or extract information it was instructed not to reveal. Prompt injection is the AI equivalent of SQL injection: it exploits the system's intended functionality — in this case, its responsiveness to natural language instructions — to make it do something the system designer did not intend. Attacks arrive through customer-facing interfaces, through documents that agents retrieve and process, and through data fields in connected systems that agents read as part of their normal workflow.

Lakera, which Check Point acquired in September 2025 for approximately $300 million, built its detection capability on a dataset of over 80 million real adversarial prompt examples accumulated through the Gandalf public research project. That training dataset is what made Lakera's detection depth unusual — most security tools build threat detection libraries from known-bad signatures, but Lakera's exposure to the actual distribution of real attack patterns produced detection capability that was harder to bypass with novel variations. The acquisition price reflected the value of that dataset as much as the product itself.

Data Leakage Prevention

Inspection of model outputs for sensitive data patterns before they are delivered to users, with redaction or blocking of responses that contain material the model should not be revealing. Data leakage in AI systems happens through several mechanisms: the model may reproduce training data that included sensitive information, it may aggregate context from a retrieval system in ways that reveal information the user should not have access to, or it may be induced through carefully crafted inputs to reveal system prompt contents or other internal information. Output-side DLP sits between the model's response and the user and catches those exposures before they complete.

Adversarial Testing

Continuous simulation of attack scenarios against production AI systems to find vulnerabilities before attackers do. This is distinct from pre-deployment red-teaming in that it runs against live systems on an ongoing basis rather than only during the security review before launch. Models and their surrounding systems change after deployment — new prompt templates, new data sources, new tool integrations — and each of those changes can introduce vulnerabilities that were not present when the original testing was done. Continuous adversarial testing catches those regressions within days rather than waiting for an external report or an incident.

OffSec introduced the AI-300 Advanced AI Red Teaming course and the OSAI 24-hour AI red team challenge in June 2026, which reflects the maturation of AI red teaming as a distinct professional discipline. The Tenable Cloud and AI Security Risk Report 2026 found that most AI workloads are externally exposed in ways that conventional penetration testing would not surface because conventional testing was not designed to probe AI-specific attack surfaces.

MAESTRO Threat Modeling Integration New

The Cloud Security Alliance published the MAESTRO framework — Multi-Agent Environment, Security, Threat, Risk, and Outcome — in February 2025, with a real-world application guide for agentic AI systems published in February 2026. MAESTRO defines seven threat modeling layers for agentic architectures: the large language model layer, the agent layer, the agent orchestration layer, the agent-tool interaction layer, the agent storage layer, the agent runtime layer, and the agent communication and query layer. Each layer has distinct threat categories, and the framework provides a structured process for analyzing where a given agentic deployment is most exposed.

The practical value of MAESTRO for enterprise security teams is that it provides a common vocabulary for discussing agentic threat surfaces across the security, engineering, and compliance functions. Before MAESTRO, organizations applying threat modeling to agentic systems were doing so without a shared framework, which produced inconsistent assessments that were difficult to compare or audit. Integrating MAESTRO into the threat and vulnerability control layer means using it to structure the adversarial testing program — which threats in each MAESTRO layer are being tested, at what frequency, and with what results.

Runtime and Execution Controls –– Stopping what should not execute before it does.

Runtime controls are the highest-priority enforcement layer for most enterprise environments in 2026, and they are the layer where the gap between what organizations have and what they need is widest. The demand signal is visible in Palo Alto's Q3 FY2026 results: the company handled roughly 1,200 customer meeting requests in the twelve weeks before June 2, 2026 — the same volume it had handled across all of 2025 — and grew its Prisma AIRS customer base from around 100 to over 300 in a single quarter. That growth rate reflects organizations recognizing that runtime enforcement, not policy documentation, is what stops damage at machine speed.

The agentic shift is what made runtime controls the urgent priority. When a human operator makes a decision, there is a natural latency between the decision and the action — time to type a request, time to review a response, time to take the next step. Autonomous agents eliminate that latency. An agent that has been compromised or that has received a manipulated input can read data, execute queries, call APIs, and generate outputs in seconds, across multiple systems simultaneously. Post-event forensics tells you what happened. Runtime controls stop it before it completes.

Real-Time Enforcement

A control that monitors the inference process and interrupts execution when the model's reasoning or output matches a defined risk pattern. Real-time enforcement lives inside the inference loop — between the model's processing and its output delivery — rather than sitting upstream as a filter or downstream as an alert system. That placement is what allows it to stop a damaging output before it reaches the user or the downstream system rather than notifying someone about it after the fact.

Palo Alto's CEO Nikesh Arora described the capability framing on the company's Q3 FY2026 earnings call: frontier AI models can now identify and act on vulnerabilities in minutes when used by attackers, a process that previously took months of manual work. The symmetry of that capability — the same speed that makes AI useful to legitimate users makes it dangerous when misused — is what drives the demand for enforcement that operates at inference speed rather than human review speed.

Agent Restriction and Action Bounding

Runtime enforcement of hard limits on what actions autonomous agents can take, implemented as policy rules that evaluate each action request before the agent executes it. Action bounding is the runtime complement to the permission scope controls in Layer 02. Where Layer 02 defines what an agent is authorized to do at the configuration level, action bounding enforces those limits in real time during task execution, blocking actions that exceed scope even when the agent's configuration theoretically permits them. The control adds a runtime verification step that catches cases where the agent's behavior has drifted from its intended scope in ways that the configuration did not anticipate.

Output Gating and Human-in-the-Loop Verification

A checkpoint that holds consequential outputs or actions in a review state until a secondary automated check or a human reviewer approves them for delivery or execution. Output gating introduces deliberate latency into high-stakes AI workflows as a control rather than a bottleneck. A procurement agent generating a large purchase order, a financial system triggering a wire transfer, or a communications platform sending an external message on behalf of an organization — all of these are cases where the cost of a wrong output significantly exceeds the cost of the seconds added by a verification step. Output gating creates that verification step as a structural feature of the workflow rather than depending on individual users to think of it.

Agentic Endpoint Security New

Security controls designed specifically for autonomous AI agents as a distinct endpoint class, covering agent process isolation, inter-agent communication security, and behavioral anomaly detection at the agent level. Palo Alto formally defined Agentic Endpoint Security as a product category in the press release announcing the completion of its Koi acquisition on April 14, 2026. That naming matters because it represents a major enterprise security platform's determination that AI agents require dedicated endpoint security architecture rather than an extension of existing endpoint protection approaches built for human-operated devices.

The specific problems that agentic endpoint security addresses are different from those addressed by general endpoint protection. An agent process can spawn sub-agents, communicate with other agents, maintain state across multiple sessions, and execute actions that span multiple connected systems. The threat surface is the agent's behavior across its entire operational scope, not just the code running on a specific device. Protecting that requires instrumentation at the agent process level — monitoring what the agent is doing across all its connections, not just what is happening on the machine running it.

LLM Interaction Controls –– Sanitizing what enters and leaves the model at the conversation boundary.

LLM interaction controls operate at the specific point where a human or system sends input to a model and receives output in return. They are enforcement controls because they can block or modify content before it reaches the model or before the model's response reaches the user. This layer differs from Layer 03 in scope: Layer 03 deals with attacks and vulnerabilities against the model system, while Layer 05 deals with the routine sanitization and policy enforcement that every input and output should go through regardless of whether an active attack is present.

Prompt Security, which SentinelOne acquired in August 2025 for approximately $250 million, built its product primarily around this layer — specifically around generative AI runtime security at the interaction point, including prompt injection defense, sensitive data detection in outputs, and policy filtering at the LLM API boundary. The acquisition brought that interaction-layer capability into SentinelOne's broader platform, which reflects the enterprise security market's conclusion that interaction controls need to be part of the same security infrastructure as endpoint protection rather than a separate tool.

Input Validation and Sanitization

Processing of every prompt and context window before it reaches the model, including detection of injected instructions, removal of potentially dangerous encoding patterns, and flagging of inputs that contain sensitive data the model should not be processing. Input validation is the first line of defense in this layer and also the place where policy enforcement can happen most cleanly — blocking or modifying an input before the model processes it is simpler and more reliable than trying to correct or redact a model's output after the fact.

Context Isolation

Enforcement of session boundaries that prevent conversation history or retrieved context from one user's session from appearing in another user's session. Context isolation addresses a specific failure mode in LLM deployments where shared context or retrieval systems allow one user to access information that was introduced into the system by a different user. In a shared customer service deployment, a conversation that mentions a specific customer's account details should not be retrievable by a subsequent user asking about their own account, and context isolation ensures that it is not.

Prompt Filtering

Policy-based evaluation of instructions before the model sees them, with blocking of topics, requests, or instruction patterns that fall outside the system's defined use scope. Prompt filtering is distinct from prompt injection defense in that it enforces scope policy rather than attack detection — it blocks requests for content the system is not designed to provide, regardless of whether those requests represent a security attack. The two controls work together: injection defense blocks malicious instructions, and prompt filtering blocks off-scope legitimate requests.

Output Content Scanning

Inspection of model responses before they are delivered to identify sensitive data patterns, policy-violating content, or information that should not be revealed in the context of the current user's access level. Output scanning catches exposures that input-side controls did not prevent — cases where the model produced sensitive content in response to a prompt that appeared legitimate. This includes scanning for personally identifiable information, proprietary data patterns, system prompt contents that the model has been induced to reveal, and content that violates the organization's acceptable use policies for AI-generated material.

Model and Pipeline Security Controls –– Securing the foundation before a model reaches production.

Model and pipeline security controls address threats that exist before a model is deployed — threats to the integrity of the training data, the model weights, the build pipeline, and the software packages the AI system depends on. These controls operate at build time rather than runtime, which means they are the layer most likely to be treated as a one-time checklist rather than a continuous practice. The Shai-Hulud supply chain attack in May 2026 demonstrated why that approach fails.

The Shai-Hulud attack, May 2026: In late April and early May 2026, a threat actor designated TeamPCP executed two coordinated attack waves against the AI software supply chain. The first wave, running from April 29 to May 12, compromised 172 packages across 404 malicious versions in ecosystems including Mistral AI's official SDKs, TanStack, Guardrails AI, and UiPath. The TanStack compromise was assigned CVE-2026-45321 with a CVSS score of 9.6. The attack vector was the CI/CD pipeline: the attacker published malicious package versions with valid provenance attestations, meaning every standard supply chain check passed. Organizations that had robust supply chain security in place detected the attack through behavioral monitoring — continuous verification that installed packages operated within expected bounds rather than reliance on provenance records that the attacker had learned to forge.

AI Bill of Materials New

A structured inventory of every component in an AI system — base models, fine-tuned weights, training datasets, software dependencies, and third-party integrations — with version information, origin documentation, and integrity hashes. The AI Bill of Materials concept extends the software bill of materials idea to AI-specific components that conventional SBOM tools do not capture. Cycode published a comprehensive AIBOM guide in February 2026, and HiddenLayer introduced AIBOM and Model Genealogy capabilities in their AISec Platform 2.0 as a direct response to supply chain attack patterns like Shai-Hulud.

The practical value of an AIBOM in an incident is that it answers the first question investigators need to answer: which version of which component was running at the time of the event? Without a current AIBOM, establishing that requires manual archaeology across build logs, dependency manifests, and deployment records that may be incomplete or inconsistent. With an AIBOM that is updated on every build and deployment, the answer is available immediately.

Model Supply Chain Security

Vetting of base models, pre-trained weights, and datasets before they enter the build environment, including hash verification against known-good sources, scanning for known backdoor patterns, and documentation of origin. AI supply chain attacks can occur at any point where external components enter the build — when a base model is downloaded from a public registry, when a dataset is imported from an external source, or when a dependency package is installed during the build process. The Shai-Hulud attack targeted the dependency layer and exploited the trust that CI/CD systems extend to packages with valid provenance attestations. Supply chain security at the model and dataset layers requires the same skeptical verification that the attack revealed was missing at the package layer.

Artifact Scanning

Inspection of containers, model files, and deployment artifacts for malware, unauthorized modifications, or embedded code that should not be present before promotion to production. ARMO's April 2026 work on AI supply chain vulnerability scanning found that standard container scanning tools missed AI-specific vulnerabilities in machine learning frameworks because those tools were not designed to inspect model weight files or ML-specific package structures. Artifact scanning for AI deployments requires tooling that understands those structures.

Training Pipeline Security

Access controls, immutable audit logs, and anomaly detection applied to the model training process to prevent unauthorized modification of training data or training configuration. Training pipeline attacks aim to bias a model's behavior in specific, pre-planned ways that will not be visible during normal quality evaluation — the model performs normally on all standard benchmarks but behaves differently when triggered by a specific input pattern. Securing the pipeline prevents those modifications from being introduced, and maintaining immutable logs of the training process provides the evidence needed to investigate whether a modification occurred.

Version Integrity Verification

Continuous verification that the model and configuration files running in production exactly match the versions that were reviewed, signed, and approved during the deployment process. Version integrity checks catch cases where a model file has been modified after signing, where a deployment included the wrong model version, or where a partial deployment has left different versions running across different inference nodes. The control is simple in concept and expensive to be without when an incident investigation requires establishing exactly what was running and when.

Audit and Evidence Controls ––The records that answer questions after something has gone wrong.

Audit and evidence controls produce the documentation that compliance teams, legal counsel, regulators, and incident responders need to understand what an AI system did, when it did it, and whether it was operating within defined boundaries. These controls do not stop incidents from occurring. Their function is to ensure that when an incident occurs, or when a regulator asks, the evidence needed to answer specific questions about specific events exists in a form that can be produced and examined.

The Workday AI hiring lawsuit established the stakes for this layer in concrete terms. Workday had monitoring infrastructure that documented 1.1 billion AI-assisted hiring decisions. What it could not answer, in a form that satisfied legal examination, was who owned accountability for each decision domain, what the documented oversight obligation was, and what specific decisions were made on specific dates for specific candidates. The monitoring data documented the scope of the activity. The audit and evidence layer is what would have allowed the organization to answer the specific accountability questions the litigation asked. Those are different capabilities requiring different instrumentation, and most enterprise AI programs have the first without the second.

Tamper-Proof Logging

Capture of every prompt, response, decision, and system event in append-only storage with cryptographic integrity protection and full timestamps. Tamper-proof logging is the prerequisite for every other control in this layer because without an immutable record of what happened, every other audit capability is limited to reconstructing history from incomplete evidence. The specific requirements for tamper-proof logs vary by regulatory framework — SR 26-2 has documentation requirements for financial services AI, EU AI Act Article 12 has record-keeping requirements for high-risk systems — but the common element across all of them is that the record must be complete, accurate, and demonstrably unmodified since it was created.

Evidence Generation and Packaging

Structured outputs that transform raw logs and system records into documentation packages formatted to answer specific regulatory or legal inquiry formats. Raw logs are not evidence packages. A log file that contains hundreds of thousands of model inference records satisfies the requirement to have captured data. A structured evidence package that extracts the specific time period, the specific decision categories, and the specific oversight records that an EU AI Act conformity assessor or an SR 26-2 examiner needs to answer their questions is what makes that log file useful in a regulatory context. Evidence packaging is the work that turns operational data into auditable documentation, and organizations that build it into their monitoring programs before an examination begins are in a significantly different position than those that build it under examination pressure.

Risk Scoring and Triage

Assignment of a numerical risk score to each session or interaction based on the controls it triggered, the content it processed, and the actions it attempted, used to prioritize investigation of the highest-risk events rather than requiring review of every alert. AI security programs generate high volumes of signal data, and the alert fatigue problem that affects conventional security operations is present here in more acute form because AI systems process high volumes of interactions that each produce multiple signals. Risk scoring applies prioritization logic to that signal volume so security operations teams can direct their attention to the interactions most likely to represent genuine threats or policy violations rather than treating every alert equally.

Framework Mapping

Automated tagging of logged events against specific regulatory and standards frameworks — SOC 2, ISO 42001, EU AI Act, SR 26-2, NIST AI RMF — so that compliance reports reflect current system behavior rather than requiring manual mapping during audit periods. Framework mapping is the control that makes continuous compliance possible rather than point-in-time. When every logged event is automatically mapped to the relevant framework requirements at the time of logging, producing a compliance report becomes a query against existing records rather than a reconstruction project. The frameworks that map to this control most directly — SOC 2 Type 2, EU AI Act Article 12, SR 26-2 model documentation requirements — all require evidence that controls operated over a period of time, not just that they existed at a moment in time.

How to Evaluate AI Security Platforms Using Controls

Stop asking which AI security tool is "best." It’s a junk question. Best for who? Best for what model? You might as well ask which car is best without knowing if you're hauling gravel or racing in the Indy 500. The only question that moves the needle is which controls your specific environment needs right now and which vendor actually has the depth to enforce them.

Most teams skip the threat model because they think it’s a homework assignment that gets in the way of the "real work." They’re wrong. Skipping the model is how you end up blowing six figures on a platform that solves a problem you don't even have, while your actual front door stays unlocked. Pick three scenarios that would actually get you fired if they happened tomorrow and work backward from there.

Matching Threat Scenarios to Control Layers

• Concern: Prompt injection on a customer chatbot. Prioritize LLM Interaction Controls and Threat Controls. You need input validation and prompt filtering sitting directly in the attack path. If it isn't blocking the prompt in real-time, it isn't security.

• Concern: Shadow AI and "rogue" tools. Focus on Asset & Discovery Controls. You can't govern a ghost. If you don't have a live inventory and detection for what your devs are spinning up on their lunch breaks, you're flying blind.

• Concern: Agents with access to live systems. Go heavy on Runtime & Execution and Identity & Access Controls. These agents move at machine speed and don't wait for human approval. They need hard, programmable limits before they start "hallucinating" your budget into a black hole.

• Concern: Data leaking through outputs. Prioritize Threat Controls (DLP) and Interaction Controls (context isolation). These are the bouncers that catch the sensitive files before they leave the building. Catch the leak at the faucet, not the drain.

• Concern: Audit pressure and regulators. Focus on Audit & Evidence Controls. A control you can't prove actually ran is useless when an auditor is breathing down your neck. You need logs and evidence generation that don't require a PhD to interpret.

• Concern: Supply chain and build integrity. Look at Model & Pipeline Security Controls. Most enterprise teams haven't even sniffed this layer yet. They're too busy with firewalls to notice the foundation of their AI house is built on poisoned data.

Where Teams Get AI Security Wrong

The most expensive mistake you can make is buying visibility and calling it security. A platform that tells you your model just leaked customer data is a historian, not a security tool. A platform that kills the connection before the data leaves is security. Most vendors blur this line on purpose because alerts are easy to build and enforcement is hard. Ask them if they can block a live action or just send an email about it after the damage is done.

Compliance is another trap. Governance teams love tools that spit out shiny reports because it makes the board feel safe. The problem? Those tools usually suck at stopping actual attacks. Compliance wins the budget fight because it’s easy to measure, but security gets the blame when the system breaks. Don't let a "clean audit" lull you into thinking your runtime is actually protected.

Prompt filtering is a single slice of a seven-layer cake, yet teams treat it like a complete posture. You put a filter on your chatbot and check the "AI Security" box? You’ve still got six layers of exposure you haven't even looked at. A filter catches the obvious junk, but adversarial attacks are built to find the gaps you didn't even know existed.

The agent layer is the next big train wreck. Most budgets were built for chatbots where a human is always in the loop. Agentic workflows—multi-step, autonomous, and lightning-fast—have a totally different threat profile. The blast radius of an agent touching your financial systems is massive. If a vendor says their chatbot controls "generalize" to agents, they’re probably lying.

Sources

All statistics and claims in this article trace to named primary documents. Vendor marketing materials and press releases are used only for acquisition facts, not for security methodology claims.

AI Threat Landscape Data

HiddenLayer — 2026 AI Threat Landscape Report (Press Release) — March 18, 2026. Primary source for the 1-in-8 agentic breach statistic, 73% ownership conflict finding, and 31% breach blindness data. Survey of 250 IT and security leaders.

HiddenLayer — 2026 AI Threat Landscape Report (Full Research) — Full report including AIBOM and Model Genealogy capability documentation.

MAESTRO Threat Modeling Framework

Cloud Security Alliance — Agentic AI Threat Modeling Framework: MAESTRO — February 6, 2025. Original MAESTRO framework publication defining the seven agentic AI threat layers.

Cloud Security Alliance — Applying MAESTRO to Real-World Agentic AI Threat Models — February 11, 2026. Practical application guide for enterprise agentic deployments.

Snyk Labs — MAESTRO: Layered Threat Modeling for Agentic AI Ecosystems — February 10, 2026. Independent analysis and application guidance for the MAESTRO framework.

NIST Cyber AI Profile

NIST — Preliminary Draft IR 8596: Cybersecurity Framework Profile for Artificial Intelligence — Official NIST draft document. Primary source for the Secure/Defend/Thwart framework structure.

NIST — Draft NIST Guidelines Rethink Cybersecurity for the AI Era — December 16, 2025. NIST announcement of the Cyber AI Profile draft publication.

Cybersecurity Dive — NIST Adds to AI Security Guidance with Cybersecurity Framework Profile — December 17, 2025. Independent analysis of the Cyber AI Profile's scope and implications.

AI Security Posture Management

ARMO — AI Security Posture Management (AI-SPM): The Complete Guide to Securing AI Workloads — March 3, 2026. Primary source for AI-SPM definition and continuous practice methodology.

Wiz — AI Security Posture Management (AI-SPM): How It Works — May 7, 2026. Independent analysis of AI-SPM practices and tooling landscape.

Concentric AI — AI Security Posture Management Guide for 2026 — April 7, 2026. Operational guidance for implementing AI-SPM programs.

Shai-Hulud Supply Chain Attack

StepSecurity — Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Hits the npm Ecosystem — May 10, 2026. First detailed technical analysis of the attack wave, including CI/CD pipeline compromise methodology.

CyberScoop — 'Mini Shai-Hulud' Malware Compromises Hundreds of Open-Source Packages — May 12, 2026. Coverage of scope: 172 packages, 404 malicious versions, npm and PyPI ecosystems.

The Hacker News — Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More — May 13, 2026. Coverage of specific affected packages including CVE-2026-45321 at CVSS 9.6.

Cloud Security Alliance Labs — Shai-Hulud/Megalodon: A Two-Wave AI Developer Supply Chain Attack — Technical analysis of both attack waves and the provenance attestation bypass technique.

SecurityWeek — Over 100 NPM, PyPI Packages Hit in New Shai-Hulud Supply Chain Attacks — Coverage of the second wave and cumulative package count.

AI Bill of Materials (AIBOM)

Cycode — AIBOM: The Complete Guide — February 2, 2026. Comprehensive guide to AI Bill of Materials structure, components, and implementation.

ARMO — AI Supply Chain Risk: Scanning Vulnerabilities in ML Frameworks — April 26, 2026. Analysis of ML-specific vulnerabilities that conventional container scanning misses.

Agentic Endpoint Security and Agent Identity

Palo Alto Networks — Completes Acquisition of Koi Security — April 14, 2026. Primary source for the formal definition of Agentic Endpoint Security as a product category.

OWASP GenAI Security Project — Top 10 for Agentic Applications 2026 — OWASP's agentic AI security risk taxonomy, used as a reference for agent-specific threat categories.

BigID — Extends Data Access Governance to AI Agents — March 25, 2026. Context for agent data access governance as a specific control requirement.

Acquisition Details

Palo Alto Networks — Completes Acquisition of Protect AI — July 22, 2025. Source for acquisition details and model security layer capabilities.

SentinelOne — Acquires Prompt Security — August 2025. Source for Prompt Security acquisition details and interaction layer capabilities.

Calcalist Tech — Check Point Acquires Lakera — September 2025. Source for Lakera acquisition details and the 80M adversarial prompt training dataset.

Palo Alto Networks — Acquires Portkey — April 30, 2026. Source for AI gateway and traffic observability capability addition to Prisma AIRS.

Help Net Security — Akamai Acquires LayerX — May 14, 2026. Source for $205M acquisition price and browser-native shadow AI discovery capabilities.

Professional Credentials in AI Security

ISACA — Advanced in AI Security Management (AAISM) — Professional certification for AI security management practitioners.

OffSec — AI-300: Advanced AI Red Teaming — Course page for the AI-specific red teaming certification.

OffSec — Introducing OSAI: 24-Hour AI Red Team Challenge — June 16, 2026. Source for the OSAI challenge launch and AI red teaming as a formalized discipline.

Cloud and AI Security Risk Data

GetAIGovernance — Tenable Cloud and AI Security Risk Report 2026 (GAIG Analysis) — Source for the 70% external AI workload exposure finding.

Palo Alto Networks Demand Surge and Earnings Data

CNBC — Palo Alto CEO Says Customer Meeting Requests Have Surged Amid AI Security Concerns — June 2, 2026. Source for the 1,200 meeting requests statistic and 300 Prisma AIRS customer figure.

Constellation Research — Palo Alto Networks Q3 Strong as CEO Says Mythos Boosted Demand — June 2026. Source for Arora's quotes on AI-enabled attack speed from the Q3 FY2026 earnings call.

GAIG Internal References

GetAIGovernance — The State of AI Governance H1 2026 — June 2026. Source for full acquisition timeline, $2B+ figure, and the H1 2026 security incident context.

GetAIGovernance — Palo Alto Networks AI Security Demand Surge — GAIG analysis of the Q3 FY2026 earnings demand signal and its implications for enterprise security buyers.

GetAIGovernance — Workday AI Hiring Lawsuit Analysis — Source for the 1.1 billion decision figure and the accountability gap analysis used in Layer 07.