Understanding agent identities

There is a lot of confusion right now about how to define an AI agent. Some people start with how the agent is triggered: is a person using it directly or is it running in the background? Others focus on how the work gets done: is the agent executing a defined task or working toward a broader goal and deciding how to get there?

Security teams tend to ask a different set of questions. What can the agent access? What can it change? Whose permissions is it using? Can it call other agents? What happens if the task changes along the way?

These are not competing ways to classify agents. They are different parts of the same profile, and that matters because two agents that look similar on the surface can create completely different access risks.

A coding agent that drafts code in a sandbox is very different from one that can modify multiple repositories, trigger CI/CD workflows and deploy to production. A support agent that summarizes a ticket is different from one that can change customer information, issue a refund or retrieve financial records. The job may be the same, but the risk is not.

That is why broad labels such as “coding agent,” “support agent” or even “autonomous agent” only get us so far. The more useful question is: What is this agent’s complete profile?

That profile tells us what the agent does, how independently it operates, whose authority it uses, what it can reach, what it can change and how far the work can extend once it begins. Those are the things that should determine the permissions, policies and controls around it.

An agent profile is not one field in an inventory. It is the combination of several characteristics, and none of them tells the whole story on its own. The risk becomes clearer when you look at them together.

The combination of these dimensions is what creates the actual risk profile. Two agents may have the same function but differ completely in how they operate, what they can reach and how much freedom they have once work begins.

The easiest way to classify an agent is by the job it performs. There are coding agents, productivity agents, business process agents, data agents, security operations agents and customer-facing agents. These categories give us basic context about what the agent is there to do.

A coding agent drafts or reviews code. A productivity agent helps someone research, summarize or create content. A business process agent may work inside finance, HR, sales or customer support. But function tells us surprisingly little about the access an agent should have.

Two coding agents may serve the same general purpose and still need very different permissions. One may suggest changes while a developer remains fully in control. Another may receive an objective, decide which repositories need to change, create branches, open pull requests and invoke deployment workflows. They are both coding agents, but from an access perspective they are not remotely the same thing.

The same pattern shows up everywhere else. A productivity agent may only read documents, while another may be able to send messages, update records and schedule meetings. A security agent may recommend remediation, while another may isolate endpoints or change infrastructure.

Function tells us what kind of work is happening. It does not tell us how much freedom the agent should have while doing it.

People often describe an agent as either human-assisted or autonomous, but that collapses several different operating models into one label. What we call autonomy is really the result of two things working together: how the agent is asked to work and how the work gets started.

Trigger type

The other half of autonomy is how the work begins. A user-initiated agent starts because a person asks it to do something. An automatically triggered agent starts because a schedule fires, a system event occurs or a job kicks off. An agent-initiated process begins because another agent handed off work.

That distinction matters because a human being somewhere in the broader process does not automatically make the agent low risk. An agent can still inspect systems, retrieve data or call tools before the next approval point ever appears.

These are useful shorthand for describing common patterns, but they should be understood as profiles rather than rigid product categories.

The important question is not simply whether a human is involved. It is where that human is involved, what the agent can do outside of those checkpoints and whether the controls match the risk of the action being taken.

Autonomy can also change over time. An agent may begin as a co-pilot and become more independent as the organization gets more comfortable with it. The same agent may even operate differently for different jobs. That is why access cannot be based solely on how the agent was originally classified. The control model has to reflect what is happening now.

If security evaluates only the credential presented at the end of that chain, it loses the context that explains how the action started. Who initiated the work? Which agent made the decision? Was the action still part of the original task? Did the work pass through another agent? Which permissions were used and which policies were evaluated?

That context matters for authorization and for accountability afterward. This is why treating the user and agent as completely separate identities is not enough. The more useful model is a blended view that considers the originator, the agent, the purpose of the request, the permissions available to each and the environment in which the action is taking place.

The final credential is still important. It just is not the whole story.

A lot of agent security discussion starts with sensitive data, and understandably so. Agents may reach customer records, source code, financial information, employee data or intellectual property.

But data sensitivity is only one side of the risk. An agent may access information that is not especially sensitive and still be able to take a very consequential action. It could change an IAM policy, delete infrastructure, deploy software, approve a transaction or communicate externally.

The better way to think about exposure is across three areas:

Scope has a multiplying effect on risk. A narrowly bounded agent with temporary access to one system is easier to understand and govern than a persistent agent that can reach many systems, call tools and delegate work.

Delegation deserves special attention because once an agent hands work to another agent, that second agent may have different permissions, different tools and a different understanding of the job. If the chain continues, the original task can become increasingly distant from the final action.

That does not make multi-agent systems inherently unsafe. It means the security model has to follow the work. Policy should not disappear simply because one agent handed the task to another.

The clearest way to see why profiles matter is to compare two agents that share the same functional label:

Both are support agents. But that label tells a security team almost nothing about the controls each one needs.

The same applies to coding agents. One may work on a single developer-created branch with no production access, while another may work across repositories, invoke build systems and deploy changes during an approved window.

Calling both of them coding agents hides the part that matters. Their profiles reveal it.

Creating an inventory of agents is a good place to start, but an inventory that simply lists names and owners will not tell you much about access risk. For each agent, organizations need enough information to understand how the agent actually behaves and what controls should apply.

Once those questions are answered, the control requirements become much more concrete. Organizations can decide whether the agent needs standing access at all, where just-in-time access makes more sense, which actions require approval and which systems or resources should remain out of bounds.

They can also change permissions based on the current task or context rather than assuming the same access is appropriate every time the agent runs. And they can preserve enough evidence to explain what happened afterward.

This approach is not tied to one agent platform, model provider or protocol. Those technologies will keep changing. The underlying questions about identity, authority, purpose, scope and accountability will not.

Understanding the profile is the first step. The next step is using that profile to determine what should happen while the agent is actually working.

An agent may be authorized to perform one action and not the next. It may be allowed to read a resource but not modify it. A user may be permitted to request a task without every downstream action automatically inheriting that permission.

That is why runtime control matters. Access decisions have to follow what the agent is actually doing, not just what was assigned earlier.

The industry is still early. Terminology is inconsistent, standards are developing and new agent architectures are appearing faster than most security models can adapt. That makes broad labels tempting, but those labels become less useful as soon as you have to make an access decision.

“Autonomous agent” sounds specific until you have to decide exactly what the agent should be allowed to do. “Coding agent” sounds useful until two coding agents need entirely different permissions.

The better question is not simply, “What type of agent is this?”

It is: “What is this agent’s complete profile, and what should it be allowed to do right now?”

That forces us to look at the full system: the identity, the task, the agent, the permissions, the systems, the actions, the delegation chain and the context around them.

There is complexity there. The answer is not to simplify it away with broader labels. The answer is to make enough of that complexity visible that we can govern it.