Agentic AI needs governance it can't ignore

Picture this: an employee didn't file a ticket because they didn't need to. The framework was a pip install. The model was an API key, and the tools were an MCP server somebody found on GitHub last Tuesday. It took them an afternoon to go from idea to production.

Now multiply that by everyone who's figured out the same thing, and you have agent sprawl and shadow AI. That’s the reality of nearly enterprises today.

There are two ways to authorize an agent today: 

• Borrow a human's credential and the agent inherits a human's reach with none of the guardrails: the background check, managerial oversight, the quarterly access review, the badge that stops working on the last day.
• Hand it a service account or a long-lived API key, and you've applied the model built for deterministic software. This is the code that does exactly what you wrote, whether it’s wrong or not, but applies the same way every time, which is why you can audit it.

An agent is neither. It’s unpredictable like a person, capable like software, with neither the judgment to push back on a bad instruction nor the determinism to fail the same way twice. So we've been routing a genuinely new kind of participant through whichever old apparatus was closest to hand. We built agents. Nobody built HR.

Fixing the agent doesn't work

The instinct is to skip the apparatus and fix the participant instead. Rules in the system prompt. A guardrail model on the output. A permission check inside the agent's own framework. Make the agent behave, and you won't need to build anything. Except every single one of these shares a fatal property: the agent can see them. So if you truly have a malicious agent at play, it can alter, modify, or delete its own guardrails and even modify or delete the audit trail of what it just did.

Now here's the principle underneath everything we've built:

Governance must be enforced through channels the agent cannot access, modify, or circumvent.

Put simply: if the agent can see the policy, you don't have governance. You simply gave it a suggestion.

Out-of-band means out of the agent’s reach. The agent doesn't get a vote. It doesn't get to know there even was a vote.

Your security model is exactly as strong as a language model's willingness to remember and obey words under every condition, including adversarial ones. Guard models don't escape this; they just add a floor to it, so now there's a second non-deterministic, injectable system supervising the first. It's just LLMs all the way down.

An in-process check is sturdier, right up until you remember what it's checking. The policy lives in the agent's own address space, and the check only fires if the agent calls it instead of the API underneath. Agents write and run code. That’s an expectation, not a guarantee.

That's what our Agentic Data Plane was founded on, and what this latest release delivers. You can now see every agent, govern what each one reaches and returns, and (coming soon) stop any one of them cold.

{{featured-custom-resource}}

See every agent in your environment 

Agent Network View is a live graph of your agent estate. Every agent, the models it calls, the MCP servers it's connected to, the policies applied to it, and the tools it actually invoked. With runtime overlays for guardrail violations and authorization denials, and a KPI strip across the top for agents, conversations, tool calls, tokens, and spend.

This is the answer to the sprawl problem, and it's deliberately unglamorous: an inventory you didn't have to assemble by hand. Because the plane is in the path of every model call and every tool call, the topology isn't reconstructed from a survey or a registry somebody remembered to update. It's derived from traffic, so if an agent is running, it's on the graph.

Nothing here requires the agents to cooperate, or to have been built by us, or to know they're being watched. That's the point.

Govern all those agents

Here's a failure mode that should worry you, and it doesn’t involve an attacker at all. 

Your triage agent runs on your credential, because that's how this works today. It needs one Jira board, but the credential opens all fifty. A customer pasted an API key into a ticket description during a support escalation, which happens constantly. Your agent reads the ticket. Someone asks it an innocent-sounding question. It reads the key back out loud.

Nothing was hacked, and every permission check passed. The agent did exactly what it was built to do. You can't patch that, and you can't align your way out of it. The authorization was the wrong size, and the data should never have crossed the boundary in the first place.

Out-of-Band Policy Engine (OBPE) fixes both, at the MCP boundary rather than inside the agent. For any tool on any MCP server, you declare what the agent may see: mask a field, drop it, clamp an argument to a legal range. It applies server-side, in the path, on every call. The agent never sees the rule or the unmasked value, and has no surface to negotiate with. (When masking changes a field's type, OBPE rewrites the tool schema to match, so the agent gets a coherent contract instead of a type error. Governance that makes agents dumber doesn't survive contact with the people deploying them.)

Policy attaches to the MCP server rather than to individual agents, which is what makes this work at organizational scale. The team that owns a data source sets the ceiling once, for every agent that will ever connect (and can vary it by user, group, or agent) so the finance team and the summarization bot get different views of the same tool without anyone maintaining two policies. The data owner doesn't have to review every agent the company subsequently builds.

The Redpanda Agentic Data Plane also governs MCP servers we didn't write: self-managed, remote, third-party, the one your teammate vibe-coded on Tuesday.

This ships with the following:

• Attribute-based access control (ABAC). Fine-grained, attribute-driven permissions across agents, tools, and connections, and the substrate that role-and group-based models sit on. Tag data internal-only, and agents serving external users can't reach it regardless of the credential.
• Bring-your-own-agent transcripts. Your LangChain, CrewAI, ADK, or hand-rolled agent gets the same full-fidelity record as anything built in our console. No rewrite.
• AWS Bedrock Guardrails integration. Plugs straight in if you've standardized on it. To be precise: Bedrock providers today. OBPE's field-level enforcement is provider-agnostic.
• Cost attribution by team, department, and project. Spend is already visible per agent; tagging it up to the org chart is what turns "agents are expensive" into an actual ROI conversation.
• Scheduled agent runs. Cron-like, with timezone control. Not every agent needs to be awake at 3 AM.
• Command-line interface (CLI). Agents, gateways, and MCP servers from the terminal. As nature intended.

