Use custom security attributes as the governance metadata layer for AI agents

This article is part of a multi-part series on Microsoft Entra Agent ID governance. For the full sequence and recommended reading order, start from the Governing AI agents with Microsoft Entra Agent ID and Agent 365

Once the agent inventory is complete and ownership gaps are understood, the next question is simple: how do we govern agents at scale without managing every agent one by one?

This is where custom security attributes become useful.

Inventory tells us what exists. Owners and sponsors tell us who is accountable. Custom security attributes give us a structured way to describe each agent with trusted governance metadata — for example, whether the agent is approved, what environment it belongs to, what type of access pattern it uses, and how sensitive its data access may be.

The goal is not to create labels for the sake of labelling. The goal is to create a metadata layer that downstream controls can use consistently across Conditional Access, access packages, lifecycle reviews, reporting, and monitoring.

Why custom security attributes matter

In a small environment, an administrator might manually review a handful of agents and decide what should happen next. That does not scale when hundreds or thousands of agents exist across platforms.

Custom security attributes help move the model from manual selection to attribute-driven governance.

Instead of creating separate policies or decisions for individual agents, the organisation can assign standard values such as:

• ApprovalStatus = Approved
• Environment = Prod
• DataSensitivity = Confidential
• AccessPattern = Autonomous
• OwnershipStatus = Complete

These values turn agent governance into a repeatable model. Once the values are populated and trusted, policy and reporting can operate against the metadata instead of against individual agent names.

Suggested attribute set

Create a dedicated attribute set for agent governance, for example:

AgentGovernance

This keeps agent-specific governance metadata separate from other business, HR, application, or user lifecycle attributes.

A focused attribute set also makes role delegation cleaner. Only the right governance or automation roles should be able to define or update these values.

Recommended starter schema

Start small. Do not create too many attributes on day one. The initial schema should contain fields that directly support governance decisions.

Attribute	Recommended	Example values	Purpose
ApprovalStatus	Yes	New, ReviewRequired, Approved, Rejected, Revoked	Indicates whether the agent is allowed to move into governed or production-ready state.
Environment	Yes	Dev, Test, Prod, Sandbox	Separates production agents from non-production or test agents.
DataSensitivity	Yes	Public, Internal, Confidential, Restricted	Helps drive review depth, access decisions, and monitoring priority.
AccessPattern	Yes	OBO, Autonomous, AgentUser, Unknown	Identifies whether the agent acts on behalf of a user, independently, or with its own user-like identity.
SourcePlatform	Yes	CopilotStudio, AgentBuilder, Foundry, Bedrock, Vertex, Custom, Unknown	Identifies where the agent came from and which governance path may apply.
BusinessCriticality	Recommended	Low, Medium, High, MissionCritical	Helps prioritise governance, review frequency, and escalation paths.
OwnershipStatus	Recommended	Complete, MissingOwner, MissingSponsor, Orphaned	Tracks whether the agent has the required accountability model.
LifecycleState	Recommended	Active, UnderReview, Retiring, Disabled	Tracks where the agent is in its operational lifecycle.
EnforcementRing	Optional	Ring0ReportOnly, Ring1Pilot, Ring2Enforced	Supports phased rollout of Conditional Access and other controls.
ExceptionId	Optional	EXC-12345	References an approved exception process without storing long free-text notes.

This schema is intentionally simple. It gives enough structure to start governing agents without overengineering the metadata model.

Role and permission model

Custom security attributes should not be treated like normal free-form directory fields. They can contain governance-sensitive information such as risk tier, sensitivity, approval state, or compliance status.

Access to define and assign these attributes should be tightly controlled.

Role	Purpose	Suggested holder
Attribute Definition Administrator	Creates and manages attribute sets and definitions.	Small IAM, Entra governance, or security architecture group.
Attribute Assignment Administrator	Assigns or updates attribute values on objects.	Controlled automation identity or limited operations team.
Attribute Definition Reader	Reads attribute definitions and schema.	Security architecture, audit, or governance reviewers.
Attribute Assignment Reader	Reads assigned attribute values.	Security operations, compliance, or reporting teams.

Use Privileged Identity Management where possible for human access. People should activate elevated roles only when needed. For bulk or recurring updates, use a controlled automation identity with the minimum permissions required.

The key design point is this: the Entra administrator should own the schema and control plane, but should not be the person deciding every agent’s business sensitivity or approval status.

Where the values should come from

Custom security attribute values should be the result of a governance process, not guesswork.

Input	Suggested source
Business purpose	Agent maker, owner, or business sponsor
Source platform	Inventory and platform export
Access pattern	Platform owner, developer, or identity review
Data sensitivity	Data owner, security team, or governance team
Business criticality	Business sponsor
Approval status	Governance or approval process
Ownership status	Inventory owner/sponsor review
Lifecycle state	Remediation or operational workflow

For existing agents, values can be backfilled from the inventory exercise. For new agents, the organisation should define a gatekeeping model so required values are captured before the agent is considered production-ready.

Recommended operating model

A practical operating model looks like this:

1. Define the schema

   • Agree the attribute set, attribute names, and allowed values.

2. Map inventory data

   • Use the inventory to identify known values such as source platform, identity state, owner, sponsor, and current governance status.

3. Validate business inputs

   • Ask the maker, owner, or sponsor to confirm business purpose, sensitivity, and criticality.

4. Assign attributes

   • Use a controlled process, bulk update, or automation to stamp approved values.

5. Flag unknowns

   • Agents with missing or unclear metadata should remain in ReviewRequired.

6. Use attributes for policy

   • Conditional Access, access packages, monitoring, and lifecycle workflows can use the attributes as decision inputs.

Design considerations

Keep these points in mind before creating the schema:

• Prefer predefined values over free text.
• Keep values short, stable, and easy to report on.
• Do not store secrets, credentials, personal data, or long business justification text in attributes.
• Avoid creating too many fields at the beginning.
• Validate that the relevant agent identity objects can be assigned attributes in the customer tenant.
• Treat Unknown and ReviewRequired as valid governance states, not failures.
• Design the schema before bulk assignment; changing attribute structure later can be harder than changing values.
• Keep exception handling separate using an exception ID or reference rather than embedding long exception details into the attribute value.

How this helps the next phase

Once custom security attributes are populated, the organisation can move from descriptive governance to enforceable governance.

For example:

• Conditional Access can target agents where ApprovalStatus = Approved.
• Unknown or rejected agents can be blocked or kept out of enforcement-ready groups.
• Sensitive agents can be placed into stricter review or monitoring paths.
• Access packages can be scoped to approved agents with known business purpose.
• Lifecycle workflows and reporting can use ownership or lifecycle values to detect stale or orphaned agents.

This makes the governance model scalable. Administrators no longer need to select hundreds of agents manually. They govern based on trusted metadata.

Wrap-up

Custom security attributes are the bridge between inventory and enforcement.

They convert raw inventory findings into standard governance values that policies, reports, and lifecycle processes can use consistently. Once the attribute model is in place, the organisation is ready to design Conditional Access policies for agent identities based on approval state, access pattern, environment, risk, and sensitivity.