The idea of an AI agent, something that does things on your behalf, but doesn’t go off the rails, is alluring. Everyone wants their own personal concierge, multiple of them if it can be helped, to manage things for them in an increasingly complex world.

But the way we talk about it is super ambiguous, and sometimes that makes a difference in how we think about building particular solutions.

What is an Agent?

It’s worth nailing down some vocabulary, but before we do, let’s go over some examples to ground the discussion.

Example: A Work Buddy

When trying to build something with someone else, or with a small team, there is a lot of communication that happens. People divide up work. Sometimes they use Scrum or Kanban or Get-Off-My-Lawnban, but whatever approach they take, they are divvying up work, communicating status and ideas, and doing things for one another. On a healthy team, anyway.

It isn’t all instructions all the time, but there is a fair amount of requesting, or prompting if you will, going on in a team like this. Can you take a look at this swim lane? Can you do a review for me? Can you help me figure out why this is failing? Can you take this while I go put out an urgent fire?

An agent can be a work buddy.

Example: A Service Desk

You are trying to just get stuff done, but somehow you got locked out of your own wiki page. You have no idea what happened, so you ping tech support. They ask a bunch of questions, they figure out what systems they need to access, and they start poking buttons you have absolutely no access to on your own. They find that they need to impersonate you to some extent so they can really understand what you are experiencing, and you give them temporary permission to do so.

An agent can be a service desk.

Example: An Independent Subordinate

You are managing a team of engineers, and you have product requirements that your product manager has worked with you to create. You can’t possibly do all of the engineering yourself, but you have a good team with a solid on-call and they can handle it. You plan with them, and you set aside time for them to deal with incoming bugs. When you hear about something that isn’t in the system, you create a report and assign it to the relevant team member, and they do what it takes to get it done. When something is ambiguous, they come back with clarifying questions, but from the time you create the ticket, you went from proactive to reactive. The baton has been passed.

An agent can be an independent subordinate.

Different Words for “Agent”

Most of the time, when people say “agent” out in the wild, they are talking about “the chat session where I ask for stuff and it happens while I wait”. That’s a very common case, perhaps the most common case. But that is shifting. Increasingly we hear about agent orchestration, the Ralph Loop, and agents that run on their own for hours or days at a time without direct supervision, without being in a live session. Given that, let’s get down to vocabulary.

There are multiple types of agent, and multiple concepts that govern how we think about and build agent capabilities.

• Agent: when used as a bare word, this is your chat session, the harness that hosts your credentials and that has an open, live session thing going. It is interruptible, and keeps you engaged while it works.
• Identity: more than the “name” of your agent, an identity is a system thing. Just like your authenticated username on your work systems, an agent’s Identity is something it can authenticate with. You know “who it is”, which helps you know what it can do.
• Permissions: this is simply what the agent is permitted to do. Can it access email? Can it see your repositories? Can it change your documentation? This is the authorization piece.
• Behavior: when someone writes agent code or a special agent prompt, this defines what it does. It isn’t an agent itself, it’s just defined Behavior.

Then there are some composite ideas:

• Capabilities: a combination of Behavior and Permissions. What can the agent actually do, and when.
• Persona: an “instantiated” Identity with certain Capabilities. You can imagine this being “the thing you assign to a ticket”.

Are these the “right way” to think about agents? I wouldn’t say that there is only one way to think about it, but having somewhat consistent vocabulary can really help, especially when the stakes are high in development scenarios.

Accountability

Whenever you start talking about assigning something to an identity of any kind, be it human, system, or agent, you have to start thinking not just about who does the work, but who is accountable for the work to be done.

If, for example, you have a workflow (like in an ETL pipeline) that pulls data, transforms it, and dumps the output somewhere, there are various bits and pieces of behavior and permissions involved. It needs permission to see the original data, it needs permissions and assigned resources to run the transformation, and it needs access to the output area to drop things in it.

And, crucially, it needs to have a person attached to it so that when things go wrong or changes are made to permissions schemes, there is someone on the other end of the email to take responsibility for it. It needs some kind of accountability.

That’s the traditional model: build a system account, run things with it, have certain permissions applied, but always have a real user attached for accountability and maintenance. That user might be an on-call rotation, but ultimately it resolves to a person.

AI introduces the personification of intent without the personification of accountability.

That matters. When people think of assigning work to an agent in their ticket system, they are usually thinking about what happens next; how does work get done, what happens when the code is written and needs review, do we really allow it to just submit a pull request directly, etc. What needs to be in the mix is also the question of who is accountable for the work, and what does accountability mean? Does it mean someone’s job is on the line? Does it mean that someone’s evening is on the line if something goes awry?

You can’t think about identity and behaviors without also thinking about accountability. I don’t have answers to these accountability questions because it will differ from mission to mission or organization to organization. But the questions have to be asked.

Agent Identity and Common Errors

There are three basic cases listed above: work buddy, service desk, and independent subordinate. The work buddy case is simultaneously the simplest and best understood. It’s the synchronous chat interface.

What do we do for the other two types? Service desks and subordinates are both pretty asynchronous ideas. You need something, you submit to a system or a co-worker or similar, and at some point in the future you ask for updates or are interrupted with news. There is no live session. Instead there’s fire-and-maybe-forget-for-a-while.

This is where the agent language and concepts really matter. A very common and utterly broken way of handling this is to assign an arbitrary identity to an agent. Arbitrary identities might be any of

• The identity of the user who created its behavior (code)
• The identity of the admin who instantiated (installed, made available) the agent
• The identity of the user who originally triggered the behavior

