Enterprise architects: your overdue Entra decision is an agent CSA schema

Enterprise architects should prioritize designing custom security attribute schemas for Microsoft Entra agent identities upfront, rather than treating classification as an afterthought. Microsoft's custom security attributes enable tenant-scoped key-value classifications that drive Conditional Access policy evaluation at token issuance, and a dedicated schema for agent identities prevents semantic collision with existing workload identity taxonomies.

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 https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview . 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. 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 https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview , Graph model https://learn.microsoft.com/en-us/graph/api/resources/custom-security-attributes-overview?view=graph-rest-1.0 , agent identity service principal model https://learn.microsoft.com/entra/agent-id/agent-service-principals . 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 https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id attribute-driven-conditional-access . In other words: if your classification is sloppy, your runtime decisions are sloppy. 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 https://learn.microsoft.com/entra/agent-id/agent-service-principals . 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 https://learn.microsoft.com/entra/agent-id/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. 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. 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 https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview limits-and-constraints , Graph overview https://learn.microsoft.com/en-us/graph/api/resources/custom-security-attributes-overview?view=graph-rest-1.0 . Start with coarse boundaries that support high-impact policy outcomes you know you will still care about two years from now. 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 https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id attribute-driven-conditional-access , autonomous agent policy walkthrough https://learn.microsoft.com/en-us/entra/identity/conditional-access/agent-id/policy-autonomous-agents allow-only-specific-agents-to-access-resources . 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. 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 https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview custom-security-attribute-roles , permissions reference https://learn.microsoft.com/entra/identity/role-based-access-control/permissions-reference attribute-assignment-administrator . Treat that as a feature, not friction. Your schema decision should include explicit ownership for: If those answers are not defined with the schema, your taxonomy will drift faster than your policies can keep up. 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.