Let us consider a workflow that almost every engineering team has built: an AI agent that listens to a meeting, summarizes the meeting notes, adds it to the Confluence, pulls out action items, opens a Jira ticket with the necessary details and assigns the ticket to the right person.
Who the agent really is?
The agent, on a simple scale, touches three different systems: it reads and writes Confluence, generates meeting notes, and creates and assigns tickets. Every time the agent executes an API or tool call, it acts under an identity. Now the question is no longer about what an agent does, but “who” it is performing these actions as.
This changes the conversation and the way we think of how an agent operates. Usually, the answer to this question would be either a service account or an API key, and for a POC or development environment it might even be the developer login credentials of whoever built the agent. Now it doesn’t matter which of these it is, since none of the three cater to agent development. They were credentials that were used because they were readily available.
Why don’t fixed credentials help?
For static webhooks or standard pipelines, fixed credential works just fine, because say a tool that always writes the same summary to the same Confluence page needs the same access every time, and you would provision the credential once and move on.
However, for an agent, the process or the workflow isn’t always fixed. An agent’s execution path on Tuesday wouldn’t be the same on Wednesday. As we know agents are exceptional at what they do, so it gets handed more tools. For example, it starts reading the CRM for context, posts updates of the ticket on Slack, or even closes the ticket based on Slack message updates. Every new tool added now uses the same credential, and what we fail to question is whether those credential fits these tools or even applies to these tools.
So, the real question isn’t just who this agent is, but what the token or credential boundaries are. For most agents like this, the token is usually scoped for convenience and does not account for a job that keeps changing shape.
A layer of its own
Identity has two layers to it: the humans and the machines. Now a service account sits in the machine layer as it’s predictable and operates within a fixed workflow or boundary. You can see what it touches and grant tokens that precisely does that.
As mentioned earlier, an agent cannot sit in any of the two layers, because it acts on its own judgment, more like a human would, but operates at machine speed, where it keeps calling tool after tool, reiterating until it reaches its goal, with nobody to stop, grant, or monitor.
That makes agent-identity a layer of its own. Almost nobody treats it that way yet. Most agents are still issued a machine identity, or a human, and expected to behave exactly like an agent.
The industry is catching up
However, this isn’t a gap that’s sitting unnoticed. People and major organizations have started working on workload and agent identity and are actively defining what an agent’s identity should carry and how it should get issued. We will discuss more on how organizations are trying to adapt existing protocols for agents as this series progresses.
Though there is active research going on to produce a protocol that exists just for agents, organizations have to continue to adopt and adapt to agents, as AI isn’t slowing down for anyone, and it shouldn’t have to just because we haven’t figured out how to secure it. This series will walk you through how current organizations are trying to ship agents like the one above securely, with what they already have, while the standards catch up.
Where to start
Let’s first start by identifying the credential each of your agents is using and moving it to its own identity, even an imperfect one would help, as long as it’s distinct from a human’s. After moving, the credential to its own space, start adding an expiry on every key that doesn’t have one, so a token or credential sized for the previous version of the agent can’t keep working for the latest one. None of that needs a new standard. It just means treating the agent’s credential as its own thing instead of a detail you set once and forget.
In the next post, we’ll dive into the four core properties required for agentic identity and break down where emerging industry standards stand today.