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. That gives you useful context, but it does not tell you what access the agent should have.

Two agents can have the same function and still need very different permissions. One coding agent may only suggest changes. Another may modify repositories, trigger CI/CD workflows and deploy to production. Same category. Very different access risk. The same is true everywhere else. A productivity agent may only read documents, while another can send messages or update records. A security agent may recommend remediation, while another can isolate endpoints or change infrastructure.

Function tells you what kind of work the agent does. It does not tell you how much freedom it 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.

The final credential presented to the target should carry that delegation context with it, including the originator and the agents involved in the chain. That gives the target a blended identity to evaluate: who initiated the task, which agent is acting now and how the request got there.

The final credential still matters. The difference is that it represents the chain...not just the last actor in it.

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