If you are an enterprise architect working on Microsoft Entra and AI agents, your first overdue job is not another policy wizard, another dashboard, or another governance steering committee. It is schema design.

Specifically, it is deciding how you classify non-human identities with custom security attributes in Microsoft Entra. Not eventually. Up front.

I keep seeing the same pattern across customers of every size: teams move quickly on agent experimentation, they onboard identities, they test controls, and then they realize they have no consistent attribute language for policy scope. At that point, every policy becomes a naming convention problem in disguise.

That is backwards.

The control plane starts with classification

Custom security attributes are not decorative metadata. They are tenant-scoped key-value classifications you can assign to users, enterprise applications (service principals), and agent identities that are modeled as a service principal subtype, with dedicated role and permission boundaries for who can define and assign them (overview, Graph model, agent identity service principal model).

That alone should change how architects think about them. This is not "nice to have taxonomy." This is policy input.

Microsoft Entra Conditional Access for agents supports attribute-driven targeting with custom security attributes, and policy evaluation happens during token issuance and refresh, not just at policy authoring time (Conditional Access for agents). In other words: if your classification is sloppy, your runtime decisions are sloppy.

Why agents raise the stakes

You can say "an agent identity is still a service principal" and be technically correct. Microsoft Entra Agent ID is built on service principal infrastructure (agent identities, service principals, and applications).

You can also miss the point.

Agent identity introduces a blueprint-centered model where one blueprint can represent many agents, where blueprint-level policy decisions can affect all derived identities, and where operational accountability (owners and sponsors) is part of the model (key concepts). This is not how most architects historically modeled "traditional" workload identities.

So yes, same substrate. Different operating semantics.

That difference is exactly why CSA strategy for agents should be deliberate, not inherited by accident from old workload identity templates.

Reuse your existing workload schema or create a dedicated agent schema?

This is the question every architecture board eventually reaches.

The honest answer is conditional, not ideological.

Reusing your existing workload schema has real advantages. It accelerates rollout, avoids duplicate governance machinery, and can be enough if your workload identity estate is already cleanly governed and your agent population is still limited.

But here is the trade-off many teams underestimate: semantic collision.

When the same attribute family has to describe static daemon services, integration apps, and AI agents with interactive and autonomous behavior patterns, naming starts to drift. Policy intent gets fuzzy. People read "criticality" or "environment" and assume shared meaning where meaning has already diverged. Then policy scopes become misleading even when the syntax is valid.

That is the failure mode I care about most. Not policy syntax errors. Policy intent errors.

For regulated enterprises, or any organization expecting meaningful agent scale, my default recommendation is to establish a dedicated agent CSA schema and keep crosswalk mappings to legacy workload attributes where needed. You can still align governance. You just stop pretending the populations are identical.

The architect's mistake: tactical granularity too early

Most teams that finally commit to an agent schema make the same second mistake: they overengineer it.

They try to encode every nuanced runtime trait into attributes on day one. They turn schema design into a cataloging exercise. They create dozens of values nobody will govern consistently.

Do not do that.

Strategic schema design means defining long-lived control boundaries, not short-lived implementation detail. Microsoft documents clear limits and lifecycle constraints on custom security attributes, including tenant-level definition caps and immutable naming characteristics, which is exactly why restraint is a design virtue (limits and constraints, Graph overview).

Start with coarse boundaries that support high-impact policy outcomes you know you will still care about two years from now.

Two coarse boundaries worth defining first

First boundary: approved workload state.

If your operating model says "no AI agent should sign in until explicitly approved," then encode exactly that as a first-class classification and enforce from there. This is the kind of architectural control objective that survives platform changes.

Second boundary: department trust segmentation.

If your operating model says "financial department agents should only authenticate within finance-defined trust boundaries," then encode that boundary at classification level before you layer finer controls. Entra policy and filtering surfaces are strongest when your classes reflect organizational trust zones, not implementation trivia (attribute-driven Conditional Access for agents, autonomous agent policy walkthrough).

These are strategic guardrails. The fine-grained boundaries should come from additional controls and deeper policy patterns, which we can cover in follow-up pieces.

Governance is part of schema, not a separate phase

Custom security attributes are security-sensitive by design, and Entra uses dedicated attribute roles for definition and assignment. Even Global Administrator is not automatically enough for these operations by default (custom security attribute roles, permissions reference).

Treat that as a feature, not friction.

Your schema decision should include explicit ownership for:

  • who defines agent attribute sets and values,
  • who is allowed to assign and update values on agent identities,
  • how schema changes are reviewed when agent programs evolve.

If those answers are not defined with the schema, your taxonomy will drift faster than your policies can keep up.

The practical position

Could you reuse your current workload identity schema for AI agents? Yes.

Should you, by default, in a large regulated enterprise? Usually no.

The better default is a dedicated agent schema with a small number of coarse, policy-driving attributes. Make the boundaries obvious. Keep the vocabulary stable. Optimize for long-term policy clarity, not short-term convenience.

This is architecture work in the most literal sense: defining the shape of control before control logic gets complicated.

We already did this in this series when discussing dynamic consent accumulation and agent governance pressure in [[The-Overlooked-Gem-in-Microsoft-Entra]] and [[Your-Agent-Is-Becoming-the-Crown-Jewel]]. This article just names the next prerequisite: the classification layer that keeps your controls honest.

If you delay this decision, every downstream guardrail becomes harder to reason about.

References