Revisited July 2026. First published in 2025. Rewritten to match how Conduktor governs AI access today, across Console, Gateway, CLI, and MCP.
AI has stopped waiting for a nightly export. Agents now read and write live operational data directly, through MCP servers, RAG pipelines, and agentic workflows that query systems while they run. The model is no longer downstream of your data. It is a client of it.
That shift moves the governance question. It was never really about the model. It is about access: which system did the agent touch, under which policy, and is there a record. For a human on a keyboard, most enterprises can answer that. For an agent acting a few hundred times a minute (with nobody watching each call), most cannot.
This is the same story the industry keeps repeating. A capability arrives faster than the controls around it, teams wire it into production to keep up, and governance gets bolted on after something goes wrong. AI governance only works if it sits where agents actually touch the data, not in a dashboard reconstructed after the fact.
Four questions you can't answer yet
Connect an agent to operational data and four questions surface immediately. Most teams cannot answer them today:
- Which agents accessed which datasets? Not which service account, which agent, and on whose behalf.
- What did each decision run on? Which records fed the action the agent took.
- Were policies enforced in the moment? Masking, access rules, and data-quality checks applied at the point of access, not audited weeks later.
- How would you catch unintended behavior? An agent reading a topic it should never see, and someone noticing before it matters.
Customers are already asking for exactly this level of granularity, and not only for AI:
"We want to go into the lowest fine grain in terms of who's using the data, how are they using it." — Technology executive, data and security, at a US health insurer
That is a who-accessed-what audit requirement stated plainly. Agents raise the stakes because they generate that access pattern continuously, without a person in the loop to remember what happened.
Why governance has to live at the data layer
The instinct is to govern the agent: wrap the model, log its prompts, review its tool calls. That catches intent, not access. The moment an agent issues a real read or write against operational data, the model boundary is behind it, and whatever it touches is governed by whatever sits on the data path. If nothing does, the access is unrecorded and unrestricted.
So what sits on that path?
Put a control layer on that path and the same access becomes governable. Every read and write passes through one point that enforces policy on the payload and writes a record as it happens.
How Conduktor governs AI access
We didn't build a separate AI product, and there is nothing in preview here. AI inherits the governance Conduktor already enforces for people, through the products platform teams already run.
- MCP is read-only, and it lives inside Console (no separate deployment). Connect Claude Code, Cursor, or any MCP client to your Console instance for safe exploration. Kafka metadata is processed locally and never leaves your network. Access uses Console personal access tokens that inherit the user's RBAC, checked on every request. Turn it off entirely with
enable_mcp: false. - The CLI and Skills are where agents act. MCP explores; when it is time to change Kafka, the governed CLI surface handles it. Exploration and mutation are deliberately different doors.
- Every AI, MCP, and CLI action inherits the human's exact permissions. Read-only versus read-write is decided per cluster and per team. An agent works inside the access model you already trust, not a parallel one built for machines.
- Gateway enforces on the wire. Every produce and consume passes through the proxy, where encryption, field-level masking, and data-quality rules apply to the payload itself. The audit record is written at the proxy, at the point of action, rather than reconstructed from logs afterward.
One honest caveat. Gateway is an inline proxy: real infrastructure on the critical path, with the availability and latency trade-offs that implies. And "nothing to bypass" holds only when clients are locked to the Gateway. It is an enforcement point, not a magic wand.
Together, those pieces are the two halves of the same idea. Conduktor holds the context (ownership, schemas, lineage, policies) so the model works from what is real, and holds the permissions so it can only do what the person behind it is allowed to do. The agent doesn't get its own trust boundary. It borrows yours.
"Smarter AI because you hold the context, safer AI because you hold the permissions."
The difference is where the control sits
Most platforms answer AI governance with the same table stakes everyone ships: RBAC, schema validation, encryption at rest. Useful, and not the differentiator.
The difference is where the control lives. Because Gateway is a proxy on the Kafka wire, every read and write an agent makes crosses one enforcement point, and masking, encryption, and data-quality run against the payload itself. Because MCP and the CLI run inside Console's permission model, the agent inherits the exact RBAC of the person who invoked it: read-only to look, a governed surface to act. The audit trail is a byproduct of that access happening, not a report someone assembles later.
Most teams are still working that out:
"All this AI stuff right now is wild west... these customers are asking how they're going to implement AI into the organization, but they don't really know how." — Solutions engineer at a data-platform partner
Nobody has a finished playbook (we don't pretend to either). The teams that move fastest are the ones that make the access governable first, then let the agents loose on it, rather than the other way around.
Ship the agent, keep the audit trail
Baking governance into the data path instead of around the model changes what a launch looks like. Policy violations get caught at access time, the audit answer already exists when security or compliance asks, and the same access model covers the human and the agent. That is what lets a team ship an agent against production data and still answer for what it did.
If you are mapping your enterprise AI roadmap against these access and audit questions, we would like to hear where you are stuck.