The Front Door: Your Agent Has No Identity of Its Own

The user surface is not a chatbot, and the agent acting behind it is not the person who triggered it. Build both wrong and you cannot audit a single thing it did.

In Part 0 I laid out the whole anatomy: eleven layers, seven organ systems, and one ordinary request, an employee resigning, that has to travel through all of them. This is the first organ. The front door. Two layers live here, the User Surface and Identity & Trust, and together they answer two questions the architecture diagram usually skips: how does a request get in, and who is allowed to make it.

Most teams have built half of the first layer and none of the second. That is not a criticism. It is the default, because the demo only ever needed the half they built.

The surface is not a chatbot

Here is the first thing the diagram gets wrong. It draws a user on the left, typing into a chatbot. So that is what teams build: a chatbot. Then a real request shows up, and it does not come through the chatbot at all.

Dana resigns on a Tuesday morning. She does not open a chat window and type "I quit." She opens Workday and files her notice. That is an event, fired by a system, hitting an API. No human typed anything to the agent. The whole thing starts with a machine telling another machine that a row changed.

Now count the doors that one resignation opens over the next three days. Four of them, and they open one at a time.

1. A system event. Dana's resignation reaches the agent without a word typed to it. Workday fires an event, the event hits an API, and that is what sets the agent off. The most important trigger in the story is one machine telling another that a row changed.
2. A chat window. Two hours later her manager wants a status check, so he asks the agent directly in Teams, the same way he asks everyone else: is Dana locked out yet?
3. An embedded copilot. IT runs the offboarding from inside the ServiceNow ticket, where the agent lives as a copilot, answering and acting in the tool they already have open instead of a separate app anyone has to go find.
4. A voice call. A field tech calls the service line to report the laptop is back, and the agent takes the call and logs it. No screen, no keyboard.

One resignation. Four different doors. And only one of them is the chatbot everybody builds.

That is the whole point of this layer. A real user surface has five entrances, not one, and Dana's story just walked through four of them. Here is the full set:

• Chat UI. The one you already built. The manager asking a question.
• Voice. The field tech, the call center, anyone whose hands are full.
• Embedded copilot. The agent living inside ServiceNow, Salesforce, the tools people already have open. Most enterprise agent use will look like this, not like a destination app.
• API and events. The Workday resignation. No person, no prompt, just one system telling another that state changed. This is how most agent work will actually be triggered.
• Agent-to-agent inbound. Another company's agent, or another team's, calling yours as a capability.

Build only the chatbot and you have built the one surface that shows up in the demo and the least common one in production.

Chat is one of five ways into an agent platform. The request that started Dana's entire offboarding, a resignation, arrived through none of the ways a human types.

Agent-to-agent inbound means you are a callable thing now

That fifth entrance deserves its own moment, because it quietly changes what you are running.

The moment your platform can be called by another agent, it is no longer just an application your employees use. It is a capability other software invokes. A partner's procurement agent calls your inventory agent. Your own payroll agent calls the offboarding agent to ask whether Dana's final numbers are ready. Standards for exactly this, like the Agent2Agent protocol, showed up in 2025 precisely because this traffic is coming.

Here is why that matters at the front door specifically. A machine caller does not do single sign-on. It does not have a browser, it will not click through your identity provider's login page, and it certainly will not do multi-factor. If your entire notion of "who is allowed in" assumes a human with a session, you have no answer for the caller that is itself a program. And "no answer" in practice means someone wires up a shared API key with no expiry, emails it around, and now the most powerful entrance to your system is guarded by a password in a Slack message.

Which brings us to the half of the front door almost nobody builds.

Now the question the diagram never asks: who is the agent?

The agent is about to revoke Dana's access. Okta, Slack, GitHub, AWS, the VPN, the badge. That is the sharp end of this whole scenario, so hold it in your head: an agent that can revoke Dana's access can revoke yours.

So when it does, whose name is on the action?

In most systems being built right now, the honest answer is: the person who happened to trigger it, or worse, a service account that everything shares. The agent has no identity of its own. It borrows one. It acts under her manager's token because that was the credential lying around when someone wired it up, and now every access change, every system it touched, every row it wrote, is stamped with her manager's name.

