Security leaders have spent the last decade building controls around people and code. Shift-left practices caught vulnerabilities earlier in the development cycle. Zero trust reduced lateral blast radius. Developer tooling added guardrails at the IDE. The architecture was sound — for an enterprise where humans wrote code and humans ran applications.
That enterprise no longer exists.
AI agents are moving from research projects to production workloads at a pace most security organizations weren’t designed to match. They operate autonomously, consume tokens and APIs directly, make decisions without human checkpoints, and leave behind an audit trail only if someone thought to require one.
The shift-left model, which placed responsibility on developers to catch security issues before deployment, cannot catch what happens in live inference streams, inside model registries, or in the decisions an agent makes at runtime.
The attack surfaces are new. The tooling hasn’t caught up. And the conventional response — add another developer-side control — won’t close the gap.
What Your Current Tooling Doesn’t See
Here is the honest inventory of what existing security tooling misses in an AI-enabled enterprise:
Prompt injection introduces malicious instructions into live inference streams. No SAST or DAST tool detects it — they were built for static code, not dynamic model interactions or for AI workloads.
Model poisoning occurs when models are pulled from registries without signing or provenance verification. There are no equivalent controls to the software signing workflows most enterprises already apply to code artifacts.
Inference data leaks expose PII and intellectual property through model responses with no audit trail and no embedded controls — invisible to DLP tools that sit at the network or endpoint layer.
Shadow AI sprawl means developers and teams are consuming unsanctioned models that bypass data governance and DLP controls entirely.
None of these are hypothetical. All of them are active in enterprises that have started deploying AI workloads without updating their security architecture to match.
The Platform Is the Most Comprehensive Trust Boundary
The response to this challenge is architectural, not procedural. You cannot train your way out of prompt injection. You cannot audit your way out of model poisoning at quarterly checkpoints. The only control surface with the scope, depth, and enforcement capability to address these threats is the platform itself.
Platform Engineering 2.0 defines four control surfaces that operationalize platform-level AI security and data privacy:
Model governance: A versioned model registry with provenance tracking, approval gates, and drift monitoring. Every model in production has a chain of custody. No model gets deployed without a signing check.
Prompt security: Platform-level input sanitization and output filtering. Context boundary enforcement that prevents injection attacks from propagating through inference pipelines — at the infrastructure layer, not the application layer.
Data isolation and privacy: Tenant-level data boundaries with encryption at rest and in transit, with DLP policies embedded directly in inference pipelines — including PII detection and real-time masking. Pipelines and guardrails for data handling and associated controls for privacy are also essential.
Inference audit: A full audit trail of every AI inference, with explainability outputs and compliance reporting. Not a point-in-time snapshot — a continuous, real-time record covering both human and agent actions.
Taken together, these make the platform the trust boundary for AI. Security sits deep in the infrastructure — invisible and immutable by default. Configurations enforce least privilege, mTLS, micro-segmentation, and automated secrets rotation without requiring developers to configure them. Compliance becomes continuous rather than periodic.
Agents Are a New Identity Problem
Agentic AI introduces something security teams must confront directly: a new class of non-human identity operating inside your enterprise. AI agents consume APIs rather than interfaces. They need scoped permissions, non-human identity credentials, budget controls, and egress controls. The key governance components are MCP-compatible APIs for agent discovery, policy guardrails constraining agent actions to pre-approved patterns, audit logging capturing the full decision chain, and escalation mechanisms routing uncertain decisions to human reviewers.
If your identity and access management strategy doesn’t yet account for agent identities, it has a gap — and that gap will widen as agentic deployments scale.
What This Means for the CSO
Security is becoming structurally unanswerable at the developer layer. The controls that worked when humans were the only actors in the system are insufficient for an environment where agents are making decisions, consuming resources, and interacting with your most sensitive data pipelines — often without a human in the loop.
The security posture of your enterprise AI deployments will be determined largely by the maturity of your platform engineering function. That is not a technology decision to delegate to a platform team working in isolation. It is a security architecture decision that belongs on the CSO’s agenda.
The ask is concrete: engage your platform engineering leadership. Demand visibility into how AI workloads are governed, how agent identities are managed, and whether the four AI security control surfaces — model governance, prompt security, data isolation, and inference audit — are embedded in the platform or left to individual teams to figure out.
If the answer is the latter, you have identified your most urgent security gap.
For a comprehensive framework on embedding security into the AI-era platform, read the full whitepaper: Platform Engineering 2.0: An Evolution for the AI Era, co-authored by Broadcom and PlatformEngineering.org.
No Responses