AI agents need identity and access limits

For a long time, when we talked about digital identity inside companies, the question seemed relatively familiar: who is the user trying to access a given system, and what are they authorized to do?

Then came applications, APIs, services, workloads, and other non-human identities. Now, artificial intelligence agents add a new dimension to the problem.

An agent can query documents, access databases, use tools, call an API, open a ticket, trigger another system, or even ask another agent to act. Depending on the level of autonomy it receives, it can also execute actions that used to depend directly on a person.

When that happens, knowing only who the user is that started the process is no longer enough.

We need to know who the agent is, on whose behalf it is acting, which resources it can access, which actions it is authorized to execute, and how to reconstruct afterward what it actually did.

The question looks technical, but it quickly turns into a governance question.

An agent that acts also needs an identity

This discussion is already appearing quite concretely in security and identity initiatives.

In 2026, the National Institute of Standards and Technology (NIST), the U.S. body responsible for developing technical standards and references, through the National Cybersecurity Center of Excellence (NCCoE), the NIST center focused on the practical application of cybersecurity technologies and standards, published a concept paper dedicated specifically to the identity and authorization of software and artificial intelligence agents [1].

The starting point is quite straightforward: as agents access different sets of data, tools, and applications to fulfill their tasks, organizations need to understand how well-known principles of identification, authentication, and authorization can be applied to them [1].

The difference between these concepts matters.

Identification answers who the agent is. Authentication seeks to confirm that it really is who it claims to be. Authorization determines what that agent can do once its identity has been recognized.

Giving autonomy to an agent without clearly knowing who it is and what it is authorized to do creates a new privileged identity without the controls we have already learned to demand of people and systems.

This discussion also helps correct a common simplification. An agent should not be treated merely as an invisible extension of the application that runs it. As it receives responsibilities of its own, its identity also becomes relevant for controlling and auditing what happens.

The agent’s identity is not necessarily the user’s identity

One of the most interesting problems arises when an agent performs a task on someone’s behalf.

Imagine an agent authorized to query corporate documents to prepare an analysis. The user who requested the task has certain permissions, but the agent also needs to identify itself to the systems it will access.

These are two different questions: who is the agent? and on whose behalf is it acting?

Google Cloud’s documentation on Agent Identity shows how this distinction is already reaching implementations. The service assigns each agent its own cryptographic identity and lets it authenticate to resources, tools, and other agents, acting both on its own behalf and on behalf of a user [2].

This matters because sharing the same identity among different agents reduces the ability to know which one actually performed a given action. An individual identity makes it possible to apply specific policies and build a more precise trail of each agent’s behavior.

NIST’s own document explicitly addresses delegation of authority in situations where the agent acts on behalf of someone, and it also asks how to link the agent’s identity to the human identity when there is authorization with a person involved [1].

Knowing who started a task is not enough when another participant, with its own identity and capacity to act, starts executing it.

This distinction tends to become especially important in processes where different agents work for different users, departments, or customers using the same corporate systems.

Identity without authorization solves only half the problem

Recognizing the agent is only the first step. After that comes a harder question: what can it do?

An agent responsible for analyzing incidents may need to query alarms, topology, inventory, and recent changes. That does not mean it should also have permanent permission to change configurations, restart services, or access any information available in the environment.

This is where the least privilege principle becomes particularly relevant: each identity should receive only the access needed to perform its function.

NIST’s document places exactly this question among the authorization challenges for agents: how do you establish least privilege when the actions needed may not be fully predictable before execution? The same document also discusses dynamic authorization when the agent’s context changes, and delegation of authority in scenarios where it acts on behalf of another identity [1].

The Blueprint Alliance, a multivendor initiative announced in September 2026 by identity, cloud, data, application, and cybersecurity companies, follows a similar direction. Among its principles are treating each agent as its own identity, limiting access to the task instead of keeping permanent privileges, and preserving the traceability of delegation when agents create subagents or act on behalf of people [3].

This change matters because agents can operate far more dynamically than traditional applications.

The right access may depend on the task, the user being represented, the resource requested, the context of the operation, and even the moment the action is being executed.

In agentic environments, the question stops being just “does this agent have access?” and becomes “should this agent have this access, for this task, at this moment and in this context?”

That brings identity closer to context and turns authorization into a potentially more dynamic decision.

When one agent calls another, the chain of responsibility cannot disappear

Complexity increases again in multi-agent environments.

An agent can receive a task and delegate part of it to another agent, which queries a tool, accesses a service, and returns a result. Depending on the architecture, that sequence can continue for several steps.

If an inappropriate action occurs at the end of that chain, it will be necessary to reconstruct not only which agent executed it, but also where the authorization came from, who delegated the task, and how it reached that agent.

The Blueprint Alliance lists end-to-end traceable delegation among its principles for agentic environments [3]. NIST also treats delegation, the link between human identities and agents, and the logging of actions among the elements needed to build this traceability [1].

In this context the concept of non-repudiation also appears. It is used in security to ensure there is evidence that allows an action to be associated with the identity that performed it, preventing its authorship from later being denied or left without clear attribution.