He did not do any of it. He could not have. He was in a meeting. But the log says he revoked Dana's production database access at 3:40 in the morning, and there is no way to prove otherwise, because the system never recorded that it was the agent. This is not a reporting inconvenience. In nine months an auditor asks who cut off Dana's access, you point at the log, and the log names a man who was asleep. You cannot re-attribute a year of logs after the fact. The attribution had to be true when it was written or it is never true.

This is the whole reason identity is a layer and not a checkbox. And it is getting more urgent, not less, because agents multiply the number of things acting in your systems far faster than you hire people.

Machine identities already outnumber human ones in the enterprise by more than an order of magnitude, and agents are the fastest-growing kind. Every one of them either has a name or borrows yours.

Four things that give an agent a name

Identity & Trust is the second layer of the front door, and it has four parts. None of them is exotic. You almost certainly own tools for all four already. The work is deciding to use them for the agent, not just for people.

SSO and OAuth, for the humans. This part you have. The manager asking in chat authenticates the way he always does. Nothing new. The mistake is stopping here and assuming it covers the agent too. It does not. It covers him.

Agent identity. The agent gets its own identifier, a first-class principal in your identity provider, the same way a person or a service does. Microsoft shipping Entra Agent ID in 2025 is the platforms admitting this out loud: an agent is a thing that acts, so it needs a name that shows up in the log as itself. When the offboarding agent revokes access, the record reads "offboarding-agent, acting under this policy, on behalf of this HR event," not "Dana's manager."

Scoped credentials. The agent's name comes with a short list of exactly what it may do, and nothing else. The offboarding agent can revoke access and read Workday. It cannot approve payments. It cannot read the CEO's mail. And its credentials are time-boxed: they work for the duration of this task and then they expire, so a token that leaks on Tuesday is worthless by Thursday. The opposite of the shared key with no expiry.

A policy engine. The rules about who may do what live in one place that every request passes through, not scattered across the code of forty different tools. When the agent asks to revoke access, one engine decides yes or no against a written policy, and it decides the same way whether the request came from chat, an event, or another agent. Without this, your permission logic is copy-pasted into every integration and drifts the moment anyone edits one of them.

Put those four together and the agent stops being a ghost operating your systems under a borrowed face. It becomes a named actor with a short leash and an expiry date, and the log finally tells the truth.

None of this is a model capability. A smarter model does not give your agent a name. You do, at the front door, or you never do at all.

Three questions for your own front door

You have an agent program, or you are about to fund one. Before anything downstream matters, the front door has to hold. Three questions tell you whether it does.

When your agent acts, whose name is in the log? If it is the user's, or a shared service account's, your agent has no identity. Fix that before you widen what it is allowed to do, because everything it does between now and then is misattributed, and you cannot correct it later.

What can a leaked agent credential do, and for how long? If the answer is "anything, forever," you have a standing key, not a scoped one. The credential should do one job and expire. Assume it will leak, and make the leak boring.

How does another agent, or a system event, get in? If your only answer to "who is allowed" is a human logging in, you have not designed for the four entrances that are not chat, and those are the ones most of your real traffic will use.

Most teams can answer none of the three cleanly. Again, that is not the team's failure. It is the failure of a diagram that drew a chatbot and a model and called the space between them a single arrow. The space between them is two layers deep, and it is where the audit trail is either born or lost.

What the front door decides

The rest of this series is about what the agent does: how it plans, what it remembers, when it stops and asks a human. All of that assumes something the front door either gave it or did not. An identity. Take a wrong turn here and every clever thing that happens downstream is done by a system that cannot say, truthfully, who did it.

The model will keep getting better at deciding what to do about Dana. It will never, at any capability level, give itself a name your auditor will accept. That is the front door's job, and it is yours to build.

Next: The Brain Stem. "Multi-agent" is not an architecture. It is four architectures, and most teams pick one by accident.

Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss the identity layer underneath your agent program.

References

1. Gartner. "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." June 25, 2025.
2. Microsoft. "Microsoft Entra Agent ID: Secure and manage your AI agents." Microsoft Build 2025.
3. Google / Linux Foundation. "Agent2Agent (A2A) Protocol." Announced April 2025.
4. OWASP. "Non-Human Identities Top 10." 2025.
5. Matthew Kruczek. "The Trust Boundary Moved: Governing Agents at the Gateway." matthewkruczek.ai, 2026.