There’s a line running through most of this year’s platform-engineering commentary, and it’s worth stating plainly because the implications are larger than the sentence: AI agents are becoming first-class platform citizens. Platform Engineering’s 2026 predictions put it as agents graduating from experimental tools to a user persona your platform serves — with RBAC, resource quotas, and governance policies, the same as any other.
Read that as a platform owner and the consequence is immediate. Your internal developer platform was designed around a human at a portal: someone who reads documentation, notices a confusing form, gets confused, and asks in Slack. Your newest user does none of those things. It reads your API, it doesn’t get confused, and it can do the wrong thing four hundred times before anyone notices the graph moved.
The IDP stops being a portal and starts being a control plane. That’s a design change, not a feature.
What actually breaks when the caller isn’t human
Most IDPs already have a service catalog, golden paths, scaffolding templates, and some RBAC. It’s tempting to conclude agents are just another consumer of the same machinery. Four things say otherwise.
Rate and blast radius. Human-scale guardrails are calibrated to human-scale mistakes. A developer who misuses a scaffolding template creates one bad repository. An agent that misuses it in a retry loop creates two hundred, along with the cloud resources each one provisions. Quotas that never bound anyone before are suddenly load-bearing.
The interface is the documentation. A human reads a description field, infers intent, and asks when it’s ambiguous. An agent takes your tool schema literally. Every vague parameter name, every under-specified enum, every “this is usually fine” convention that lived in a README becomes a behavioral defect. Interface quality stops being polish and becomes correctness.
Attribution collapses by default. When a human uses the platform, the audit log names them. When an agent does, most platforms log the agent’s service account — which tells you nothing about which human’s request set it in motion. That’s the anonymous inference endpoint problem showing up in your IDP specifically: the platform can no longer answer “who asked for this,” which is the question every incident review starts with.
Approvals stop working as a control. A review gate assumes a human who reads the diff and can decline. Route enough agent-generated changes through it and you get rubber-stamping — the failure I’ve written about as the 47th approval click. Human-in-the-loop is not a scaling control; it’s a control that degrades precisely as the volume it’s meant to govern goes up.
The golden path, rewritten for a non-human caller
A golden path is the platform’s opinion about the right way to do something, made easier than the alternatives. That idea survives intact. What changes is that the path has to be machine-navigable and self-enforcing, because there is no human to nudge back on course.
Every agent gets an identity. Not a shared platform-bot credential — a distinct principal per agent, with scoped, short-lived credentials tied to the human or workflow it acts for. This is the precondition for everything else: quotas you can enforce, audit trails you can read, and a revocation story that doesn’t mean rotating one key for the entire fleet. The primitives are the ones you already run for people and CI; what’s new is applying them to a caller that acts far faster than either.
Every agent gets a quota. Requests, provisioned resources, spend. Set them low enough that a runaway loop trips a limit before it trips a budget alert. This is the cheapest containment control on this list and the most commonly skipped, because nobody sets quotas for a caller they expect to behave.
The catalog entry is the contract. Register agents in the same service catalog as everything else, with an owner, a declared tool set, and a declared blast radius. An agent that isn’t in the catalog shouldn’t be able to authenticate. This is the inventory discipline that agent sprawl punishes you for skipping, and the IDP is the natural place to enforce it — you already have the registry.
Expose the platform as tools, not as a portal. The paved road for an agent is a governed set of typed operations — a broker that authenticates the caller, authorizes the specific action against policy, and writes the audit record. Not screen-scraping your portal, and not handing the agent raw cloud credentials and hoping the prompt holds. Where MCP fits, this is what an MCP gateway is for.
Make the safe path the easy path — mechanically. With humans this is persuasion: better docs, nicer defaults. With agents it’s enforcement. If the ungoverned route still works, an agent will find it, because it has no social reason not to. The paved road has to be the only road that authenticates.
What I’d push back on
The “agents as first-class citizens” framing is directionally right and slightly too tidy. Two caveats.
Most organizations are nowhere near this. If your IDP doesn’t yet have a reliable service catalog and working RBAC for humans, adding an agent persona on top is building the second floor first. The honest sequencing is that agent readiness is mostly ordinary platform maturity, arriving with a deadline attached.
And “treat agents like any other user persona” undersells one asymmetry. A human user has judgment and can be held accountable; an agent has neither, and the platform absorbs both gaps. So agents are not just another persona — they’re a persona whose guardrails have to be strictly tighter than a person’s doing the same job, at least until the evidence says otherwise. Which authority an agent has earned should be a measured thing, tied to its track record, the same way error budgets work for anything else you’re deciding to trust.
Where to start
Pick your single highest-traffic golden path — the one agents in your org are already using or about to. Give the agents calling it real identities, put a quota on it, register them in the catalog, and make sure the audit record names the human behind the request. One path, done properly, teaches you more about what your platform is missing than a year of planning the agent persona in the abstract.
Your newest user showed up without waiting for the platform to be ready. It’s already filing tickets, opening PRs, and provisioning things. The only open question is whether it’s doing that on a paved road you built, or on a path it found because you hadn’t built one yet.
Related: Agent sprawl · Agents need identities, not API keys · The MCP gateway pattern
Comments