The short version
- An AI agent that acts on Kafka needs its own identity, with only the permissions it needs, not a person's account.
- Permission rules belong outside the model. A poisoned message can talk a model into almost anything, so enforcement sits in the platform and the sandbox.
- Reads can run on their own. Reversible actions run within limits. Anything that can't be undone becomes a proposal that a named person approves.
- Keep an audit record under the agent's identity, rehearse the switch that cuts it off, and mask sensitive fields per identity before they leave the platform.
- Six controls cover this, each standing on the one below. The checklist later in this post sets out where to start.
This post is for engineering managers running agents against production data, and for security, risk and audit teams deciding what an agent should be allowed to do. It draws on a talk at Current San Francisco 2026, "Least Privilege for Non-Human Identities: Governing an Autonomous Kafka SRE Agent". The examples use Kafka, but the controls apply to any system an agent can change.
My first Kafka Summit was in San Francisco in 2018, at Pier 27. Back then I ran Kafka operations at a health tech company in London, and I saw incidents from both sides of the on-call rota. Last week I was back in San Francisco, this time at Moscone West, presenting at Current for the first time.
Last month, at Data Streaming Summit, I showed an autonomous SRE agent that takes a Kafka incident from the page to the pull request that caused it. At Current I covered the part I skipped: what that agent should be allowed to do on its own.
We keep coming back to this agent for a reason. This year, when our customers talk about giving AI agents access to Kafka, incident management and SRE is the use case they ask us about first.
Suggesting a fix is the easy part
The incident runs on a simulated bank on a real Kafka cluster. Every time someone taps a card, a payment gateway writes an authorization to a topic, and a fraud service decides whether to approve or decline it. That fraud check sits on the path of every payment.
Then another team changed the schema of those messages and switched off the compatibility check that would have stopped them. The fraud service could not read the new messages, so it stopped. Payments kept arriving behind it, each one waiting on a decision that wasn't coming. That is consumer lag, and it is what paged us.
The agent picked up the page and worked it the way a good on-call engineer would. It pulled the fraud service's runbook from the owning team's Confluence space. Then it checked the consumer through Lenses, saw that new messages were still arriving, found the pull request upstream and wrote up the cause. Its advice was to revert the change and not to reset offsets. It got there in minutes, for less than a dollar.
That's all it did, really: root cause analysis. The incident wasn't over. The fraud service was still stuck, and getting payments moving again waited on a person. That gap is what this post is about.
Acting on Kafka means things you can't undo
That runbook, the one the agent read during triage, had a "last resort" answer for a stuck consumer: reset its offsets to latest. On paper, that gets the fraud service moving again. In practice, it jumps past every payment in the queue, and none of them ever gets a fraud check. That can't be taken back.
That makes a Kafka SRE agent close to a worst case. It reads private data, it takes in text nobody controls, and it can send things out, the combination Simon Willison calls the lethal trifecta. On top of that, ours can access the Kafka cluster, where it can edit configs or delete data.
Meta's Agents Rule of Two gives a practical answer. A session should hold at most two of the three, and when a task needs all three, a person approves it. We apply that as three tiers. Reads run on their own, reversible actions run within limits, and anything that can't be undone becomes a proposal.
The harder question is who enforces those tiers. It can't be the model, because one poisoned log line can talk it into anything. It can't be the harness, the agent's own code, because a compromised agent takes its code with it. It has to be the permission layer outside the agent, so that even a fully compromised agent can't do catastrophic damage.
Six controls, none of them in the model
We wanted the agent to act, but only within limits it can't talk its way out of, so we put six controls around it, all of them outside the model. For each one, I went back over the agent I'd shown and asked one question about it. Each control stands on the one below.
1. Give the agent its own identity. In the first run, the agent acknowledged the page with my PagerDuty account, so the record said I did it. Now it has its own service account in Lenses, with only the permissions it needs. The MCP specification also has a way for it to sign in without borrowing a person, the OAuth client credentials extension.
2. Keep a record it didn't write. Everything we read about that first run was written by the agent, about itself. If it was wrong, or lying, we had no way to tell. Now Lenses keeps the audit log under the agent's own name. One rehearsed switch cuts the agent off in under a second, and the engineer fixing the incident keeps working.
3. Gate what you can't undo. The agent can still ask for an offset reset, but it can only propose one. A separate service previews the change against Kafka itself. A named person approves it, and a separate executor runs it with an identity the agent never holds. In our incident, the approved reset skipped only the few messages the fraud service couldn't read.
One Kafka detail makes this matter. A reset is just an offset commit, and Kafka authorizes it with the same Read permission a normal consumer has on its group and topic. An agent you think of as read-only can still rewind a consumer.
4. Treat everything it reads as data. Anyone who can produce to a topic can write to the agent's prompt, which puts prompt injection on the Kafka attack surface. We label everything the agent reads as data. That helps, but it is not a wall. The control below it is what holds, because an injected instruction can only produce a proposal, and the preview shows a person what it would really do.
5. Give it one door. The agent runs in a sandbox, Strands Box, whose only door leads to Lenses. Every request it makes is checked against a policy written in Dogwood, and anything not explicitly allowed is refused. It can't reach a broker directly, and it cannot restart a connector it has not looked at recently. That second rule needs a memory, which no role or firewall has.
6. Mask in the platform. An agent copies what it reads into everything it writes, from model traces to Slack threads and incident reports. So sensitive fields are masked by a Lenses data policy for the agent's identity, before they leave the platform. Nobody has to remember to redact a report.
Put together, the controls sit in the platform, in the sandbox, or with a person. None of them lives in the model.
Platform-specific and general practice
Identity, audit and masking depend on platform features: service accounts, audit logs and data policies in Lenses. The sandbox and its policy rules are implemented here with Strands Box and Dogwood, but the principle works with other tooling. The tiers, the approval gate, treating input as data, and the poison-message tests described in the checklist are practice you can apply on any platform.
What this means for your team
For engineering managers
The on-call questions are the ones you already ask: who did what, can we stop it quickly, and who signed off on the change. The approval step adds one human decision for anything irreversible. In the run described here, the only step that waited on a person was the offset reset: one approval request, with a preview from Kafka of exactly what it would skip.
For financial services and risk teams
Several controls map to terms your risk and audit teams already use. Separation of duties: the agent proposes, a named person approves, and a separate executor runs the change under an identity the agent never holds. Audit evidence: the record is kept under the agent's own name, not written by the agent. Incident response: a revocation switch that has been rehearsed. Data minimization: sensitive fields are masked per identity before they leave the platform. Third-party and network access: one door, with every host the agent may call named.
We have not mapped these to a specific regulation or framework here.
Where to start with your own agent
If you run an agent that accesses Kafka today, these are the steps I'd take first, in the same order as the controls.
- Give it its own identity in the platform, with short-lived tokens, and never let it run as you.
Keep the record in the platform, list every
the agent holds, and rehearse the switch that revokes them. A switch you've never pulled is a hope.
- Tag every tool by what it can't undo, refuse anything untagged, and make approvals expire.
- Plant poison messages in your tests, and check that nothing they ask for ever runs.
- Remove any network path from the agent to your brokers, and name every host it may call.
- Mask sensitive fields per identity in the platform, cap what one query can return, and count every place the agent's output ends up.
Frequently asked questions
What is least privilege for a non-human identity?
It means the agent runs under its own identity, with only the permissions it needs, rather than borrowing a person's account. The OAuth client credentials extension in the MCP specification is one way for an agent to sign in without a person.
Why can't the model enforce the agent's permissions?
A single poisoned log line can talk a model into almost anything, so enforcement has to sit in a permission layer outside the model. It also has to sit outside the agent's own code, which a compromised agent takes with it.
What is the lethal trifecta?
Simon Willison's term for an agent that holds private data, reads untrusted content and can send things out. A Kafka SRE agent can do all three, and in the example here it can also access the Kafka cluster, where it can edit configs or delete data.
Does read-only Kafka access stop an agent from changing consumers?
Not necessarily. A consumer reset is just an offset commit, and Kafka authorizes it with the same Read permission a normal consumer has on its group and topic. An agent you think of as read-only can still rewind a consumer.
What should an agent be allowed to do without approval?
Reads, and reversible actions within limits. Anything that can't be undone becomes a proposal, which a named person approves before a separate executor runs it.
Try it yourself
Building an autonomous SRE Agent for Kafka incidents covers how we built and tested the agent.
To play this video, accept functional cookies in your privacy settings.
YouTube video
The talk ended on an answer to its own question. What should an AI agent be allowed to do to your Kafka cluster? Only what its own identity allows, and nothing you can't undo without a person saying yes.
Want to compare notes?
I closed the talk with a question: how far up the ladder is your agent? If you run an agent that accesses Kafka, I'd like to hear which rung you're working on, or which one you think we got wrong. You can find me on X and LinkedIn.
Sources
- Building an autonomous SRE Agent for Kafka incidents: how we built the agent I showed at Data Streaming Summit
- The lethal trifecta for AI agents: Simon Willison on private data, untrusted content and external communication in one agent
- Agents Rule of Two: Meta's rule that one session holds at most two of the three
- OAuth Client Credentials extension: the MCP extension for clients that act without a user
- OWASP Non-Human Identities Top 10: the risks behind controls 1 and 2
- OWASP LLM01: Prompt Injection: the risk behind control 4
- Lenses service accounts: how an agent gets an identity of its own in Lenses
- Strands Box: the sandbox the agent runs in
- Dogwood: the policy language behind the sandbox's rules, including rules that depend on what the agent did before
- Lenses audit logs: the record the platform keeps under the agent's identity
- Lenses data policies masking per identity, inside the platform
