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.
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.
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.
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.
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.
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. A practical operating model looks like this:
Define the schema
Map inventory data
Validate business inputs
Assign attributes
Flag unknowns
ReviewRequired
.Use attributes for policy
Keep these points in mind before creating the schema:
Unknown
and ReviewRequired
as valid governance states, not failures.Once custom security attributes are populated, the organisation can move from descriptive governance to enforceable governance.
For example:
ApprovalStatus = Approved
.This makes the governance model scalable. Administrators no longer need to select hundreds of agents manually. They govern based on trusted metadata.
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.