Agentic AI Architecture and Identity Implications using Microsoft Entra
Summary
Picture an agent built the way most of these are built now: an orchestration layer, LangChain in this case, coordinating a reasoning core that decides at runtime what to do next, backed by a memory store and a set of tool connectors reaching into SharePoint, a SQL database, and the open web. To stay together on this journey, we will call our agent "Research-agent." Every connection in that architecture is its own authentication event: the orchestrator talking to the reasoning core, the reasoning core reaching into memory, the reasoning core calling out to a tool. Traditional identity governance assumes a person is behind each request, weighing whether it makes sense before it happens. "Research-agent" doesn't have that person in the loop. It reads a page, decides the instruction on it sounds reasonable, and acts on real systems with real credentials. What follows is what that means for how "Research-agent" should actually be built, and where setups like it usually go wrong instead.
The Identity Triangle
"Research-agent" isn't one running program. It's four. An orchestration decides which components get invoked; the reasoning core, which is the actual Large Language Model (LLM), decides at runtime what to do next rather than following a fixed script. Then sit a memory and state store, holding whatever context the conversation needs to carry forward, and a set of tools and APIs, in this case SharePoint, a SQL database, and the open web.
None of those four components is the security problem on its own. The problem is that every line connecting them is a place where one component has to prove its identity to another, and Microsoft Entra ID has to decide what that identity is allowed to do. Call it the identity triangle: an orchestrator ID for the orchestration layer itself, a sub-agent ID for the reasoning core acting on the orchestrator's behalf, and a tool-call ID for whatever credential "Research-agent" presents when it actually reaches out to SharePoint or the database. Get any one of those three wrong, and the boxes in the diagram are fine, but the lines between them aren't.
| Workflow | What has to prove its identity | What breaks if it's wrong |
|---|---|---|
| Orchestrator to reasoning core | The orchestration layer's own identity, since it's the one invoking the LLM. | A shared, unscoped credential means every reasoning core on the platform inherits the same access. |
| Reasoning core to memory | A sub-agent identity tied to this specific run, not the whole platform. | Without it, one conversation's reasoning core can read another user's saved context. |
| Reasoning core to tools | A tool-call credential scoped to the one connector being used. | One broad credential covering SharePoint, SQL, and web at once turns any single compromised call into access to all three. |
Table 1 - Describes the workflow for agents to authenticate its identity
Token Flows
When "Research-agent" reaches out to Microsoft Graph, SharePoint, or a SQL endpoint, it has to present a token, and which of two patterns produced that token decides whose permissions it's actually using.
Pattern 1: Client Credentials Flow
In the client credentials flow, "Research-agent" authenticates as itself. It sends its own client ID and either a secret or a certificate assertion to the token endpoint, requests a scope such as https://graph.microsoft.com/.default, and gets back a token carrying its own standing application permissions, the ones an administrator granted to "Research-agent" once, not to whichever person happens to trigger this particular run. That's a reasonable pattern for a fully autonomous batch job with no human involved. It's a much worse one the moment someone types a request into a chat window and "Research-agent" acts on it, because the token it's using was never scoped to what that specific person is allowed to see.
Pattern 2: On-Behalf-Of Flow
The on-behalf-of flow starts from a different place. A person is already signed in, and "Research-agent" is holding a token that represents them. To reach a downstream resource, it exchanges that token instead of presenting its own credentials.
Microsoft Entra ID validates the incoming assertion, confirms it really belongs to the signed-in user, and issues a new token scoped to the downstream resource, capped at whatever that user could already reach. "Research-agent" cannot return a document the requesting user didn't already have permission to open, because the token doing the work was always theirs, just passed through the agent along the way.
One detail this pattern exposes quickly: access tokens typically expire on the order of an hour, and an agent that thinks for twenty minutes before its next call is fine, but one that keeps a research task open for two hours needs a refresh strategy designed in from the start. Discovering that gap the first time a long task dies partway through is not the way to find it.
The Risks
Four key risks account for most of what goes wrong once "Research-agent" is actually running against real systems.
| Risk | OWASP mapping | What it looks like for "Research-agent" |
|---|---|---|
| Prompt injection | LLM08, Excessive Agency | "Research-agent" reads a web page containing a hidden instruction telling it to email a database export to an outside address. It has no reason to suspect the page, so it complies, using its own legitimate credentials. Nothing crashes. It did exactly what it was told, just not by the person who was supposed to be doing the telling. |
| Over-Permissioned agents | LLM08, Excessive Agency | "Research-agent" was given write access to a production SQL database "just in case" a future task needed it. No task ever has. Now a single injected instruction can turn a research tool into something that deletes rows, not just reads them. |
| Lateral Movement | LLM04, LLM06 | Because "Research-agent" tool credential covers SharePoint, SQL, and the web under one grant instead of three separate scoped ones, a compromise anywhere in that chain can hop across all three, each hop using a token that's technically valid. |
| Sensitive Data Disclosure | LLM06 | An over-permissioned "Research-agent" doesn't need to be tricked to cause harm. It can answer a question honestly, using access nobody meant for it to have, and return information the requesting user was never supposed to see. |
Table 2 - Describes the four risks and its OWASP classification
How It All Comes Together
Every one of the last three sections points at the same idea. "Research-agent" is, in practical terms, a new hire: brilliant, tireless, and willing to work through a research question at three in the morning without complaint. It's also infinitely gullible and has no security intuition of its own, so a prompt injection is really just a stranger confidently telling that new hire to do something terrible, and the new hire, having no reason to doubt a confident-sounding instruction, does it, cheerfully, using its own credentials.
| "Research-agent," built by Default | "Research-agent," built Securely | |
|---|---|---|
| Authentication Pattern | Client credentials, even for user-triggered runs | On-behalf-of, access is capped at what the requesting user could already reach |
| Tool Permissions | One broad grant covering SharePoint, SQL, and web | Separate, narrowly scoped credentials per tool |
| Standing Access | Write access kept "just in case" a future task needs it | Access added only when a specific task requires it |
| Token Handling | Expiry discovered the first time a long task fails | Refresh designed in before the agent ships |
Table 3 - Describes the difference between the traditional way of authentication and the secure way.
None of this requires treating "Research-agent" as untrustworthy. It requires treating it the way a reasonable manager treats any new hire: give it exactly the access the job requires, watch what it actually does with that access, and don't wait for it to prove the access was too broad before narrowing it.
Conclusion
An agent is not a faster version of the automation you already had. It's a new kind of coworker that reads instructions from anywhere and acts on them immediately, using real credentials, with no pause to ask whether the instruction made sense. The identity triangle, the choice between client credentials and on-behalf-of, and the discipline of scoping every tool credential narrowly are what stand between "Research-agent" being a genuinely useful hire and being the easiest way into your production systems.