Enterprise AI
Security Stack The 10-Layer Architecture Every CISO Needs in 2026

The most expensive AI security failures in 2025 and 2026 were not failures of detection — they were failures of anticipation. Organisations deployed AI systems without first asking what attack vectors those systems expose, what CVEs exist in the frameworks powering them, and how a compromise would propagate through connected enterprise infrastructure.

Risk Intelligence is the layer that asks those questions before deployment, not after. It is threat modelling applied to AI: building structured, continuously-updated maps of model attack surfaces, framework vulnerabilities, and organisational exposure that inform every decision downstream in the stack. Automated risk classification pipelines ensure that new AI deployments cannot enter production without a completed risk assessment — replacing ad hoc evaluations with repeatable, auditable processes.

Executive risk scorecards translate the technical output of this layer into the board-level language that drives resource allocation. The CISO who can show leadership a current, quantified AI risk posture — rather than a narrative — builds the organisational support needed to fund the rest of this architecture.

Identity is the control plane for the entire AI stack. An AI agent operating with excessive permissions, a shared API key with god-mode access, or a service account whose privileges have drifted beyond what any task requires — these are not edge cases. A systematic audit of 30 AI agent frameworks in 2026 found that 93% relied on unscoped API keys and 0% had per-agent identity. This is the access control debt that attackers are actively exploiting.

At RSA Conference 2026, Cisco’s announcement of Zero Trust Access for AI agents framed the challenge precisely: traditional IAM tools were built for human users, and their assumptions break completely for autonomous agents that delegate to sub-agents, inherit permissions from connected SaaS platforms, and operate at machine speed without human review. The answer is not extending legacy IAM to AI — it is rebuilding identity governance with AI as a first-class actor.

A managed identity with scoped authentication for every agent, enforced through short-lived tokens rather than persistent credentials, combined with regular access review workflows, represents the baseline from which all other AI security controls derive their effectiveness.

Data protection in AI systems requires a substantially more complex mental model than in traditional applications. The surface area is unprecedented: training data, fine-tuning datasets, RAG retrieval corpora, embedding vector stores, inference inputs, and model outputs all represent distinct exposure pathways. Traditional DLP tools inspect file transfers and network metadata — they do not scan training pipelines, validate embedding contents, or evaluate whether a model response contains information reconstructed from sensitive training examples.

Vector store encryption is a control that receives inadequate attention in standard security architectures. A RAG system’s knowledge base is not just a database — it is a queryable representation of the organisation’s most sensitive information. Every document indexed into the retrieval corpus becomes both a potential injection vector and a potential data source for extraction attacks. Encrypting at rest is necessary but insufficient; the access controls on what can be retrieved, by whom, and under what conditions require the same rigour as production database access controls.

PII tokenization before training prevents models from memorising personally identifiable information in their weights — closing the model inversion attack surface that allows adversaries to reverse-engineer training data through systematic querying.

Agentic AI attacks traverse systems, exfiltrate data, and escalate privileges at machine speed — before a human analyst can respond using traditional playbooks. Average detection time for AI-related breaches currently sits at 247 days for shadow AI incidents. The incident response layer exists to shrink that number, and to ensure that when containment happens, it happens completely.

AI-specific incident response differs from traditional IR in one critical dimension: the blast radius is defined not just by what the attacker accessed, but by what a compromised AI agent did. An agent that reads credentials, forwards data, and modifies records between the time of compromise and the time of detection has caused cascading damage that requires a fundamentally different forensic approach — one that can reconstruct the agent’s decision trail, not just the network traffic.

Cryptographic controls — HSM-managed key storage, encrypted model artifacts, and TLS termination at every API gateway — ensure that even in the event of infrastructure compromise, exfiltrated model artefacts or intercepted inference traffic cannot be used by attackers to reconstruct proprietary models or extract training data.

The EU AI Act’s August 2026 enforcement deadline for high-risk systems makes compliance mapping an operational imperative rather than a periodic exercise. Serious incidents affecting high-risk AI systems must now be reported to regulators within two to fifteen days depending on severity. Producing required documentation, logs, and evidence within those windows requires that audit readiness is continuous — not assembled in response to a notification.

The compliance challenge for AI systems is substantially more complex than for traditional software. Regulators require documentation spanning the entire AI lifecycle: training data provenance and bias testing, model architecture and performance characteristics, deployment procedures, ongoing monitoring evidence, post-market surveillance data, and incident history with post-mortem analysis. This is not documentation that can be produced retrospectively from memory — it must be captured as operational artefacts throughout the system’s life.

Automated isolation triggers — controls that quarantine a compromised or non-compliant AI system before human investigation begins — reduce both the blast radius of incidents and the compliance exposure created by continued operation of a known-compromised system during the investigation period.

