Platform engineering teams have spent the last decade standardizing Kubernetes clusters, pipelines, internal developer platforms (IDPs), and processes for web and microservice workloads. Now, as organizations integrate large language models (LLMs) and AI agents into production workflows, platform engineering 1.0 is shifting into platform engineering 2.0.
This shift to platform engineering 2.0 has clear implications for security, specifically for isolation and compliance in this new agentic world. But for those understandably concerned about what they must spend, an effective platform engineering 2.0 strategy should represent an evolution, not a reset. These changes in the foundational platform engineering 1.0 substrate are available in Broadcom’s recently introduced Platform Engineering 2.0 blueprint.
For governance and compliance, confinement to documents and application code isn't enough. Instead, structured frameworks must protect against AI risks by implementing consistent guardrails, policies, and procedures with real technical controls. Security responsibilities must move down into the platform itself, enforced at the platform level, not bolted on after deployment.
AI escalates security worries.
A long-held truth in IT is that a human will inevitably (knowingly or not) introduce or inject bad code into the infrastructure. With AI agents at work, that axiom is amplified if AI is allowed to introduce bad code into the infrastructure, and the effects can range from minor bugs to cataclysmic outages, especially in highly distributed environments. This is precisely why strong isolation mechanisms are essential.
A second concern is complying with expansive new regulations designed to address the explosion in AI-generated code and large language models (LLMs). Because of new regulatory requirements for data residency, continuous compliance is a requirement.
To solve this, platform engineering 2.0 automates policy-as-code enforcement as a core capability. This gives security and compliance teams a native platform layer to dictate guardrails, rather than forcing them to audit fragile, bespoke application architectures after deployment.
How platform engineering 2.0 treats AI security
Platform engineering 2.0 treats AI security not as a special case but as a first‑class workload type, with native constructs for governance and isolation. While platform engineering 1.0 offered “secure by default” Kubernetes clusters and GitOps pipelines, 2.0 adds “governed by default” model access and “isolated by default” AI workload lanes.
Shifting security down into the platform and runtime layers is designed to complement legacy "shift-left" pipeline checks. It acts as a continuous runtime safety net, catching the active, unpredictable threats that static code analysis and pipeline templates completely miss. This baseline platform architecture is required because frontier models are widening the security gap much faster than traditional, bolt-on application controls can respond to.
The platform substrate must natively mitigate model poisoning and inference data leaks - two critical attack vectors that platform engineering 1.0 architectures were never designed to anticipate. Even common risks like prompt injections ultimately fall under this broader umbrella of isolation, and the industry currently lacks native platform architectures to handle them seamlessly.
At a high level, the 2.0 iteration revolves around two foundational security pillars: First, there's strict, platform‑level AI model governance using a control plane that enforces policy, data‑handling rules, and logging across all models and providers, regardless of where they run. Second, robust workload isolation is baked into the platform fabric with structural enforcement that one AI workload cannot bleed into another’s data, secrets, or performance envelope.
Both must be exposed as platform capabilities rather than bespoke patterns, so developers can consume them as self-service infrastructure through APIs and templates rather than reimplementing them per application.
Pillar 1: Model governance
Model governance serves as a centralized control plane. Because model-specific governance breaks at scale, a control layer above the model tier can enforce policy, log decisions, and monitor behavior across all models.
Platform engineering 2.0 operationalizes this through four core elements. First, a central model registry tracks approved capabilities and locations via a consistent API. Second, unified policy enforcement locks down data-handling and safety rules universally. Third, centralized auditing provides a single pane of glass for tracing incidents and logging prompts. Finally, standardized access workflows automatically map developer requests to risk tiers, replacing manual security exemptions.
This "infrastructure as AI" acts as a referee, allowing the enterprise platform team to select the models they want, so the developer can pick and choose what they need without having to submit a job ticket, configure YAML files, etc.
Pillar 2: Workload isolation
Workload isolation establishes a structural guarantee to contain exploits. Because AI disrupts traditional multi-tenancy, platforms are forced to isolate shared GPUs and prevent embedding commingling within vector stores to eliminate downstream data leaks.
This isolation requires dedicated domains to separate experimental sandboxes, internal workloads, and regulated data tiers. Tagged resource pools and workload groups must partition hardware backends so that heavy inference jobs never degrade latency-sensitive interactive applications.
Furthermore, integrating zero-trust identity controls binds models and tools to narrowly scoped service identities, preventing lateral movement when prompt injections inevitably succeed. Finally, network, storage, and runtime policies must align across cluster, node, and pod layers using confidential computing.
Platform teams can then encode these isolation strategies into reusable, opinionated blocks inside developer portals.
How AI security is changing platform engineering
Platform Engineering 2.0 must incorporate AI security that covers the full range of stakeholders, from developers to data scientists to business stakeholders. In response, PlatformEngineering.org and Broadcom have introduced a multi-year directional blueprint, Platform Engineering 2.0. It's a platform substrate organized around five interlocking architectural pillars:
An AI-native platform transitions the IDP to an agentic development platform (ADP) while executing GPU/TPU provisioning, MCP gateways, and AI agents as platform citizens.
A multi-persona experience serves the wider enterprise (beyond developers) with tailored experience layers for data scientists, FinOps and security leaders, and AI agents.
Embedded FinOps shifts cost tracking from retrospective reporting to provisioning time to govern token economics, real-time attribution, and predeployment cost gates.
Security shifts down into the platform and runtime substrate to mitigate shadow AI sprawl, support prompt security, and enable model registry governance.
A foundation built on a composable architecture rejects rigid "build vs. buy" thinking in favor of modular, API‑first building blocks that can be swapped or repaved quickly as workloads demand.
A neutral, scalable AI trust boundary.
Taken together, strict model governance and strong workload isolation will help create a neutral, platform‑level trust boundary for AI, and platform engineering 2.0 will play a key role. Instead of each application drawing its own fuzzy perimeter around models and tools, the platform defines a consistent line.
Inside the boundary, models should be invoked through a governed plane, workloads run in defined isolation domains, and shared controls mediate access to data and tools. Outside the boundary, shadow AI and ad‑hoc integrations are clearly out of policy, easier to discover, and easier to replace with sanctioned patterns.
Organizations are already feeling the strain of AI‑driven sprawl, and platform engineering 2.0 aims to ease that. Platform engineering 2.0 provides a systemic way to experiment with AI, scale native workloads, and absorb new model capabilities without redrawing the security architecture every quarter. The sooner platform teams move the AI trust boundary into platform‑managed architectures with model governance and workload isolation as first‑class primitives, the sooner they can properly secure AI workloads.