Killswitch: stop bad things from happening 

This is where it matters that agent governance is a data infrastructure problem, not a dashboard problem. Every input, output, and tool call the Agentic Data Plane sees gets written to a transcript. Not sampled or summarized. And critically, not written to a dashboard. Instead, it’s written to a log: a Kafka-compatible topic you can consume, in your own account, queryable with standard Postgres semantics.

That distinction is the whole ballgame. A dashboard is something a human reads after the fact, assuming they already knew to go looking. A log is something a program subscribes to. This means you can hang a grader off it that evaluates agent behavior continuously, in real time, against whatever you care about: policy violations, quality regressions, cost anomalies, tone. 

This system is the only thing that works on a participant that never fails the same way twice. That grader's verdicts become their own log, and a verdict stream is exactly what a kill switch needs upstream of it (if you want the switch to fire on evidence rather than on someone eventually noticing). Agents work at machine speed across every system they can reach. By the time a human notices, "contain the damage" has already become "assess the damage."

So: the agent kill switch. Cut a misbehaving agent off from the gateway and every tool it can reach, in one action. This one is coming soon. We'd rather say that plainly than shill vaporware. But it's a critical part of the story, and one we've been building towards from the start.

A switch is only as good as whatever tells it to fire, and nothing can tell it to fire without a complete record of what your agent actually did, sitting somewhere the agent cannot edit. Build the switch first and you've built a button nobody knows when to press. That must be the order. The record is already here, and the switch comes soon.

How to tell actual governance from security theater

Everyone in this category says they take governance seriously, so the phrase tells you nothing. These four questions do. (Ask them of us, too.)

1. Is it out of band? We've spent most of this piece on this one, so just the short version: if the policy lives anywhere the agent can read, modify, or route around, nothing else on this list matters. It's the first filter, and most approaches don't survive it.

2. Does it cover the whole path? Out-of-band governance is only as strong as its least-covered segment, and an agent's path has several: the model call, the tool call, the data access, the compute it runs on, and the record of all of it. An AI gateway covers one. An observability vendor covers a different one. A prompt firewall covers part of one. Any segment left uncovered is where the sprawl leaks out, and the instrumented segments won't tell you it's happening. We're in all of them, which is less a feature than a position in the topology.

3. Does it work with what you already have? You can use our agent framework and our managed MCP servers. But you don't have to. Any model provider, any framework, any client, any MCP server (including ones we've never seen) can be reached through open standards like MCP, A2A, OIDC, OAuth, OTel, OCSF, Kafka. Governance you only get for the agents you bought from one vendor isn't governance, it's just a walled garden. And the agents most likely to hurt you are precisely the ones built outside whatever platform you standardized on.

4. Does it run where your data already is? The Agentic Data Plane deploys into your own cloud account, on your own private network, fully managed by us. Bring-your-own-cloud (BYOC)is not a premium tier; it's the only way this ships. There’s no vendor-hosted version. There's a sharp reason for that: full-fidelity transcripts are the single most sensitive artifact this entire system produces. A complete record of every question every agent asked and every answer your systems returned. In your account, that's a log you own. In a vendor's SaaS, it's a second copy of your crown jewels sitting somewhere you don't control. Asking you to ship your sensitive data to a third party so it can be protected from your agents is a strange trade we don't want you to make. Our control plane never sees your data. It authors the desired state and nothing more, and it holds no standing credentials in your account. Management traffic is outbound from your network only. And the whole thing is built so that a single firewall rule severs all of our access while your data plane keeps serving. You should be able to fire your vendor mechanically, not just contractually, which is the same instinct as an agent kill switch, one layer down.

This isn't new machinery we bolted on for agents. We've been delivering infrastructure this way for years. Hundreds of BYOC clusters on AWS, Azure, and GCP, in customers' own accounts, on their own networks, under their own IAM policies. The Agentic Data Plane rides on delivery infrastructure that was already doing this at scale before agents were the reason anyone cared.

Early preview features

Now you know what’s shipped, here’s what’s coming.

• Agent kill switch. Surgical, instance-level cutoff from the gateway and all tools.
• Transcript and audit export. Managed streaming of transcripts and OCSF audit records to DataDog or your own SIEM.‍
• Audit log in OCSF format. Every governed action, in the schema your SIEM already speaks, queryable in the console. We were already OTel-compliant on transport; OCSF is the data model. (Format now, managed export soon.)‍
• Agent edit controls and versioning. Gate who can change an agent's prompt, with full configuration history. No more stomping on each other's work.‍
• More managed MCP connectors. The MCP server catalog keeps growing.

To get a first look, get in touch with our team. 

Nobody built HR for agents. So we did.

Every infrastructure shift runs the same play. We fall in love with the new capability, deploy it well past the point where we can explain what it's doing, have our “oh crap” moment, and then go build the governance layer we should have built first. Microservices begat the service mesh. Cloud migration begat the entire cloud security industry. Capability first, governance after, panic in between.

With agentic AI, we’re in the panic-in-between stage. However, the way out isn't to build perfect agents. We never required perfect humans; we just built infrastructure to manage the imperfections. Agents need that too, but with an implementation specifically built for a participant that can be hijacked through its own input, that moves faster than anyone can intervene, and that can't be allowed to see the rules that constrain it. None of which was ever true of the people the original apparatus was built for.

The agents aren't the problem. The missing layer between your agents and your data is the problem. That layer is what we built. It ships today and runs in your cloud.

Everything in this post is detailed in the Docs. If you want to skip ahead and see agentic governance in action, book a demo below.