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

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. Access is not authority

Starburst’s Jitender Aswani approaches the same problem from the data layer. A federated query engine lets an agent reach data across many systems without copying all of it into one place. But, as he puts it, “The compute engine has to work with the governance that is very much required at every enterprise.” His catalog still has to answer: where is the data, what data exists, and who has access to it?

That distinction matters because reachability is a technical capability, not a grant of authority. Connecting an agent to a federated data layer should not let it bypass the row, column, or source-level rules that already govern the person it represents. Otherwise federation makes the blast radius larger while the permission model stays vague.

Across these conversations, one rule emerges: an agent should never inherit ambient authority merely because it can reach a system. Its authority should be explicitly delegated, bounded by the user, the task, the agent’s own restrictions, and enterprise policy.

3. 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.”

4. 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.”

5. 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.”

6. Access control still leaves the action problem

Cisco President and Chief Product Officer Jeetu Patel draws the next boundary: “You can’t just do access control on the agents. You have to do action control.” His example is an agent with access to your email. Permission to use the inbox for making a dinner reservation should not also mean permission to message your board of directors.

The system and the action are different dimensions. An agent may need read access without write access, or permission to draft a message without permission to send it. The task boundary has to survive after the agent gets through the front door.

7. 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.

8. Who owns the boundary

No single guest assigns every part of this to an org chart. A workable ownership split across the four layers is:

Layer	Decision	Primary owner or owners
Governed data access	Which sources, rows, columns, and fields may be read or changed	The data owner
Task delegation	Which job this agent instance is doing, for whom, and for how long	The user and the agent or application owner
Action control	Which operations are allowed, denied, or sent for approval	Security and platform teams, with the application owner
High-stakes enforcement	Which actions require an external policy check, human signature, or hardware-backed approval	The relevant business or risk owner

The user can delegate only authority they already hold, and only inside the agent’s own ceiling. That makes the effective permission set an intersection, never a union.

Personalized harnesses do not remove that ceiling. A person can choose more autonomy when the harness touches only data and accounts they control. Once an enterprise system enters the loop, personal configuration becomes a request, not policy. The organization’s source rules, agent-level denies, and approval thresholds still win.

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.

Apply the boundary: review a fictional agent patch and decide what evidence earns a limited release.