Key Ingredients of AI Agent IDs

Introduction

AI agents are increasingly ubiquitous, yet they rarely present information about the construction and origins of the agent, and why they should be trusted.

Consider the example of OpenAI agents hacking into Hugging Face’s systems. On 16th July 2026, Hugging Face disclosed a security incident where unauthorized access to a limited set of internal datasets and to several credentials was identified. However, five days would pass before OpenAI announced that the incident was driven by their models. At the time of Hugging Face’s announcement, they knew that the campaign was run by an autonomous agent framework, but did not know which LLM was used. Here, we see a gap between seeing the action an agent is taking but not being able to identify the agent and its operator.

Agent IDs aim to mitigate risks similar to such cases.¹ While there are many industry solutions for agent IDs, they primarily address the functionality of agents and the technical needs of agent providers and deployers. Robust agent IDs can additionally address risks that affect other entities who are not directly involved in creating or operating the agent, as the ID can include information that provides transparency into how the agent was built, information to ensure accountability across all the actors involved, and a plan for what to do when something goes wrong with the agent.

This post sets the stage for forthcoming research comparing features and functionality of different proposals for agent identity. We will describe the high level goals of agent IDs, examine some functions that contribute to the goals, and provide several examples of protocols implementing those functions.

Goals of Agent IDs

We use the term AI agent to mean the whole technical system that uses an LLM to turn a human or machine input into actions in the digital world. Some key actors² in this system are:

• The deployer who directs the agent to accomplish a task
• The agent provider who provides the agent scaffold, which is used to manage models, data sources, and tools, and specifies how the agent takes actions
• The model provider who hosts the LLM that decides how the agent will accomplish the task
• The service, not part of the agent, who ultimately receives a request from the agent and has to decide whether to take the requested action

The agent may present an ID to the service that carries extra information to convince the service to trust the agent. For instance, if the service requires a user to log in to the service to take that action, then the agent clearly needs to present evidence to the service that the user authorized the agent to take that action.

The ID can support the agent’s functionality (like carrying authorization), prevent malicious or accidentally harmful actions, or provide additional information to the service to inform its decision to allow or reject a request. The table below summarizes the primary goals that an agent’s ID can support, along with the specific functions that support the outcome.

Ultimately, agent IDs achieve these goals by enabling transparency across the ecosystem. Access control can only be enforced by knowing who is behind the agent, incidents can only be responded to if those able to take actions are identified, and actors can only be held accountable by knowing who provided the model or the agent scaffold.

What already exists

We now briefly discuss various parts of a solution that either already exist or are actively being developed, and provide some examples. These range from narrow building blocks we refer to as “primitives” that implement specific functions, protocols that describe how agents communicate, platforms and products for managing agents, to standards work that aims at something more comprehensive.

As we have seen in the previous section, a robust agent ID solution would include authorization, authentication, identifiers, and other functions. Mature protocols and implementations already exist for many of these functions. OAuth is a standard that allows a user to authorize an application or a website to access certain resources. OpenID Connect is a protocol that enables authentication of a user. Separately, Secure Production Identity Framework for Everyone (SPIFFE) provides instance identifiers for any kind of software workload, and can be used for AI agent processes as well.

Other protocols standardize how an agent reaches tools and other agents, and unlike the primitives above, they provide the means of communication an agent uses to take actions affecting the external world. Model Context Protocol (MCP) is an open-source standard for connecting AI applications to external systems.³ Agent2Agent (A2A) is an open protocol which provides a standard way for agents to collaborate with each other, regardless of the underlying framework or vendor.

Besides protocols that simply specify a common language of communication, other efforts provide ways to build or manage agents. Know Your Agent - Operating System (KYA-OS), previously known as MCP - Identity (MCP-I), addresses agent identity and delegation and can be implemented on top of MCP. The Gemini Enterprise Agent Platform allows the creation of an agent with agent identity, which can be used for access control and auditing, and agents on it can be built using their open-source Agent Development Kit (ADK). Microsoft Entra Agent ID and Amazon Bedrock AgentCore Identity are other offerings that support agent IDs from Microsoft and AWS respectively.

In particular, the agent commerce domain has developed more mature implementations, with protocols that carry information about who authorized an agent and on what terms. Agent Payments Protocol (AP2) is an open protocol that uses cryptographically signed mandates to show a merchant that a user authorized a specific purchase. Visa developed Trusted Agent Protocol which aims to distinguish trusted, commerce-focused agents from malicious bots.

Finally, various efforts are underway towards developing a more comprehensive agent ID protocol. IETF has various working groups that would address specific parts of such a protocol, e.g. WIMSE and Web Bot Auth, alongside Birds of a Feather (BOF) groups such as Agent Communication Protocols. Individuals also publicly submit proposed protocols as drafts to the IETF, for example AI Agent Authentication and Authorization among many others on various topics related to agent AI protocols. The ITU also has a Focus Group on Trust and Identity for Humans and Agentic AI (FG-TIDA) which aims to address digital identity infrastructure for humans and for agentic AI. NIST National Cybersecurity Center of Excellence (NCCoE) also published a concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, to propose a project to demonstrate how identity standards and best practices can be applied to agentic AI applications and have started a series of blog posts with some of their findings.

Conclusion

Agent IDs aim to serve a wide range of purposes, from enabling basic functionality to safeguarding against harm to the broader ecosystem. In this post, we described the goals of agent IDs and the functions required to fulfill them, and gave a few examples of existing and ongoing work related to agent IDs.

Next, we will develop a refined methodology and use it to compare existing agent ID proposals and implementations in order to identify areas of alignment and divergence across this fast-moving space. If you’d like to contribute to this work or the methodology behind it, please reach out at agentids@aisafety.sg.

Appendix

Core Functions

Additionally, there are other functions that are valuable for AI agents and may be supported by agent IDs, even though they may not contribute directly to the goals of agent IDs. For example, agent discovery allows for agents, their capabilities, and other relevant information to be discovered without having prior interaction. Agents can also be scored for their ‘trustworthiness’ by third parties according to various criteria, where only agents of a certain reputation would be allowed access. Furthermore, a registry can be used to store information related to the agent, including their IDs, their capabilities, and other details on the actors behind the agent.

Notes

1. Unfortunately, this particular OpenAI / Hugging Face incident cannot be prevented by agent IDs alone, as the attack was conducted through several intermediaries where the ID would not have been carried through. We describe these learnings in more detail in an upcoming post. ↩
2. There are also additional actors who may be involved in the process and may also play a role in agent IDs, such as agent platform and gateway providers. On the other hand, there are often implementations where these roles are performed by the same actor, such as when an agent and the model used are open-source versions hosted locally. ↩
3. Additionally, MCP provides authorization capabilities at the transport level. ↩