This capability will matter not only for security, but also for auditing, incident investigation, and operational responsibility. If several agents took part in a workflow, we need to be able to reconstruct the complete chain: who received the task, who delegated, who accessed a given piece of data, who made a given decision, and who finally executed the action.

The greater the autonomy and collaboration among agents, the more important it will be to preserve the chain of responsibility for what they do.

Before controlling agents, you need to know they exist

There is also a problem that comes before authorization itself.

An organization may not have full visibility into all the agents that start to appear in its environment.

Teams can create agents internally, vendors can embed agents in their applications, and users can start using services that introduce new identities and integrations without going through the same traditional governance processes.

Palo Alto Networks draws attention to the need for continuous discovery, inventory, and classification of agents, including so-called shadow agents, agents that appear or operate outside the organization’s visibility and formal controls [4].

The Blueprint Alliance also includes discovery and cataloging among the first elements of its architecture and proposes that each agent be registered as a distinct identity, tied to a human owner or operating team [3].

This point brings the discussion closer to the broader problem of Shadow AI, the use of artificial intelligence resources outside the company’s formal mechanisms of awareness and governance.

You cannot govern the identity, access, or behavior of an agent whose existence the organization does not know about.

As creating agents becomes easier, inventory and ownership stop being secondary administrative tasks and become part of the security of the operation itself.

Identity also needs to follow the lifecycle

People join, change roles, and leave organizations. Systems are created, modified, and decommissioned. Agents will also have a lifecycle.

An agent can change version, receive new tools, start serving another process, or stop being needed. Permissions that made sense in a given role can become excessive after a change.

That is why identity cannot be treated only at the moment the agent is created.

The architecture proposed by the Blueprint Alliance itself ties agent governance to access reviews, separation of duties, and joiner, mover, and leaver discipline applied to the scope, owner, and versions of agents [3].

This means management will need to keep answering seemingly simple questions: does this agent still exist? Does it still perform the same function? Is its owner still the same? Are the permissions still appropriate? Are the resources it has access to still needed?

In environments with few agents, this may be manageable by hand. As the number of agents and workflows grows, it tends to become an operational problem.

This is the point where identity starts to connect directly with AgentOps.

Identity, observability, and AgentOps start to converge

In the previous articles in this series, we discussed that putting agents into production requires an operational discipline capable of tracking their lifecycle, behavior, costs, results, and reliability. We also saw that observability starts to include what agents do during their executions.

Identity adds another layer to this architecture.

A trace can show that a tool was called. Identity lets you know which agent made the call. Authorization helps answer why it had permission to make it. Delegation lets you reconstruct on whose behalf, or on behalf of which other agent, that action occurred.

These dimensions do not replace one another. They complement each other.

The Blueprint Alliance itself organizes its proposal around questions that connect discovery, identity, authorization, runtime monitoring, and response [3]. Google Cloud’s documentation also combines agent identity with gateway mechanisms and access policies for the resources used during execution [2].

As agents gain autonomy, therefore, identity stops being only a security concern and becomes part of the very ability to operate these systems.

Governing agents will require connecting who they are, what they can do, what they actually did, and what result they produced.

This may be one of the most important changes compared with the machine identities we already know. We are not just authenticating a technical component that performs a predefined function. We are starting to assign identity to systems capable of interpreting context, choosing paths, and carrying out actions with growing degrees of autonomy.

From vision to practice: ARGUS

As AI agents receive access to corporate applications, tools, and information, identity and authorization become part of a broader operational challenge. It is not enough to know which permissions were granted. You also need to understand how they are used while tasks run.

ARGUS addresses this dimension through its AgentOps and AI Gateway capabilities, which let you relate agent activity to the applicable policies, the resources used, and the information available about their executions.

The proposal is not to replace corporate identity and access systems. It is to complement that layer with visibility into agent behavior and, where applicable, with operational context built from existing monitoring, observability, and management tools.

Knowing which agent executed an action is important. Understanding the circumstances in which it occurred and which resources were used makes that information far more useful for governance and auditing.

Learn about ARGUS and see how it works in practice.

About the author

Paulo Florêncio de Menezes is an entrepreneur, partner, and co-founder of companies such as Target Solutions, BiPTT, and ARGUS.

He holds a degree in Data Processing from the Federal University of Amazonas (UFAM), an MBA in Business Management from Fundação Dom Cabral (FDC), and a Professional Master’s in Economics from Fundação Getulio Vargas (FGV).

In his Master’s research, he developed the IBEOP-IA (Brazilian Index of Potential Occupational Exposure to Artificial Intelligence), investigating the potential exposure of Brazilian occupations to AI capabilities by combining occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] National Institute of Standards and Technology / National Cybersecurity Center of Excellence. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. Concept Paper, 2026.

[2] Google Cloud. Agent Identity overview. Identity and Access Management documentation, 2026.

[3] Blueprint Alliance. Industry leaders form the Blueprint Alliance to advance a shared architecture for securing AI agents. 2026.

[4] Palo Alto Networks. Secure AI Agent Identities & Access. 2026.