Zero Trust Architecture for NHIs and Agentic AI Pipelines in Microsoft Entra

Summary

"Research-agent" has come a long way over the course of this series of articles. It runs on a managed identity instead of a stored secret, its deployment pipeline is federated instead of holding a key, and after the incident a few modules back, its access got scoped narrower than it was before. None of that answers a more basic question: why does anything "Research-agent" presents get trusted at all, and does that trust depend on where it happens to be running? Zero Trust says no. Every call "Research-agent" makes gets evaluated on its own, regardless of network location, regardless of what it was allowed to do yesterday, and increasingly, regardless of whether the thing on the other end of the call is a person, an API, or another agent entirely. This article walks through what that actually requires to build, not just to say.

The Zero Trust Principles

Zero Trust for "Research-agent" rests on three ideas, and none of them are new inventions. What's new is applying them to something that isn't a person.

Verify explicitly means evaluating every action "Research-agent" takes, not the network it happens to be running on. A request from inside the corporate VNET doesn't get a pass just because of where it originated. Least privilege means "Research-agent" holds exactly the access a given task needs, for exactly as long as that task takes, not a standing grant that's technically scoped correctly but active every hour of every day whether it's being used or not. Assume breach means designing the whole system so that if "Research-agent" token gets stolen again, the way it was in an earlier module, it travels nowhere useful and stops working fast.

None of these are controls you buy. They're constraints the rest of this article's architecture has to satisfy.

Identity Becomes the New Perimeter

The old model trusted "Research-agent" because of where it sat. Inside the firewall meant trusted, and the network boundary did the work identity does now. That model assumed there was an inside worth trusting in the first place. "Research-agent" calls SharePoint, a SQL endpoint, and the open web, sometimes from an Azure region, sometimes through a partner's API, and none of those calls have a meaningful notion of inside to rely on.

The replacement is a Policy Enforcement Point in front of every resource "Research-agent" touches, backed by a Policy Decision Point that evaluates each request against policy before it's allowed through. In Microsoft Entra ID terms, Conditional Access plays the role of the decision point. It doesn't just gate a sign-in once. Continuous Access Evaluation, the same mechanism that would have cut off "Research-agent" stolen token faster back in the incident response module, keeps re-checking a small set of critical signals against tokens that are already active rather than trusting a decision made an hour earlier.

None of this makes "Research-agent" untrusted by default. It makes trust something re-earned on every call, instead of something granted once at the network boundary and assumed to still hold an hour later.

Four Patterns That Make Zero Trust Real

Four architectural patterns turn the principles above into something an engineering team can actually build, and "Research-agent" ends up touching all four in a mature deployment.

Hub-and-Spoke Identity Broker

Instead of "Research-agent" holding separate credentials for SharePoint, SQL, and whatever web APIs it calls, a central broker issues short-lived, scoped tokens for each resource on request. "Research-agent" never talks to a resource directly to authenticate. It talks to the broker, and the broker is the one place policy gets enforced, behavior gets observed, and access gets revoked if something looks wrong. Microsoft Entra ID already plays this role for anything that goes through it, which is part of why consolidating on it instead of scattering credentials across a dozen resource-specific mechanisms is worth the effort.

Sidecar Identity Proxy

For a containerized workload like "Research-agent," a sidecar takes the broker pattern one step further. A companion container running alongside "Research-agent" own code handles token acquisition, rotation, and validation, so the application code itself never touches a raw credential, not even a managed identity token cached in memory longer than it needs to be. This is still an emerging pattern for AI workloads specifically, closer to how service meshes have handled workload identity for a few years than to anything Entra ID enforces on its own.

JIT Access with Microsoft Entra PIM

"Research-agent" runs its usual queries against Sites.Selected access to one SharePoint site every night. Once a week it runs a broader audit that needs read access across the whole site collection, and that's the access worth making just-in-time instead of standing. Privileged Identity Management support for workload identities lets a service principal hold an eligible role assignment instead of an active one, activated only for a bounded window:

Most of the week, that broader permission simply doesn't exist for "Research-agent" to lose.

Cross-Tenant Federation

If "Research-agent" ever needs data from a partner organization, the anti-pattern is the partner emailing over an API key. Microsoft Entra External ID and B2B collaboration let the partner's own tenant govern what "Research-agent" can reach, scoped through a cross-tenant access policy rather than a shared secret either side has to protect:

Access lives in policy the partner tenant controls and can revoke on their end, not in a string "Research-agent" team has to remember to rotate.

Agent-to-Agent Trust with Verified ID

Everything so far assumes "Research-agent" is talking to a resource or a person. Once it starts talking to another agent, a new question shows up: how does "Report-agent," the agent that turns "Research-agent" findings into a drafted report, know that what it just received actually came from "Research-agent" and hasn't been tampered with along the way?

Microsoft Entra Verified ID answers that with two pieces working together: a decentralized identifier that "Research-agent" controls independent of any single directory, and a verifiable credential issued against that identifier attesting to specific claims. A credential "Report-agent" would check looks roughly like this:

Three claims are doing the actual work here: that "Research-agent" is who it says it is, that whoever issued the credential is an authority "Report-agent" already trusts, and that "Research-agent" configuration and integrity state match what was attested at issuance rather than something modified afterward. "Report-agent" checks the signature against the issuer's DID document, confirms the configuration hash matches what it expects, and only then treats the incoming findings as legitimate. It's close to two diplomats exchanging sealed credentials before getting into the actual conversation, and it lines up with the W3C's DID specification and the OpenID for Verifiable Credentials work rather than being a proprietary format.

Conclusion

None of "Research-agent" hardening from earlier in this series means much if trust still depends on which network it happens to be calling from. Verify explicitly, least privilege, and assume breach only become real once there's a broker issuing short-lived tokens, PIM making standing permission the exception instead of the default, and a way for "Report-agent" to check that what it received actually came from "Research-agent" unmodified. Identity ends up doing the job the network perimeter used to do, and it has to do it on every single call, not once at the door.