Monitoring is knowing something is wrong. Observability is knowing why. AI systems require both — and the distinction matters operationally. A monitoring dashboard that shows a drop in model accuracy tells you there is a problem. An observable AI system with drift detection, feature importance tracking, and adversarial request identification tells you whether the accuracy drop is caused by data drift, a poisoned input batch, an adversarial campaign, or a genuine shift in the underlying distribution.

Statistical drift detection — using Kolmogorov-Smirnov tests, Population Stability Index calculations, or Jensen-Shannon divergence — provides the quantitative foundation for distinguishing normal model evolution from security-relevant behavioural change. Without baseline metrics established at deployment, drift has no reference point and anomalies have no definition. This is why monitoring must be activated before the first production inference, not after the first production incident.

Adversarial request identification — the ability to flag inputs that exhibit patterns characteristic of extraction attacks, jailbreak attempts, or prompt injection — requires AI-specific tooling. Traditional WAFs and SIEM platforms were not built to evaluate the semantic content of inference requests. The monitoring layer must integrate AI-native tools capable of assessing intent, not just traffic volume.

Output filtering is the final safety boundary between an AI system and the users or processes that act on its responses. A model that has been well-governed, carefully trained, and thoroughly monitored can still produce harmful, biased, or policy-violating output — particularly in the face of adversarial inputs designed to elicit responses that bypass internal safety training.

Factuality verification layers represent an increasingly critical component of this layer as AI is deployed in high-stakes domains. A legal AI assistant that fabricates citations, a compliance system that misrepresents regulatory requirements, or a medical information tool that confidently produces incorrect dosage information — these outputs cause real harm that occurs after the model returns a response, not during training or inference. Output filtering at the factuality level requires either retrieval augmentation with authoritative sources or post-generation verification against verified knowledge bases.

Response risk scoring — assigning each output a risk score before delivery — enables dynamic routing: low-risk responses delivered immediately, medium-risk flagged for user review, high-risk responses blocked and logged for investigation. This probabilistic approach is more operationally sustainable than binary block/allow policies that generate alert fatigue.

Agent permissioning is the layer that has produced the most visible security failures of 2026. As Proofpoint’s analysis noted at launch, a single AI request can trigger dozens of autonomous actions across multiple systems — at machine speed, without human oversight. The question has shifted from “Does this agent have the right credentials?” to “Is this agent doing what it was supposed to be doing — and can a human prove they approved it?”

Intent-based security — granting and restricting agent access based on what the agent is supposed to be doing for a specific task, rather than static role assignments — represents the architectural evolution that traditional RBAC cannot provide. 25.5% of deployed agents can spawn and instruct sub-agents. RBAC has no concept of delegation chains where authority propagates through autonomous systems. Capability whitelisting, with function-level grants that expire when the task concludes, is the structural answer to this problem.

Approval workflows for sensitive actions — data deletion, financial operations, external communications, security configuration changes — introduce the human oversight that prevents a hijacked or misaligned agent from causing damage at machine speed during the window between compromise and detection.

Model protection operates at the boundary between the AI system and everything that interacts with it. It addresses the structural vulnerability that makes prompt injection possible — the absence of clear separation between trusted system instructions and untrusted user inputs — and extends that principle to every input the model processes, every tool call it makes, and every output it produces.

Delimiter-based separation and system instruction isolation are engineering controls that reduce but cannot eliminate prompt injection risk. The EU AI Act requires that AI system boundaries are clearly defined and enforced — this layer is where that requirement becomes a technical control. Input sanitisation at every ingestion point treats every external input as potentially adversarial — the correct posture for any system that processes content from untrusted sources at scale.

Tool call verification is particularly critical for agentic systems. When an AI agent decides to call an external API, send an email, execute code, or modify a database record, that decision is itself a potential attack surface. Verification against a policy layer before execution — confirming the tool call is consistent with the agent’s defined purpose and within its authorised scope — is the control that prevents a hijacked reasoning process from triggering real-world actions.

Predictive analytics closes the loop that risk intelligence opens. Where risk intelligence identifies threat vectors before deployment, predictive analytics uses operational data from deployed systems to identify emerging attack patterns, model degradation trajectories, and anomalous usage trends before they cross into incident territory. It is the difference between knowing that extraction attacks are theoretically possible and knowing that your model is currently being subjected to one.

Artifact versioning and signing enable the predictive layer to correlate behavioural changes in a model with specific version events — distinguishing performance degradation caused by a problematic update from the same degradation caused by an ongoing poisoning campaign. A centralised model repository with enforced versioning ensures that this correlation is always possible, regardless of how many teams are deploying how many model versions in parallel.

Isolated hosting environments for high-risk or sensitive AI workloads reduce the lateral movement available to attackers who compromise one model — ensuring that a successful extraction attack on one system does not provide a foothold into the broader AI infrastructure. Isolation is not just a security control; it is a blast radius constraint that limits the worst-case consequence of any single failure.