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 = ApprovedEnvironment = ProdDataSensitivity = ConfidentialAccessPattern = AutonomousOwnershipStatus = 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:
Define the schema
- Agree the attribute set, attribute names, and allowed values.
Map inventory data
- Use the inventory to identify known values such as source platform, identity state, owner, sponsor, and current governance status.
Validate business inputs
- Ask the maker, owner, or sponsor to confirm business purpose, sensitivity, and criticality.
Assign attributes
- Use a controlled process, bulk update, or automation to stamp approved values.
Flag unknowns
- Agents with missing or unclear metadata should remain in
ReviewRequired.
- Agents with missing or unclear metadata should remain in
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
UnknownandReviewRequiredas 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.