Anton Staykov

Posted on Jul 21

How enterprise architects should decide Entra Agent ID blueprint boundaries for non-Microsoft platforms

#entraagentid #identitygovernance #aiagents #zerotrust

Enterprise architects keep asking me the same question: how many agent identity blueprints should we create for third-party or custom agent platforms connected to Microsoft Entra Agent ID?

That question sounds operational, but it is architectural. You are deciding failure containment, ownership boundaries, and governance behavior, all at once.

Before we go deeper, one important acknowledgement. If your agents are built in Microsoft-managed builder paths such as Copilot Studio and Agent 365 integration flows, identity provisioning is largely handled for you, including automatic Agent ID creation and shared blueprint behavior in that platform path (Copilot Studio automatic Agent IDs, Agent 365 identity integration). If you choose that platform, you also accept its blueprint identity model by design.

This article is for the other world: non-Microsoft-built agent platforms, where your enterprise architecture team owns the blueprint boundary decisions.

I am also not going to summarize the canonical guidance. You should read both Plan your agent identity architecture and Microsoft Entra Agent ID design patterns directly, then come back. This piece is about decision framing, trade-offs, and policy posture.

Stop asking for a count, start defining trust boundaries

When architects ask "how many blueprints," they usually mean one of three fears:

"I do not want one compromised component to become tenant-wide damage."
"I do not want central identity teams to become a ticket bottleneck."
"I do not want unrecoverable sprawl six months from now."

That is a trust-boundary problem, not an object-count problem.

Microsoft's own architecture guidance is explicit that blueprint count should follow trust boundaries, while many common concerns (replicas, memory partitioning, session context) are not valid reasons to split identities (planning guidance, design patterns).

If your team still starts with org chart lines like "one blueprint per project by default," you are optimizing for slide readability, not for incident containment.

The blueprint power model, and the part teams keep confusing

You need one clear mental model.

The blueprint is your identity factory and authentication anchor. It is what enables creation of child agent identities at scale, including runtime or ephemeral patterns when your architecture needs on-demand identities (creation channels).

That is good news for delivery teams. Developers do not need to raise a central ticket for every single new identity if the right blueprint channel and controls are already in place.

But do not confuse that with automatic governance.

Blueprints are not where your organization magically enforces business access policy. Consent boundaries, entitlement policy, Conditional Access, and app-governance controls are separate control planes that still require explicit enterprise policy definition and rollout (user/admin consent model, define governance policy).

Treat the blueprint as a creation authority, not as the permission-grant layer and not as your per-agent lifecycle governance switch.

In plain terms, Entra Agent ID and Agent 365 capabilities do not enforce your internal architecture doctrine by themselves. Without internal policies, teams will improvise.

Blast radius reality: one compromised agent can become many identities

Here is the uncomfortable part.

Within a shared blueprint trust boundary, if one agent runtime is compromised and the attacker can use the same blueprint credential path, that attacker can request tokens that act as sibling identities under that blueprint boundary. This is exactly why Microsoft frames blueprint compromise as potentially affecting all child identities in that blueprint scope (planning guidance).

That is the architectural reason you model by trust boundary first.

It also explains a frequent false comfort pattern: "we will just split certificates or managed identity details but keep one shared blueprint boundary." If the effective authentication authority is still the same blueprint trust surface, your containment gain is smaller than people assume.

A risk-first decision framework for blueprint boundaries

Use this sequence. Do not skip steps.

1) Define hard trust boundaries

Map runtime, secret stores, network segmentation, and operational ownership. If compromise should not cross between two zones, they should not share a blueprint.

2) Define failure containment targets

State explicitly what should be kill-switch scope:

one identity,
one blueprint,
one environment,
or tenant-wide.

If this is undefined, your incident response design is fiction.

3) Define permission topology

Decide what is inheritable baseline and what is per-agent specialization. Keep inherited baseline tight and role-specific differentiation local to agent identities.

4) Define lifecycle behavior

Will identities be long-lived, or created dynamically for specific task windows? If dynamic creation is a first-class requirement, blueprint channel design and guardrails become even more critical.

5) Define governance ownership

Who approves what, who can create via which channel, who can override in emergencies, who attests quarterly. If there is no owner matrix, there is no governance.

When one blueprint is right, and when it is reckless

One blueprint with multiple agent identities is often correct when teams share the same trust boundary, runtime envelope, and operational ownership, while still needing per-agent attribution and differentiated downstream access (design patterns).

Concrete example: if your agents run in the same container orchestration boundary (for example, a shared Kubernetes namespace on AKS, EKS, or GKE), that is usually a strong indicator for one shared blueprint in that boundary. In practice, namespace-level controls define who can deploy, who can mutate workloads, what network policies apply, and what mounted/shared resources are reachable.

That matters because your real security perimeter is often the namespace and its attached runtime controls, not an individual pod. Most engineering organizations can consistently enforce controls at namespace scope for developers and CI/CD pipelines, while per-pod isolation is harder to guarantee as a durable operating model.

It becomes reckless when you cross security domains and still keep one blueprint for convenience. Separate teams, separate secret domains, separate runtime isolation, or separate regulatory boundaries should usually trigger separate blueprints.

Policy starter kit for enterprise architects

If you want consistency across teams, publish a short internal policy before the next project starts.

Blueprint policy baseline

One blueprint per trust boundary unless exception approved.
Mandatory sponsor and owner assignment, with periodic attestation.
Naming convention that encodes environment, domain, and business owner.
Conditional Access baseline and monitoring baseline applied at blueprint and identity levels where applicable (best practices, manage and govern agent identities).

Creation channel policy

Define which channels are allowed in your org: admin center, Graph, IaC/CLI, product-integrated channels.
Bind each channel to approved roles and permission grants.
Prohibit ad-hoc consent paths for production-grade identity creation unless explicitly reviewed (configure user consent).

Split and merge rubric

Require architecture review on:

trust-boundary changes,
new regulated data exposure,
new external execution platform,
incident lessons that show containment gaps.

If teams cannot explain why two workloads can safely share compromise blast radius, they should not share a blueprint.

The architect checklist to force before production

Before approving blueprint design, require crisp answers to these questions:

If one agent runtime is compromised, what exact identity scope can the attacker influence?
Which trust boundaries are represented, and why are they safe to share?
Which channels can create identities, and who controls them?
Which policies prevent consent and permission sprawl?
What is the fastest kill-switch path during incident response?
What quarterly evidence proves this model is still valid?

If your team cannot answer those six questions in one review, your blueprint model is not ready for production.

DEV Community