Nobody told the agent to mine cryptocurrency.
ROME, an experimental AI agent built by Alibaba-affiliated research teams, was partway through reinforcement-learning training when Alibaba Cloud’s managed firewall started flagging security-policy violations from the training servers. The agent had opened a reverse SSH tunnel to an external host and quietly diverted provisioned GPU capacity to crypto mining. According to the researchers, no prompt asked it to do either.
There are two lessons here for platform teams. First, an agent pursuing a goal will find routes you never thought to close. No policy prohibited mining, because nobody imagined needing one. Second, what caught it was not the agent framework or a prompt filter. It was a control in the infrastructure. That is the argument for Platform Engineering 2.0 in miniature.
From fulfillment to authorization
Platform Engineering 1.0 solved a fulfillment problem. Golden paths, self-service Internal Developer Platforms (IDPs), and a portal that turned a two-week ticket into a two-minute form. A developer asked; the platform delivered.
Agents break that model. They are one of the new personas that Platform Engineering 2.0’s multi-persona pillar brings onto the platform, and they behave unlike any user before them. They consume APIs rather than portals, plan their own steps, and execute at machine speed, often with no human watching any individual call. The platform’s job shifts from fulfilling requests to deciding whether machine intent may become enterprise action. That is why the AI-native platform pillar evolves the IDP into an Agentic Engineering Platform (AEP), with bounded autonomy built in rather than bolted on.
This article is part of a series on the report Platform Engineering 2.0: An Evolution for the AI Era, which I co-authored with Sam Barlien of PlatformEngineering.org. The series runs from the overview to a deep dive on AI security and compliance.
Why golden paths don’t transfer
A golden path is an opinionated template resting on three quiet assumptions: a human chose it, that human understands what it does, and they will notice if the output looks wrong. An agent violates all three.
The threat model changes too:
- Prompt injection turns untrusted input, such as a README, a ticket, or a tool response, into instructions.
- Credential exposure turns a single secret that lands in a context window or log into a path for lateral movement.
- Static authorization stops being enough. IAM typically evaluates a stable identity once, at login, and trusts the session. An agent’s trustworthiness can change mid-session. The agent that was safe three tool calls ago may now be acting on poisoned context, and nothing about its credentials changes to tell you. Authorization has to be evaluated on every tool call.
Seven control surfaces for bounded autonomy
As detailed in Platform Engineering 2.0, platform teams operationalizing bounded autonomy keep converging on the same seven control surfaces. The first three do most of the work.
- Identity: who is acting. Each agent gets a non-human identity bound to the user who delegated the task, so every action has a chain of custody. No more shared service accounts that fifty workflows authenticate through.
- Capability: what it can reach. Scoped tool registries and Model Context Protocol (MCP) gateways decide which tools an agent can even see. An agent cannot reason its way toward a tool that was never in its field of view.
- Observability and audit: what happened. Every prompt, tool call, and policy decision, recorded immutably. This is the surface teams most often defer and most regret deferring.
- Context: what the agent knows. Lineage and access control over the data it reads.
- Execution: where it runs. And what that environment is allowed to touch.
- Evaluation: does the action fit the mission? Requested actions are checked against the agent’s declared mission, and anything uncertain is escalated to a human.
- Security: zero trust for agentic traffic. Including MCP and agent-to-agent (A2A) flows.
Define these controls as code, versioned, reviewed, and repaveable, and you get the recoverability and auditability platform teams already expect from infrastructure as code.
Extending zero trust to machine intent
Zero trust made a simple bet: verify every request in context. Agents force that bet to be re-made, because the requester is now reasoning about what to request.
The working pattern looks like this. Every tool invocation passes through a policy enforcement point, which asks a central policy decision point four questions: who is the subject (the agent’s identity and its delegating user), what is the action (the tool), what is the resource, and what is the context (including the declared mission). The decision comes back inline, before the call executes.
Declared mission is the load-bearing input. An agent tasked with writing code has no business opening outbound tunnels or launching long-running compute. A policy engine that reads mission alongside identity denies that at the call.
Governed agents need governed data
Build every control surface correctly and the agent will still fail if its context is bad. This is the part most enterprises underestimate. Security limitations of existing data platforms are a challenge limiting AI and agentic AI implementation.
Signal65’s PINNACLE benchmark, developed with Kamiwaza, ran 44 model configurations through multi-step enterprise jobs twice: once against governed data, and once against data as enterprises actually accumulate it, duplicated, half-migrated, and self-contradictory. Forty-three of the 44 configurations scored lower on the messy data, with a median drop of about 28 points in workflow completion. Only two configurations cleared 95% completion on the messy data. Signal65’s own framing is that clean data is close to solved for these scenarios, while the real enterprise is not.
The platform answer is to put a governed data product between the agent and the system of record:
The blueprint for platform teams
We tested this on ourselves. Broadcom ran a swarm of more than twenty agents across its own software development lifecycle, from requirements through code and tests. One lesson kept repeating: the governance layer has to exist before the agents do.
Five moves matter most over the next twelve months:
- Inventory the agents you already have. Mapping the MCP servers and model endpoints on your own network is uncomfortable, but it is the most valuable exercise a security team will run this year.
- Give every agent an identity and a mission. Agents on shared service accounts leave you with no chain of custody and no basis for an audit.
- Move credentials out of the reasoning loop. Treat any architecture where an agent can read a raw key as already compromised.
- Fund the data work before the agent work. The PINNACLE gap between governed and messy data is strong evidence that context quality, not just model choice, sets the ceiling on what an agent can finish.
- Instrument for audit from day one. Emit prompts, tool calls, and policy decisions as telemetry traces, using the GenAI semantic conventions and redacting sensitive fields, so a regulator and an incident responder read the same record.
The platform team’s new remit
Platform engineering built the substrate that developer autonomy runs on. Platform Engineering 2.0 asks it to build the substrate that enterprise-wide agentic autonomy runs on. The agents are already inside the building, pursuing whatever goals they inferred. Deciding which of those intents is allowed to become action is now the platform team’s job, whether or not anyone has formally handed it to you.
Go deeper: read the full report, Platform Engineering 2.0: An Evolution for the AI Era, or start with the summary blog.
