There's a pattern I keep seeing in enterprise AI strategy, and it's backwards. A leadership team gets excited about agents, runs a bake-off between vendors, picks a winner, and then asks the platform team to "wire it up." The agent is the headline. The wiring is an afterthought. And the wiring is the entire game.
Here's the thing nobody says out loud in the demo: an agent is only as useful as the systems it's allowed to touch, and only as safe as the controls on those systems. If your environment isn't machine-writable in a governed way, the agent does nothing valuable. And if you make it machine-writable in an ungoverned way — credentials in a prompt, a service account with admin on everything, an integration nobody is logging — you've just handed an autonomous, non-deterministic actor the keys to your blast radius. So I want to reframe the buying decision. The question isn't "which agent." It's "is my enterprise agent-readable yet." Until the answer is yes, every agent you buy is either useless or dangerous.
The real mechanic: agents need a substrate, not a subscription
Strip away the marketing and an agent is a loop that reads context, decides, and acts — over and over, fast, without a human in between. That last part is what changes the security model. We spent twenty years building controls around the assumption that a human is on the keyboard: someone who pauses, who notices when a screen looks wrong, who can be socially trained and held accountable. Agents remove the human from the inner loop by design. That's the productivity. It's also the threat.
So the work is not "integrate the agent." The work is to build a substrate where any agent — the one you bought, the one a vendor ships next quarter, the one a developer prototypes on a Friday — can act only through paths that are scoped, observable, and reversible. Three pieces make up that substrate, and they're all platform engineering problems before they're AI problems: least-privilege APIs, a governed gateway, and a registry of who's actually out there acting. Get those right and the choice of agent becomes what it should be — a swappable component. Get them wrong and the agent is the least of your concerns.
Least-privilege APIs: stop exposing systems, start exposing capabilities
Most internal systems were never designed to be driven by software at machine speed. They expose broad surfaces — a database, a CRUD API, an admin console — built on the assumption that the caller is a trusted internal service or a logged-in employee. The fastest way to make those systems "agent-readable" is also the worst: hand the agent a powerful credential and let it loose. That's how you get an agent that can technically do anything any employee can do, with none of the judgment and all of the speed.
The right move is to expose capabilities, not systems. Instead of "here's write access to the customer table," you publish a narrow, intentional operation: "update this specific field on this record, subject to these validation rules, returning this receipt." Each capability gets its own identity, its own scopes, its own rate limits, and ideally its own idempotency guarantees so a retrying agent can't fire the same destructive action three times. This is just good API design and least privilege — concepts every platform team already knows. The shift is treating the agent as a first-class, distrusted caller and designing the smallest possible interface it needs to be useful. If a capability is irreversible — moving money, deleting data, changing entitlements — it shouldn't be a single autonomous call at all. It should require a second signal: a human approval, a co-sign from another service, a hold-and-confirm. You're not blocking the productivity. You're deciding, deliberately, where the loop has to slow down.
An MCP gateway with policy and audit by default
The protocols for connecting models to tools are maturing fast — the Model Context Protocol is becoming the lingua franca for exposing capabilities to agents. That's good. But a protocol is a contract for how things connect, not a control plane for what they're allowed to do. If every team stands up its own MCP server and every agent connects directly, you've rebuilt the same shadow-integration sprawl we spent a decade cleaning up, except now the integrations act on their own.
So you put a gateway in the middle, and you make it the only path. Every agent-to-tool call routes through it, and the gateway does what gateways do well: authenticate the calling identity, authorize against policy, enforce rate and cost limits, and — this is the part people skip — log everything by default. Not opt-in audit. Audit you'd have to actively work to turn off. Every action an agent takes, every tool it invoked, every argument it passed, every result it got back, tied to a stable identity and a request lineage you can replay. In a regulated environment — and serving 1,500+ financial institutions is about as regulated as it gets — "we let an agent do it but we can't tell you what it did" is not an answer you ever want to give an examiner, a partner's due-diligence team, or your own incident responders at 2 a.m.
The gateway is also where you centralize the controls that are genuinely new to this era: prompt-injection defenses, output filtering, detection of an agent suddenly behaving outside its established pattern. You do not want forty teams each inventing their own injection mitigation. You want one chokepoint that's instrumented, owned, and improved as the threats evolve. Concentrating the traffic concentrates your leverage.
An internal agent registry: you can't govern what you can't see
The third piece is the one almost nobody builds until after the incident: a registry of every agent operating in your environment. What it is, who owns it, what model backs it, which capabilities it's entitled to, what data it can see, when it was last reviewed. Treat agents as a first-class asset class — the way you (hopefully) already inventory services, data stores, and human identities.
This matters because agents proliferate quietly. One starts as a developer's experiment, gets useful, gets shared, and six months later it's load-bearing and nobody decided that on purpose. Without a registry you can't answer the questions that govern everything else: How many agents touch customer data? Which ones can move money? If a model provider has an incident, what's our exposure? When an agent is decommissioned, do we actually revoke its access — or does that capability keep working forever? The registry turns "we have some AI initiatives" into an inventory you can reason about, age out, and audit. It's the difference between a fleet and a swarm.
Build the substrate, then go shopping
None of this is exotic. Least privilege, a governed gateway, an asset inventory with audit by default — this is the platform engineering and security playbook we already know, pointed at a new kind of caller. What's new is the urgency and the consequence: the caller acts on its own, at speed, and the cost of getting the controls wrong scales with exactly the productivity you're chasing.
So here's the challenge. Before you sign the next agent contract, ask your platform and security leaders one question: if we gave this thing real access, could we scope what it touches, see everything it does, and pull it back in minutes? If the honest answer is no, you don't have an agent problem — you have a substrate problem, and another subscription won't fix it. Make your enterprise agent-readable first. Then the agents become what they should have been all along: cheap, swappable, and safe to be excited about.
