If your agent can’t be revoked, it isn’t autonomous. It’s unattended.
That is the bit I think we are politely talking around while the “AI gateway” confetti cannon goes off in the background. And to be clear, I’m not dismissing the risk. Quite the opposite. I think the risk is real. I just don’t think slapping a shiny category label on it makes it less likely to stuff your production systems into a hedge.
The operational truth is much less magical: Agents are non-deterministic consumers hitting deterministic systems.
The agent plans. It guesses. It retries. It interprets vague human intent and turns that into a sequence of actions. That part is probabilistic, squishy, and occasionally impressively weird.
But eventually it does something very boring. It calls an API. It invokes a tool. It talks to an MCP server. It creates a ticket, sends an email, queries a database, updates a CRM record, calls a cloud API, or pokes Kubernetes with a stick.
That call path is where governance stops being a slide and starts being physics.
The market signal is forming. That doesn’t mean the category is settled.
This past week, a bunch of vendors all seemed to discover the same sentence with different logos attached to it.
Kong has been talking about securing AI agents with runtime controls, including a Noma integration described as “a hardened execution layer that governs, observes, and protects every agent interaction as it happens” in the Kong AI Gateway. A related Kong post argued that when agents call tools, you need “runtime visibility” and “policy enforcement,” not just model-level controls, and another framed a central gateway for AI context as one place for authentication, security, and observability.
MuleSoft framed the same transition slightly differently: “AI agents are moving from experimentation to production,” bringing complexity around governance, cost, and the connected AI ecosystem. In another post, they asked the important operator question (“Where did that agent come from?”) and pointed at agent discovery across platforms so teams can bring things back into inventory.
Akamai added the API-security flavor, warning: “Zombie APIs. Shadow APIs. Rogue APIs. Now meet LLM-linked APIs and GenAI-linked APIs”.
This is useful as a market signal. It tells us the narrative is forming.
It is not proof that the new category brochure has descended from the heavens, laminated and correct. It is, quite frankly Begriffsverwirrung, a.k.a: a conceptual muddle. Lovely word. Very efficient. When the Germans looked at enterprise software marketing they concluded, “we will need a noun for that.”
Translate the hype into the checklist
When I strip away the AI-gateway language, the questions I care about are brutally simple:
- Who or what made the call?
- On whose behalf?
- To which tool, API, model, or data source?
- With which permissions?
- Under which policy?
- At what rate and cost?
- What was logged?
- Who owns the thing?
- How do we stop it when it starts doing something daft?
That’s it. That’s the governance problem.
You can call the enforcement point an API gateway, AI gateway, MCP gateway, LLM gateway, agent gateway, runtime control plane, or Derek. I don’t care. The name is not the control. The controls are the control.
Authentication. Authorization. Scoped credentials. Rate limits. Quotas. Audit logs. Observability. Policy enforcement. Lifecycle ownership. Revocation. Human approval for high-risk actions. Boring things. Beautiful things. The stuff that keeps production from becoming a group therapy session.
We’ve known this in API management for years. Misbehaving clients aren’t new. Leaked keys aren’t new. Zombie APIs and shadow integrations aren’t new. What is new is that the consumer can now assemble its own plan, discover tools, and call them at machine speed while sounding very confident about it.
Confident nonsense is still nonsense. It just has better punctuation now.
MCP is useful – but it’s also a sprawl accelerator if you’re sloppy
I like the idea behind MCP. The Model Context Protocol is described by Anthropic as an open standard for connecting AI-powered tools to data sources, with developers exposing data through MCP servers and AI applications connecting as clients. The official spec talks about server-side resources, prompts, and tools – basically a way for agents to discover and invoke useful things.
Good.
Also: Yikes!
Tool discovery without inventory is just a faster way to lose track of what can touch production data. We spent a decade trying to get APIs cataloged, versioned, owned, documented, deprecated, and retired. Now we’re giving agents a convenient interface for discovering tools and pretending this won’t recreate the same mess, only with more YAML and a jaunty demo video.
The MCP spec itself doesn’t magically solve this. It explicitly says clients and servers may negotiate their own authentication and authorization strategies. MCP defines a way to connect and expose capabilities. It does not, by itself, give you enterprise-grade identity, rate limiting, audit retention, lifecycle ownership, or a kill switch. Those come from the surrounding infrastructure.
And this is where the boring people come back into the room.
Hello. We brought snacks.
Production is where weirdness stops being cute
Demos tolerate weirdness. Production does not.
In a demo, an agent sending the wrong summary to Slack is a laugh. In production, an agent issuing refunds, changing CRM records, deleting cloud resources, approving access requests, merging code, or emailing customers is not “agentic.” It’s a privileged workload making state changes.
Treat it like one.
OWASP’s GenAI guidance names Excessive Agency as a real LLM risk, with mitigations including constraining permissions and requiring human approval for high-impact actions. That maps perfectly to the operator checklist: Least privilege, approval gates for destructive mutations, monitoring, and auditability.
Cloud and platform systems already teach this lesson. AWS IAM best practices tell you to grant least privilege. Kubernetes RBAC exists to control access to Kubernetes API resources. Terraform Cloud has policy enforcement for infrastructure changes.
None of those controls become obsolete because the caller now has a chat interface. If anything, they matter more.
Revocation isn’t magic; it’s still mandatory
A small but important caveat: revocation isn’t a time machine.
If an agent has already sent the payment, deleted the record, or triggered the deployment, revoking its token won’t undo that. Revocation mostly prevents future calls. Stopping an in-flight workflow may require cancelling the job, killing the process, expiring the session, blocking the queue, or relying on downstream rollback logic.
This is why the control stack has to be layered.
The gateway or traffic layer can identify the caller, enforce coarse policy, throttle traffic, and record what happened. IAM and RBAC constrain what credentials can do. Application logic decides whether this particular user or agent can refund this particular customer. Policy-as-code can stop unsafe infrastructure changes. Monitoring and incident response catch the bits you missed.
One layer won’t save you. Multiple layers make failure less theatrical.
Also, log carefully. Agent prompts and tool payloads can contain sensitive data. Auditability doesn’t mean dumping every prompt and response into a plaintext bucket. Log agent ID, tool called, time, outcome, cost, and policy decision. Mask or avoid sensitive payloads unless you have a very good reason and proper access controls.
Future-you, during an incident review, will either thank you or develop a facial tic.
The leadership test
Before approving a production agent, I would ask for this, in writing:
- Inventory: Where is the agent registered, and which team owns it?
- Identity: What credential does it use, and can we distinguish it from the human or service it acts on behalf of?
- Delegation: If it acts for a user, how is that user context carried and limited?
- Least privilege: What is the smallest set of tools and APIs it can call?
- Policy: Which calls are blocked, allowed, or require approval?
- Rate limits and budgets: How do we stop runaway loops, cost spikes, and accidental floods?
- Observability: Can we see tool usage, errors, latency, and anomalies per agent?
- Audit: What is retained, for how long, and with what privacy safeguards?
- Human approval: Which actions need a person in the loop – payments, deletes, access grants, production changes?
- Lifecycle: Who reviews it, rotates credentials, deprecates tools, and retires stale agents?
- Revocation: What exactly do we disable when it misbehaves, and how fast?
- Incident runbook: Who gets paged when the agent goes feral?
That is how autonomy survives contact with production.
So yes, maybe “AI gateway” becomes a useful label for a bundle of runtime controls. Fine. I can live with the label if the work underneath is real. The mistake is believing the label is the solution.
Agents won’t fail only because models hallucinate. They will fail because someone gave an unattended process too much access, too little scope, no audit trail, and no off switch.
And then we will all gather in a post-incident meeting and pretend this was surprising.
It won’t be.