There are others, but these are distressingly common. The reason they are all broken and wrong is simple: they require either storing auth tokens or minting them on the fly for a user who is not present.

If anything helps to boil down AI security concerns into security fundamentals, this is it: don’t violate standard authentication and authorization protocols. Authentication implies presence. Authorization implies only a past grant of authority, somehow, sometime in the past. They are not the same, but the above examples conflate them in deep ways, and it all comes down to the need for an identity, and the fact that system accounts and AI agents can’t be “present” in the typical sense.

The rule is actually simple:

Only use a human’s direct authorization context when the human is in a live session.

Another way to state that is: only use the context you naturally have access to. If you have to store one, stop. If you have to mint one, stop.

Besides being a very dangerous way to use someone’s rights and privileges, it destroys visibility and accountability. You can truly never tell what happened if the agent looks just like a user in every logged event.

The implementation is a little trickier, but very doable.

Agent Personas in Asynchronous Settings

The service desk and independent subordinate categories have one thing in common: they are operating asynchronously. Where they differ is in whether they escalate or restrict permissions that would be tied to a requesting user. We’ll get into the difficulties there in a moment. For now let’s lump these together, leading us to ask, “What do we do when there is no live session?”

You make an app.

If some of the concepts in the agent vocabulary above feel familiar, but you can’t quite put your finger on it, that’s because you’ve seen them all before with mobile apps. You have

• App: what people think of as “the thing they’re interacting with”
• Attestation: your app was downloaded from the app store and you can trust that it is who it says it is
• Permissions: dynamically or statically assigned, at runtime or download time
• Code: defines how the app will work once its running on a device

Instantiating an app is the act of downloading it from an app store and having it live on your device. But your app, even though it came from the same place and has the same code, is not the same as mine. They are in different operating contexts. They have, in other words, distinct identities and permissions. They have distinct additional credentials for you, the user.

OAuth2 already defines apps in this way, and it’s an extremely natural mapping onto agents. A recent RFC also includes “act”, which signals delegation in ways that make sense for AI agents, which just leaves the issue of determining whether you are dealing with an agent in the first place. If you follow standard OAuth2 procedure as an app developer, you will be familiar with the setup step where you get a client secret. This is where you establish the relationship between your app and the identity provider (IDP), and that step is where the IDP can keep track of the fact that this is an app, or in our case, this is an agent. When that secret is presented, the IDP has the ability to inject the appropriate information into the rest of the auth flow.

Identity is the same as system account identity, with the same setup and controls. Admins create an account and assign it privileges, and admins don’t have to have those specific privileges, they just have to have the ability to connect those privileges to identities.

So the guidance for agent authorization is

Your agent is an OAuth2 application. Identity is a system account.

Net New AI Concerns: Whom Can I Invoke?

There is one thing that is somewhat new, and it is really just a version of unwanted permissions escalation. Where there have always been controls for what certain accounts can do, and who has issuing authority for those accounts, there is now a need to determine which agent identities a user can invoke.

That’s somewhat new. Who can you @-mention in this ticket system? Which identities can you assign to do coding work for you? When it’s humans, you can ask just about anyone to do something for you, and they will exercise judgment to determine whether they can or should. With agents, you need something more formal, and that shows up in the form of invocation permissions.

There are some new control needs there for admins and team leads. If I want to create a workflow node that triggers agent behavior by way of assigning an agent identity and letting it roll, I need to have permission to make that work assignment.

Circling Back to Behavior

Just like your mobile app identity (for, e.g., attestation) and its behavior are not really one and the same thing, and don’t necessarily have to be tightly coupled (but usually are), identity, permissions, and behavior don’t have to be pre-specified.

Here’s what I mean. Suppose your company has a “write code” agent identity. You invoke it by mentioning it or assigning it on a ticket. But what code does it write? What repositories can it pull? What boundaries does it have to stay within while doing its work? All of these will be different for each team. All you know is that it has a particular identity, with, basically privileges to do code things.

Where do you define actual behavior?

It could be stored along with the identity, making it a single-purpose assignable entity. Or, it could be something that your team defines as needed: the identity assignment is just a trigger. You define the behaviors when that trigger fires.

In this latter case, the behavior is now decoupled from the identity and general permissions. It’s one way to approach what could otherwise be a real nightmare configuration scenario for admins and ops folks. You don’t want them to have to manage the cross product of every identity, every permissions scheme, and every behavior for every agent in your organization. It’s enough for them to just manage the identities, permissions, and invocation authority. Let teams figure out what those agents actually do.

Dynamic Permissions and Unanswered Questions

There are a lot of big questions out there, and I don’t necessarily have all the answers, but let’s at least ask the questions:

• How do you follow the Principle of Least Privilege? Can you down-scope permissions easily?
• How do you allow an agent persona to take on part of an invoking user’s privileges?
• How do you do targeted, point-in-time permissions escalations? This is the “give me access for 15 minutes” question.

And finally, we have said nothing about discretion, the misbehaved twin of access. That will have to be another post.

Some of these can be naturally handled, to some extent, by a workflow orchestration mentality. That is also another post.

Unanswered Questions, but Tractably Answerable

This is just a primer, really, an articulation of where things get murky, and where they make sense, and what we can leverage that we already have. It turns out we already have a lot, we just have to get clear on the different aspects of what makes an agent an agent, and what it means to have an identity in the first place. The rest starts to fall out from there.

Agents as apps. Identities as system accounts. Behaviors as trigger responses. Invoking authority. There are some pretty fundamental things in here that can make the agent permissions and identity questions a little less daunting. You just have to do the mapping, and occasionally you need to be more linguistically crisp.

And don’t disregard the fundamentals of control, visibility, and auth.