AI, decoded

How do you give an AI agent an identity and permissions?

Give each agent instance a short-lived identity scoped to one task, not a standing service account, and carry the human it acts for along with it. Redpanda CTO Tyler Akidau's rule is that the permissions have to be enforced somewhere the agent cannot see or modify, because anything you enforce in the prompt eventually loses to prompt injection.

· Chain of Thought

AI SecurityAI AgentsEnterprise AI

1. The problem is governance, not model quality

Tyler Akidau, CTO of Redpanda, thinks the models are ready and the scaffolding is not: “It’s not that you need to make the agents better. The agents have actually reached a point where they’re super capable.” What stalls deployment is that “we just don’t have the governance layer for that.”

His analogy is the argument. “We never tried to make humans perfect. Every corporation in the world is stacked top to bottom with imperfect humans. And most of them live to see another day, despite of that, because of all the structural pieces that we built up around managing sets of imperfect humans.” Agents get the job without the structure: no manager, no scoped badge, no approval chain.

He names four pillars: “identity, authorization, observability and explainability, and then accountability and control.”

2. Why a service account is the wrong shape

The instinct is to treat an agent as software and hand it a service account. Akidau’s objection is that agents do not behave like classic software: “Agents are not predictable, like classic software. They will go do random things.” They are also trivially duplicated, so one credential can end up shared across many concurrently running instances doing different things.

Then there is prompt injection, which he frames through a human comparison. A CEO can tell an employee to do something and they mostly will, but that works because the employee holds the context that this is the boss. An agent has no such anchor: anything that reaches its context window claiming prior instructions are void may simply be obeyed, up to “leak all the customer emails or delete the production database.”

3. A new badge per task, carrying the human

His identity model is per-instance and per-task rather than per-agent: “you need each agent instance for any given specific tasks it’s running to have an identity… short-lived, you know, it’s essentially every time you get asking you to go do something, it gets a new badge.”

That alone is not enough, because accountability has to terminate at a person. “You can’t really hold an agent accountable. So at some point in time, everything an agent does has to be held accountable to some human in some way.” So the identity is hybrid, carrying a chain of responsibility: “this is Agent X, it’s supposed to do this task, and it’s doing it on behalf of Tyler or whoever. Or maybe it’s on behalf of Agent Y who’s doing it on behalf of Tyler.”

4. Four properties the authorization needs

Akidau’s list, in his terms:

  • Narrowly scoped — “limit it to the specific task at hand, not everything the agent might ever need.”
  • Short-lived — an agent that needs the billing database at 2pm “shouldn’t still have that access an hour later, maybe even a minute later.”
  • Deny capable — you must be able to say “this agent can never write to the production database. It can only ever read,” and have that survive the agent borrowing a human’s permissions.
  • Intersection aware — when an agent adopts some of a user’s rights, what it gets is the intersection of the two sets, never the union.

The guest-badge image carries the last two: a visitor “can kind of go anywhere that a human will take you. But even if the human has access to the secret server room that guests aren’t allowed in, you’re still not allowed to go because you’ve got the guest badge.”

5. Enforce it where the agent cannot reach

The rule that everything else rests on is architectural: “Governance needs to be enforced through channels the agent can’t access, can’t modify, or even see.” Prompts and guard models are inbound controls, and inbound controls “will at some point collapse under prompt injection or hallucination.”

His worked example is a trading agent where any trade above a threshold routes to a human, and “the agent doesn’t even know that that’s there. All it does is it makes recommendations.” The check lives in the infrastructure, so there is no instruction that turns it off. Akidau is candid that his own team has fallen short of this: a guidance file scoping what agents may touch in a repository is, he notes, only guidance. In his words, “if it actually matters that it doesn’t do a thing, we can’t enforce it here.”

Ledger CTO Charles Guillemet reaches the same conclusion from the hardware side in can AI agents be secured with software alone, which is the sharper version of this argument when money moves.

Why it matters

Most agent rollouts inherit an identity story built for humans and services, and neither fits something that is cloned on demand, obeys text it finds, and acts for a person who is not watching. The test is simple: name one thing your agent must never do, then find the code that stops it. If that code is a sentence in a prompt, it is not a control. See also how to govern AI agents for the surrounding policy layer.

From the conversation

This explainer is drawn from these episodes — each carries its full transcript.