The Enterprise Security Model Was Built for Humans — AI Agents Are Breaking It
For the better part of a decade, enterprise security teams invested heavily in a framework built around one central assumption: humans write the code, humans run the applications, and humans are the actors whose behaviour needs to be governed. Shift-left practices pushed vulnerability detection earlier into the development cycle. Zero trust architectures reduced lateral movement after a breach. Developer toolchains added guardrails inside integrated development environments. The model was coherent, well-funded, and widely adopted — and it is now quietly falling apart.
The reason is the rapid migration of AI agents from experimental research projects into live production workloads. Unlike traditional software, AI agents operate autonomously. They consume tokens and APIs directly, make decisions at runtime without human checkpoints, and generate an audit trail only when someone has specifically required one in advance. According to a Gartner forecast, more than 80 percent of enterprises will have deployed generative AI-enabled applications by 2026. Yet the security architecture guarding those deployments has, in most organisations, not fundamentally changed. That gap is the core argument behind what practitioners are now calling Platform Engineering 2.0 — and it has direct consequences for anyone responsible for data privacy, regulatory compliance, or digital infrastructure.
For European organisations operating under GDPR, the stakes are particularly concrete. AI inference pipelines that expose personally identifiable information without audit trails, or that pull models from unverified registries, are not merely technical liabilities. They are potential regulatory violations with financial consequences.
What Existing Security Tooling Doesn't See in an AI-Enabled Enterprise
The honest inventory of gaps in current enterprise security tooling is substantial. Four categories of threat stand out as both technically distinct and actively present in organisations that have begun deploying AI workloads without upgrading their security architecture.
Prompt injection introduces malicious instructions into live inference streams. No static application security testing (SAST) or dynamic application security testing (DAST) tool is capable of detecting it — these tools were designed for static code, not dynamic model interactions. A malicious actor can craft inputs that manipulate an AI agent's behaviour without ever touching the underlying code.
Model poisoning occurs when models are pulled from registries without signing or provenance verification. The software signing workflows that enterprises already apply to code artifacts have no equivalent in most model registries. A compromised model imported from an external source can carry malicious behaviour that is invisible to conventional code scanning.
Inference data leaks represent a particularly serious GDPR risk. Models can expose personally identifiable information or intellectual property through their responses, with no audit trail and no embedded controls. Data loss prevention (DLP) tools that sit at the network or endpoint layer cannot see inside inference pipelines.
Shadow AI sprawl is the enterprise equivalent of shadow IT: developers and teams consuming unsanctioned models that bypass data governance and DLP controls entirely. According to IBM's Cost of a Data Breach Report, organisations with lower security maturity consistently face higher breach costs — and ungoverned AI adoption is rapidly becoming one of the primary vectors driving that exposure.
"The attack surfaces introduced by AI agents are categorically different from anything shift-left or zero trust was designed to address. The platform itself must become the trust boundary — there is no other control surface with the necessary scope."
— Platform Engineering 2.0 whitepaper, Broadcom and PlatformEngineering.orgNone of these threats are hypothetical. They are active in enterprises that have already begun deploying AI workloads. The absence of incidents on the security dashboard does not mean the exposure isn't there — it often means the tooling doesn't have visibility into these layers yet.
Platform Engineering 2.0: The Four AI Security Control Surfaces Explained
The architectural response to these threats — as outlined in the Platform Engineering 2.0 framework developed by Broadcom and PlatformEngineering.org — centres on making the platform itself the primary trust boundary for AI. This is a structural shift, not a procedural one. You cannot train your way out of prompt injection. Quarterly compliance audits cannot catch model poisoning in real time. The only control surface with the scope, depth, and enforcement capability to address these threats is the infrastructure layer.
The framework identifies four specific control surfaces that operationalise platform-level AI security:
| Control Surface | What It Does | Gap It Closes |
|---|---|---|
| Model Governance | Versioned registry with provenance tracking, approval gates, and drift monitoring | Model poisoning, unverified third-party models |
| Prompt Security | Platform-level input sanitisation, output filtering, context boundary enforcement | Prompt injection attacks in live inference |
| Data Isolation & Privacy | Tenant-level data boundaries, encryption, DLP policies embedded in inference pipelines with PII detection and real-time masking | Inference data leaks, GDPR non-compliance |
| Inference Audit | Continuous real-time audit trail of every AI inference, with explainability outputs and compliance reporting | Invisible agent actions, compliance gaps |
When these four surfaces are embedded at the infrastructure layer, security becomes, in the framework's language, "invisible and immutable by default." Configurations enforce least privilege, mutual TLS, micro-segmentation, and automated secrets rotation without requiring individual development teams to configure them. Compliance shifts from a periodic checkbox exercise to a continuous, real-time state — a model that aligns directly with the GDPR's requirements for ongoing data protection by design and by default.
Why AI Agents Create an Entirely New Identity and Access Management Problem
Beyond the technical control surfaces, Platform Engineering 2.0 surfaces a governance challenge that many identity and access management strategies have not yet confronted: AI agents are a new class of non-human identity operating inside the enterprise.
Traditional identity and access management was built to govern human users and, more recently, service accounts. AI agents are different in kind. They consume APIs rather than interfaces. They need scoped permissions, non-human identity credentials, budget controls on resource consumption, and egress controls to prevent unauthorised data exfiltration. The OWASP Top 10 for Large Language Model Applications explicitly identifies excessive agency and insecure plugin design — both manifestations of inadequate agent identity governance — among the most critical risks in deployed AI systems.
The governance components needed for agent identity management include MCP-compatible APIs for agent discovery, policy guardrails constraining agent actions to pre-approved patterns, full audit logging that captures the complete decision chain, and escalation mechanisms that route uncertain or high-stakes decisions back to human reviewers. If an enterprise's identity and access management strategy does not yet account for agent identities, that gap will widen materially as agentic deployments scale — which, based on current adoption trajectories documented by McKinsey's State of AI research, is happening faster than most security roadmaps anticipated.
What This Means for GDPR Compliance and the EU AI Act
For European organisations and those handling European data, the Platform Engineering 2.0 framework maps closely onto existing and emerging regulatory requirements. GDPR's Article 25 mandates data protection by design and by default — a principle that is effectively unachievable if DLP controls and data isolation exist at the application layer only, where they can be bypassed or misconfigured by individual teams. Embedding these controls at the infrastructure layer is not merely a best practice; it is arguably the only technically sound interpretation of what Article 25 requires in an AI-enabled environment.
The EU AI Act, which entered into force and is being phased in progressively, adds further requirements for high-risk AI systems — including mandatory logging, human oversight mechanisms, and transparency obligations. The inference audit and agent escalation components of Platform Engineering 2.0 directly address these requirements. Organisations that build these controls into their platform now will be significantly better positioned for EU AI Act compliance than those treating these as future considerations.
The alignment between sound AI security architecture and European regulatory requirements is not coincidental. Both are responses to the same underlying reality: when AI systems make decisions autonomously, process sensitive data, and interact with other systems without human review, the governance frameworks that worked for traditional software are structurally insufficient. The regulatory response in Europe has been to mandate what good engineering practice already demands: auditability, human oversight, data minimisation, and accountability embedded into systems by design.
Small and medium-sized businesses deploying AI tools — whether SaaS-based or self-hosted — are not exempt from these dynamics. If an AI tool processes personal data of EU residents, GDPR applies regardless of company size. Shadow AI sprawl, where teams adopt external AI services without going through procurement or security review, is particularly acute in smaller organisations where governance processes are less formalised. The practical implication: before deploying any AI tool that touches customer data, verify that the vendor can demonstrate model provenance, inference logging, and data isolation.
