With Meta’s recent launch of its consumer-facing Muse AI agent, many people are now learning what the growing number of organizations working with agents already knew: agentic tech has advanced beyond simply answering questions or directing inquiries and can act on the information they retrieve to handle tasks like fulfilling orders, transferring information to other applications and editing databases.
But while Meta’s has given its Muse agents distinct personalities, complete with avatars, enterprises should think about identity differently. Agents can be given characteristics like a name and rules for communication, which can give them authority with users and encourage their use. But an AI agent’s persistent identity should also include records that document not only the authentication and permissions granted, but the business authority behind the agent.
AI agent identity should be more than a service account
Traditionally, identity and access management (IAM) answers questions about which identity is requesting access, which resources that specific identity can access and which permissions the identity has been granted.
With AI agents, these questions are still relevant but more complicated. Agents can use the permissions and access they have not just to share and retrieve information but to make decisions, invoke tools and APIs and perform event sequences with little or no human oversight.
Modern IAM that takes the capabilities of AI agents into account requires enterprise-grade agent identity records. For each of an enterprise’s agents, these records should include the agent’s approved business purpose, its creation and approval date, a persistent and unique identity, the human owner (tied to a business role, in case of staffing changes) of the agent and its actions, the systems and tools the agents can use, the permissions delegated to the agent (and who they were delegated by), any limits on the agent’s autonomy and the conditions for the agent’s review and/or expiration.
Even as the technology behind a given agent changes, its identity should persist, says Nuha Hashem, co-founder and chief technology officer of Cozmo AI. Agents should have a single ID that stays consistent while versioning any changes to the agent within the identity record, Hashem recommends.
“We need to give the agent one ID that stays the same when the model or prompt changes, because we want its full history in one place,” she said.
In creating robust identity records for AI agents, enterprises should consider both permissions and authority. The agent’s permissions describe what it technically can do, while its authority describes what the enterprise intends it to do. That distinction can mean very different risk levels even for agents with similar access, says Shashwat Sehgal, CEO and co-founder of P0 Security. For example, one agent might summarize information, while another could modify production infrastructure. Therefore, each agent’s identity record needs to contain enough context about its purpose and capabilities to distinguish between them, Sehgal says.
A chain of delegated authority for each agent
So where does authority come from? As with most things involving AI agents and IAM, the answer can be complicated.
An AI agent might be created internally by an employee or a team of employees. The manager for the creating employee(s) will approve the workflow or workflows designated to the agent and IT staff will provision the necessary access and permissions to allow the agent to execute that workflow. If the agent needs to be integrated with other tools or APIs, security staff will approve that, which allows it to invoke other applications – or other agents. At every step along this chain – from human/business function to authorization to agent to delegated permissions to action – identity records must be created and preserved.
That identity record should identify the person who first gave the agent its authority, along with a business sponsor and the IT or security staffer who approved the agent’s scope, Hashem says. As well, the record should document the agent’s purpose, which systems and tools it can use and which of its actions require human oversight or approval.
“The way I think about it is that an AI agent cannot authorize anything by itself. Someone has to give it that authority and that person should be named in the record,” she said.
That chain of authority should then follow the agent into its work. Each of an agent’s actions should be logged with the version of authorization under which the action occurred, what the agent did and the resulting output, Hashem suggests. Any human approvals or takeovers should also be part of that same record.
These records are important not just when employees are part of the chain, but also when one agent delegates work to another. “An agent shouldn’t become the beginning of the audit trail,” Sehgal said.
If an AI agent calls another agent or tool to complete a task, the authorization record should preserve who initiated that request, which agents acted on it and which permissions were used at each step, he says. By the time an action reaches the target system, the organization should be able to determine not just which agent accessed it but on whose behalf it was acting, which task it was doing and why that action was allowed.
“If the record ends with ‘the agent did it,’ you’ve lost a lot of the accountability enterprises rely on today,” Sehgal said.
Hashem sees that need in Cozmo AI’s work with insurance claims. Its agents can answer calls, open claims and schedule crews and these actions create situations in which a carrier might later need to determine who authorized a specific dispatch. The agent’s record should make it possible to trace that action back to the operations lead who approved the workflow, what was specifically approved and the associated transcript or call recording, she says.
“This can all be pulled out in a minute, since everything was already logged and timestamped,” Hashem said.
Purpose belongs in the identity record
Along with establishing who authorized an agent’s actions, it’s also important to document what specifically an agent is – and isn’t – authorized to do.
Consider two distinct AI agents in an organization, both with legitimate access to the same customer database. Agent A can access customer records to prepare renewal recommendations, while Agent B can access them to resolve support cases. In cases like these, the access is technically identical, but the authority is very different for each agent.
This is why it’s important to record each distinct agent’s business purpose, so organizations have the context beyond the agent’s permissions. Having this documentation is particularly key for determining if a technically permitted action was actually within the approved role for a given agent.
That purpose can also inform how access is granted. Sehgal argues against giving AI agents broad standing access just because they might need it at some point. “Its access should follow the task,” he said. For example, an agent that needs to query a specific database or restart a service can be given the necessary access for that job instead of credentials with much broader permissions.
Agent authority should come with an expiration date
After creating robust identity records for AI agents that consider both permissions and authority, one more step is required: determining when they end.
For reasons ranging from staff changes to tech updates and evolving workflows, AI agents will eventually outlive their business use cases. For that reason, agents should never be given an identity and permissions indefinitely. An agent might need to be reassessed when its owner changes roles or leaves the company, its business purpose or workflow changes, its permissions expand or retract, or it gains a new model, tool, or integration.
“The mistake is treating an identity as static while the agent keeps evolving,” Sehgal said.
Ensuring each agent has an expiration date ensures its permissions and authority will undergo periodic review to affirm the agent should still exist, is still owned by the same person or team and still holds the same business purpose. But if the agent itself changes significantly, periodic reviews aren’t enough, Hashem says. Changes like a new model version, prompt, tool or system to which the agent can write should be sent back through the approval process before deployment.
Unusual or unexplained agent behaviors – for example, unexpected use of a new tool, escalations to humans, or customer complaints associated with an agent – should trigger a review and might be reason to reconsider its authorities, she says. Hashem also recommends revoking the credentials of any AI agents with more than 30 days of inactivity and requiring reauthorization before those agents are put back into operation.
“Anything that changes the agent or the job function it’s doing should trigger a review or change to its identity, credentials, or permissions,” Hashem said.
Identity as an AI agent’s organizational record
Enterprises are managing a quickly growing population of AI agents – 40% of large organizations are scaling AI agents, according to McKinsey. In this environment, just knowing which credential made an API call isn’t enough to provide accountability for those agents.
For organizations using AI agents, enterprise-grade identity should answer four questions: who is this agent, who authorized it, what is the agent authorized to do and why and is the agent’s authority still valid?
The value in ensuring the development and documentation of robust, modern AI agent identities isn’t just in giving enterprises another identity to authenticate. The true benefit lies in the preservation of the chain of human and organizational authority behind the autonomous actions those agents are deputized to take.
Leave a Reply