DEV Community: stepbystep tocloud

Putting the agent governance model into production

stepbystep tocloud — Thu, 09 Jul 2026 15:17:58 +0000

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

By this point, the governance design is no longer theoretical. The organisation has a defined path for discovering agents, classifying them, assigning accountability, applying custom security attributes, designing Conditional Access policies, governing access through access packages, maintaining sponsor continuity, and monitoring risk.

The final step is to turn these design areas into a practical production rollout plan.

This is where many governance efforts fail. The architecture may be sound, but if the rollout is too broad, too manual, or unclear to operational teams, it becomes difficult to sustain. The goal should be a phased rollout that proves the model with a small controlled set of agents before expanding to the wider estate.

Start with a pilot, not the full estate

Do not try to govern every agent on day one.

Start with a representative pilot group that includes different agent types and governance states. The pilot should include a mix of:

One or more Microsoft Entra Agent ID-backed agents
A few approved production agents
A few agents with missing owner or sponsor
One or two unknown or ReviewRequired agents
An agent with higher sensitivity or business criticality
If available, a third-party or registry-synced agent for comparison

This helps validate whether the governance model works across real scenarios. It also helps confirm where controls apply cleanly and where additional validation is required.

Define rollout phases clearly

A practical rollout can be structured into phases.

Phase	Focus	Outcome
Phase 1	Inventory and classification	Agents visible and grouped by source, identity model, owner, sponsor, and access pattern
Phase 2	Accountability cleanup	Missing owners, sponsors, orphaned agents, and unknown agents identified and actioned
Phase 3	Custom security attributes	Approved schema created and pilot agents tagged with governance metadata
Phase 4	Conditional Access report-only	Agent policies tested without enforcement
Phase 5	Access package pilot	Approved agents receive governed, time-bound access
Phase 6	Lifecycle workflow pilot	Sponsor transition scenarios validated
Phase 7	Monitoring and operations	Risk review, access expiry, attribute drift, and ownership hygiene become recurring checks
Phase 8	Wider enforcement	Controls expanded from pilot to production cohorts

This phased approach avoids accidental blocking and gives the customer confidence before enforcement.

Define decision gates

Each phase should have a decision gate. A decision gate is a simple checkpoint that confirms whether the customer is ready to move to the next stage.

For example:

Gate	Question to answer
Inventory gate	Do we know what agents exist and where they came from?
Classification gate	Do we know which agents are Agent ID-backed, legacy, third-party, shadow, system-generated, or unknown?
Accountability gate	Do production agents have valid owners and sponsors?
Metadata gate	Are required custom security attributes populated?
Policy gate	Have Conditional Access policies been tested in report-only mode?
Access gate	Are access packages designed only for approved agents with clear business purpose?
Lifecycle gate	Do sponsor transition workflows have reliable manager and lifecycle data?
Monitoring gate	Is there a recurring process to review risky agents, orphaned agents, and stale access?

This keeps the rollout controlled and measurable.

Recommended minimum production baseline

Before an agent is considered production-ready, it should meet a minimum governance baseline.

Requirement	Why it matters
Agent is inventoried	Establishes visibility
Source platform is known	Determines governance path
Identity model is known	Confirms which controls apply
Access pattern is known	Determines Conditional Access model
Owner is assigned	Provides technical accountability
Sponsor is assigned	Provides business accountability
Business purpose is documented	Confirms why agent exists
Data sensitivity is classified	Helps define risk posture
Approval status is populated	Lets policies distinguish approved and unapproved agents
Lifecycle state is known	Supports review, retirement, and monitoring

If these values are missing, the agent should remain in ReviewRequired state.

Rollout should be policy-light at first

Initial rollout should avoid creating too many policies.

Start with a small number of meaningful controls:

A report-only Conditional Access policy for approved autonomous agents
A block or review policy for rejected or unknown agents
A risk-based policy for high-risk agent identities
One or two access packages for common approved access patterns
One lifecycle workflow for sponsor leave or role-change scenarios
One drift report for missing owner, sponsor, or required attributes

This gives the customer a working governance model without creating unnecessary policy sprawl.

Keep exception handling explicit

Every governance model needs an exception path.

Some agents may not fully fit the target design immediately. Some may be legacy. Some may be third-party. Some may not yet support the preferred identity model. The important point is that exceptions are visible, approved, time-bound, and reviewed.

Good exception handling should include:

Exception ID
Agent name
Business justification
Owner
Sponsor
Risk accepted by
Expiry date
Review date
Compensating controls
Final disposition

Avoid permanent exceptions wherever possible.

Define operational ownership

Production governance needs clear ownership across teams.

Area	Primary owner
Inventory reporting	IAM, platform team, or AI governance team
Owner and sponsor cleanup	Business sponsors, platform owners, identity governance team
Custom security attribute schema	IAM or Entra governance team
Attribute assignment process	IAM operations, automation team, or delegated governance team
Conditional Access policies	IAM / security team
Access packages	Identity governance team with resource owners
Lifecycle workflows	Identity governance team
Risk review	Security operations / identity protection team
Agent retirement	Platform owner, sponsor, and IAM team

This prevents the common problem where central IT becomes responsible for every business decision about every agent.

Production rollout checklist

Use this checklist before scaling wider.

Agent inventory completed
Classification model agreed
Owner and sponsor model agreed
Orphaned agent process defined
Custom security attribute schema approved
Attribute assignment owner identified
Initial attributes populated for pilot agents
Conditional Access policies created in report-only mode
Sign-in and policy impact reviewed
Access package model validated
Sponsor request or approval process validated
Lifecycle workflow pilot validated
High-risk agent review process defined
Monitoring cadence agreed
Exception process documented
Rollout ring model approved

Suggested rollout rings

Roll out in rings rather than one broad change.

Ring	Scope
Ring 0	Lab or test agents
Ring 1	Small pilot group of approved agents
Ring 2	Production agents with complete metadata
Ring 3	Wider agent estate
Ring 4	Enforcement for unknown, rejected, or unmanaged agents

This lets the organisation move from visibility to enforcement safely.

What success looks like

A mature production rollout should result in:

Every agent has a known governance state
Production agents have owners and sponsors
Unknown agents are not silently trusted
Custom security attributes support policy targeting and reporting
Conditional Access policies are scoped using trusted metadata
Access packages provide approved, time-bound access
Sponsor lifecycle changes do not create orphaned agents
Risky agents are reviewed and actioned
Exceptions are documented and time-bound
Governance is repeatable for new agents, not just existing ones

Wrap-up

The production rollout is where the governance model becomes real. Do not move directly from design to broad enforcement. Start with a pilot, define decision gates, use report-only policies, validate access packages, test lifecycle workflows, and build monitoring into regular operations.

The goal is not to create the most complex governance design. The goal is to create a model the customer can operate repeatedly: every agent known, classified, accountable, approved, governed, monitored, and eventually retired when no longer needed.

Build an operating model for AI agent governance

stepbystep tocloud — Thu, 09 Jul 2026 15:15:54 +0000

By this point in the series, the governance building blocks are in place.

You have inventoried the agents, classified them, assigned owners and sponsors, added custom security attributes, designed Conditional Access policies, introduced access packages, configured sponsor continuity, and defined monitoring practices.

The next step is to turn all of this into an operating model.

Without an operating model, agent governance can easily become a collection of disconnected controls. One team maintains inventory, another team owns Conditional Access, another reviews access packages, and another responds to risk. The controls exist, but the process is unclear.

A good operating model answers one practical question:

How does an agent move from creation to approved use, ongoing review, and eventual retirement?

Why an operating model matters

AI agents are not static objects. New agents are created, old agents become unused, sponsors change roles, access requirements evolve, and risk signals may appear over time.

If the organisation only completes a one-time cleanup, the estate will drift again. New agents may appear without owners, unclassified agents may remain active, or approved agents may keep access longer than required.

The operating model keeps governance repeatable.

It defines:

Who provides metadata
Who approves the agent
Who assigns ownership and sponsorship
Who validates data sensitivity
Who applies governance attributes
Who reviews risky agents
Who approves access packages
Who retires or disables agents

The goal is not to make central IT responsible for every detail. The goal is to create shared accountability across makers, sponsors, security, identity, platform, and operations teams.

The recommended governance flow

A practical lifecycle for agent governance can be structured like this:

Stage	Purpose	Output
Discover	Identify agents across platforms	Agent added to inventory
Classify	Determine source, identity model, and access pattern	Agent placed into governance bucket
Assign accountability	Confirm owner, sponsor, and business purpose	Agent becomes accountable
Tag with governance metadata	Populate custom security attributes	Agent becomes policy-addressable
Approve or reject	Decide if agent can move forward	ApprovalStatus updated
Apply access controls	Use Conditional Access and access packages	Agent access governed
Monitor	Review risk, access, ownership, and activity	Agent remains trusted
Retire	Disable or remove agents no longer needed	Agent lifecycle closed

This keeps governance simple: every agent should have a known state and a clear next action.

Suggested agent governance states

Use a small set of governance states that everyone understands.

Governance state	Meaning	Recommended action
New	Agent newly discovered or created	Add to inventory and classify
ReviewRequired	Required metadata or accountability missing	Do not treat as production-ready
Approved	Agent has required metadata, owner, sponsor, and business justification	Eligible for policy and access design
Rejected	Agent not approved for use	Block, disable, or prevent access based on policy
Orphaned	No valid owner or sponsor	Run claim-or-retire process
Retiring	Agent no longer needed but cleanup not complete	Remove access and disable safely
Disabled	Agent no longer allowed to operate	Confirm access and assignments removed

Screenshot: Governance state view showing New, ReviewRequired, Approved, Orphaned, Retiring and Disabled agents

These states help reduce confusion. Instead of arguing whether an agent is “good” or “bad”, the organisation can ask: what state is this agent in, and what action does that state require?

Define roles and responsibilities

Agent governance works best when responsibilities are clear.

Role or team	Responsibility
Agent maker or developer	Provides purpose, platform, data sources, access pattern, and technical details
Technical owner	Maintains configuration, connectors, runtime, and operational support
Business sponsor	Confirms business need, approves continued use, and supports lifecycle decisions
Security governance team	Reviews risk, sensitivity, policy impact, and approval criteria
IAM / Entra team	Owns identity governance model, Conditional Access design, custom security attribute schema
Platform team	Supports Copilot Studio, Agent Builder, Foundry, or third-party platform controls
Operations team	Reviews drift reports, orphaned agents, risky agents, and access expiry
Automation team	Builds scripts, flows, or integrations to update metadata and reduce manual effort

A mature model does not expect the Entra administrator to decide every value manually. The Entra team owns the control plane, but business and security teams provide the decisions that determine approval, sensitivity, and risk.

New agent onboarding gate

The operating model should include a gate for newly created agents.

Before an agent becomes production-ready, it should have minimum required information:

Required field	Why it matters
Owner	Technical accountability
Sponsor	Business accountability
Business purpose	Explains why the agent exists
Source platform	Determines governance path
Environment	Separates production from test or sandbox
Access pattern	Determines Conditional Access and access governance model
Data sensitivity	Drives risk and protection decisions
Business criticality	Helps prioritise monitoring and review
Approval status	Determines whether access should be allowed

If required metadata is missing, the agent should remain in ReviewRequired state.

This does not mean every agent must be blocked immediately. It means the agent should not be treated as fully approved or policy-ready until the required information is complete.

Existing agent remediation

For existing agents, use the inventory to drive remediation.

Finding	Action
Missing owner	Assign or confirm technical owner
Missing sponsor	Assign business sponsor
No owner and no sponsor	Mark as Orphaned and run claim-or-retire process
Unknown source platform	Validate platform or registry origin
Unknown access pattern	Review authentication and runtime behaviour
Unknown data sensitivity	Ask owner, sponsor, or data governance team to classify
Approved but missing metadata	Move back to ReviewRequired until corrected
Retired but still active	Remove access and disable

The aim is to convert the existing estate from unclear to governed.

Automation and manual process balance

Not every customer needs heavy automation from day one.

A small estate may start with manual review and periodic bulk updates. A large estate with hundreds or thousands of agents needs automation or structured workflows to avoid daily manual housekeeping.

A practical maturity model looks like this:

Maturity level	Approach
Level 1: Manual	Inventory reviewed periodically, attributes updated by authorised admins
Level 2: Bulk-assisted	Export inventory, validate in tracker, bulk update attributes using approved scripts
Level 3: Workflow-driven	Intake, sponsor approval, security review, and metadata stamping handled through workflow
Level 4: Integrated	Agent creation pipeline captures metadata and stamps governance values automatically where supported

The recommended start is simple: define the required metadata and approval states first. Automation can come after the process is clear.

Policy enforcement model

Once governance states and attributes are trusted, enforcement becomes easier.

Example policy logic:

Condition	Governance action
ApprovalStatus = Approved	Eligible for access controls and access packages
ApprovalStatus = ReviewRequired	Do not grant production access
ApprovalStatus = Rejected	Block or disable based on policy
OwnershipStatus = Orphaned	Escalate for claim-or-retire review
DataSensitivity = Restricted	Require stricter approval and monitoring
AgentRisk = High	Block, investigate, or move agent back to ReviewRequired

This keeps policy decisions based on trusted metadata rather than manual agent selection.

Recommended implementation sequence

A customer can implement the operating model in phases.

Create the inventory
- Collect agents from Agent 365, Microsoft Entra, platform-native exports, registry sync, and third-party sources.
Classify the estate
- Identify Agent ID-backed agents, legacy app registrations, service principals, Agent Builder agents, registry-synced agents, shadow AI, system objects, and unknowns.
Fix accountability
- Assign missing owners and sponsors.
- Mark unclaimed agents as Orphaned or ReviewRequired.
Define custom security attributes
- Start with ApprovalStatus, Environment, DataSensitivity, AccessPattern, SourcePlatform, OwnershipStatus, and LifecycleState.
Backfill existing agents
- Populate known values.
- Keep unclear values as Unknown or ReviewRequired.
Create the onboarding gate
- Require minimum metadata before agents are considered production-ready.
Design Conditional Access
- Start with report-only.
- Use custom security attributes for scalable targeting.
Introduce access packages
- Use for approved agents that need durable access to groups, roles, or API permissions.
Enable lifecycle workflows
- Maintain sponsorship continuity when sponsors move roles or leave.
Monitor continuously

Review risky agents, owner/sponsor drift, access package expiry, audit logs, and stale attributes.

What good looks like

A healthy operating model should make these statements true:

Every production-ready agent is inventoried.
Every governable agent has an owner and sponsor.
Every approved agent has required custom security attributes populated.
Unknown agents are not silently trusted.
Orphaned agents are reviewed, claimed, retired, or disabled.
Conditional Access policies are based on access pattern and trusted metadata.
Access packages provide time-bound, approval-based access.
Sponsor changes are handled through lifecycle workflows.
Risky agents are reviewed and actioned.
Monitoring detects drift before it becomes a governance problem.

Wrap-up

Agent governance is not a one-time configuration activity. It is an operating model.

Inventory provides visibility. Ownership and sponsorship provide accountability. Custom security attributes provide scalable metadata. Conditional Access provides enforcement. Access packages provide governed access. Lifecycle workflows maintain continuity. Monitoring keeps the model current.

The strongest design is not the one with the most controls. It is the one where every agent has a known state, a responsible person, an approved purpose, and a clear path from creation to retirement.

Monitor risky agents and keep agent governance current

stepbystep tocloud — Thu, 09 Jul 2026 15:15:01 +0000

Agent governance does not finish when inventory, custom security attributes, Conditional Access policies, access packages, and lifecycle workflows are configured. That is only the foundation.

The real operating model starts after that.

Agents will continue to be created. Sponsors will move roles. Access packages will expire. Some agents may become risky. Some may become unused. Some may lose ownership. If the organisation does not monitor these signals, the governance model will slowly become stale.

The final stage of the agent governance journey is continuous monitoring and operational review.

Why monitoring matters

A governed agent estate should not be treated as a one-time project. It should behave more like an identity governance programme.

The organisation should be able to answer these questions on an ongoing basis:

Are any agents currently risky?
Are any agents accessing resources unexpectedly?
Are any agents missing owners or sponsors?
Are any approved agents no longer used?
Are access package assignments nearing expiry?
Have any agents lost their sponsor due to role change or departure?
Are custom security attributes still accurate?
Are Conditional Access policies working as expected?
Are any agents still in ReviewRequired state for too long?

If these questions are not reviewed periodically, the environment may drift back into unmanaged state.

What to monitor

The monitoring layer should focus on a few practical areas instead of trying to inspect every detail manually.

Monitoring area	Why it matters	Recommended action
Risky agents	Agent identities may show risky behaviour or unusual access patterns.	Review high-risk agents, block access if required, disable the agent, or move it back to `ReviewRequired`.
Sign-in logs	Shows whether agents are authenticating and accessing resources as expected.	Validate Conditional Access impact and check unexpected access behaviour.
Audit logs	Helps track changes to agent identity, ownership, sponsorship, attributes, and access assignments.	Review important changes and investigate unauthorised or unexpected updates.
Owner and sponsor gaps	Agents without accountability become governance risks.	Re-run ownership and sponsorship gap reports periodically.
Access package expiry	Agent access should not remain permanent without review.	Track expiring assignments and ensure sponsor or approver validates continued need.
Custom security attribute drift	Incorrect attribute values can lead to wrong policy targeting.	Review agents with missing, stale, or inconsistent attribute values.
Conditional Access impact	Policies may block or allow agents unexpectedly if scope is wrong.	Review report-only results and policy impact before broad enforcement.
Lifecycle workflow outcomes	Sponsor transition workflows depend on accurate user and manager data.	Verify sponsorship transfers and notifications worked as expected.

Review high-risk agents

Identity Protection for agents should be treated as an operational review point.

If an agent is marked as high risk, the organisation should not simply ignore the signal. The response should depend on the agent’s business criticality, access level, and sensitivity.

Recommended actions include:

Review the agent’s recent sign-in and audit activity.
Confirm the agent’s owner and sponsor.
Validate whether the agent still has a valid business purpose.
Check access package assignments and resource permissions.
Move the agent to ReviewRequired if the risk is unclear.
Block access through Conditional Access if required.
Disable the agent identity if immediate containment is needed.
Retire the agent if it is no longer required.

The key point is that risky agents should not remain silently approved.

Use governance states to drive action

The monitoring process becomes easier when agents have clear governance states.

Governance state	Meaning	Monitoring action
Approved	Agent is classified, accountable, and allowed to operate.	Monitor normally.
ReviewRequired	Agent has missing or uncertain metadata, risk, or ownership issue.	Do not treat as production-ready until reviewed.
Rejected	Agent should not be used.	Ensure access is blocked or removed.
Orphaned	Agent has no valid owner or sponsor.	Start claim-or-retire process.
Retiring	Agent marked for removal or decommissioning.	Track until disabled or deleted.
Disabled	Agent no longer allowed to operate.	Confirm access and assignments removed.

These states should be reflected in custom security attributes or the governance tracker so that operations teams can filter and act quickly.

Monitor Conditional Access effectiveness

Conditional Access policies for agents should be reviewed after deployment.

The review should check whether policies are doing what they were designed to do:

Approved agents can access expected resources.
Rejected or unknown agents are blocked.
Risky agent identities are blocked or restricted.
Report-only policies are showing expected impact.
No business-critical agent is unintentionally blocked.
Policies are scoped to the correct access pattern.

This is especially important because on-behalf-of agents, autonomous agents, and agent users may follow different access models.

A strong review question is:

Is this policy controlling the right identity subject for the right access pattern?

If the answer is unclear, reassess the policy before enforcement.

Monitor access package lifecycle

Access packages provide time-bound access, but they only deliver value if expiry and extension are reviewed.

For agents, access package monitoring should focus on:

Assignments nearing expiry.
Sponsors requesting extensions.
Assignments with no sponsor action.
Agents with access packages but missing valid sponsor.
High-risk agents with active access assignments.
Agents that no longer need access but still hold assignment.

The recommendation is simple: approved access should not become permanent access by accident.

If access is still needed, extension should follow approval. If no one validates the need, access should expire.

Review owner and sponsor health

Owner and sponsor data should be reviewed periodically.

Useful checks include:

Agents with no owner.
Agents with no sponsor.
Agents where owner or sponsor has left the organisation.
Agents where sponsor changed role.
Agents where only technical owner exists but no business sponsor.
Agents where sponsor exists but business purpose is unclear.

This connects directly with lifecycle workflows. If sponsor transition workflows run, the organisation should still validate whether the new sponsor is appropriate.

Automatic transfer can help continuity, but it should not replace business accountability review.

Watch for custom security attribute drift

Custom security attributes are only useful if they remain accurate.

Common drift examples:

Agent marked Approved but sponsor missing.
Agent marked Prod but actually used for testing.
Agent marked Low sensitivity but now accesses confidential data.
Agent still marked ReviewRequired after approval completed.
Agent owner changed but OwnershipStatus not updated.
Agent retired but still marked Active.

Build a simple periodic review around these mismatches.

The goal is not perfect metadata. The goal is trusted enough metadata to drive policy decisions safely.

Suggested operational cadence

The cadence can vary by organisation size and risk, but the operating model should include recurring checks.

Cadence	Review item
Daily or frequent	High-risk agents, blocked access events, critical policy failures.
Weekly	New agents, agents in `ReviewRequired`, owner or sponsor gaps, report-only CA impact.
Monthly	Access package expiry, sponsor validity, orphaned agents, attribute drift.
Quarterly	Overall agent governance posture, policy effectiveness, exception review, retired agent cleanup.

For large environments, this should be report-driven and automated where possible. For smaller environments, a lightweight review process may be enough.

What good looks like

A mature agent governance monitoring model should show:

Every production agent has owner and sponsor.
Every approved agent has required custom security attributes.
Unknown agents remain under review and are not silently trusted.
Risky agents are reviewed and actioned.
Agent access is time-bound where appropriate.
Access extensions require sponsor or approver validation.
Conditional Access policies are reviewed before enforcement.
Lifecycle workflow outcomes are validated.
Retired or orphaned agents are removed or disabled.
Governance dashboards show actionable exceptions, not just raw inventory.

Final operating model

The complete governance journey should now look like this:

Inventory agents across platforms.
Classify source, identity model, and access pattern.
Assign accountability with owners and sponsors.
Populate custom security attributes for governance metadata.
Apply Conditional Access using approval state, risk, and access pattern.
Use access packages for governed, time-bound access.
Use lifecycle workflows to maintain sponsor continuity.
Monitor continuously through risk, logs, access expiry, and metadata drift.

Wrap-up

Monitoring is what keeps agent governance alive.

Inventory creates visibility. Custom security attributes create structure. Conditional Access and access packages create control. Lifecycle workflows maintain accountability. Monitoring ensures the model does not drift over time.

For AI agents, the goal is not just to approve access once. The goal is to continuously confirm that each agent is still known, accountable, justified, correctly classified, and operating within policy.

Next in the series (Bonus): Putting the agent governance model into production

Maintain sponsor continuity with lifecycle workflows

stepbystep tocloud — Thu, 09 Jul 2026 15:13:48 +0000

Agent governance does not end when an agent is inventoried, classified, approved, and granted access. The people accountable for that agent can change. A sponsor may move to another role, leave the organisation, or no longer be the right person to make lifecycle decisions for that agent.

That is why sponsor continuity matters.

If an agent continues to exist after its sponsor has moved or left, the organisation can end up with an active agent that still has access, but no clear business owner. Lifecycle workflows help reduce that risk by keeping sponsorship aligned with organisational changes.

Why this matters

Owners and sponsors are not just informational fields.

The owner helps with technical administration and operational support. The sponsor provides business accountability: why the agent exists, whether it should continue to exist, whether it still needs access, and whether access should be extended or removed.

When the sponsor changes roles or leaves the company, that accountability chain can break.

Without a sponsor-continuity process, agents can become:

Orphaned, because no one remains accountable.
Over-permissioned, because access continues without review.
Operationally unclear, because no one knows who should approve changes.
Riskier over time, because access and purpose are no longer actively validated.

Lifecycle workflows provide a way to handle this as part of the normal identity governance lifecycle.

Where lifecycle workflows fit in the journey

Lifecycle workflows should not be the first step in agent governance. They become meaningful after the earlier foundations are in place.

The recommended sequence is:

Inventory agents
Classify identity model and access pattern
Assign owners and sponsors
Populate custom security attributes
Design Conditional Access policies
Use access packages for governed access
Use lifecycle workflows to maintain sponsor continuity
Monitor risk, access expiry, and governance drift

The key point is simple: lifecycle workflows help keep the governance model current after it has been established.

What lifecycle workflows help with

Lifecycle workflows are useful when there is a change in the human accountability layer around an agent.

Common scenarios include:

Scenario	Why it matters	Recommended action
Sponsor leaves the organisation	Agent may become orphaned	Notify manager or co-sponsors, transfer sponsorship where appropriate
Sponsor changes role	Sponsor may no longer be the right business accountable person	Notify relevant stakeholders and review whether sponsorship should change
Sponsor no longer owns the business process	Agent may need a new business accountable owner	Reassign sponsor or mark agent for review
Agent access is tied to sponsorship	Access extensions may need business validation	Ensure future approvals go to the right accountable person

The goal is not only notification. The goal is continuity of accountability.

Sponsor lifecycle workflow patterns

There are two useful lifecycle workflow patterns for agent sponsorship.

Workflow pattern	Lifecycle category	Typical trigger	Outcome
Sponsor leaves organisation	Leaver	Leave date, attribute change, or group membership change	Notify manager or co-sponsors, transfer sponsorship, avoid orphaned agents
Sponsor changes roles	Mover	Role, department, job profile, or group membership change	Review sponsorship, notify stakeholders, transfer accountability if needed

Screenshot: Lifecycle workflow template showing sponsor-related tasks for mover and leaver scenarios

What actions should be considered

A lifecycle workflow for sponsor continuity can include actions like:

Notify the sponsor’s manager that sponsorship needs attention.
Notify co-sponsors that the current sponsor has changed roles or left.
Transfer sponsorship to the sponsor’s manager where that is the agreed operating model.
Trigger a review of agents associated with that sponsor.
Move affected agents into a review state if automatic transfer is not appropriate.

Not every organisation should automatically transfer sponsorship to the manager. That depends on the operating model.

For some customers, manager-based transfer is acceptable. For others, sponsorship should move to an application owner, product owner, business process owner, or governance team.

Design decisions before enabling workflows

Before configuring sponsor lifecycle workflows, agree on these decisions.

Design decision	Why it matters
Who should receive sponsor-change notifications?	Manager, co-sponsor, governance team, or platform owner may be more appropriate depending on process
Should sponsorship transfer automatically?	Automatic transfer is useful but may be wrong if manager is not accountable for the business process
What happens if manager data is missing?	Workflow may fail or route accountability incorrectly
What happens if no co-sponsor exists?	Agent may need to be marked as ReviewRequired
Should affected agents be paused or disabled?	High-risk agents may need stronger action until sponsorship is confirmed
Should access packages be reviewed at the same time?	Sponsor changes can affect access extension and approval decisions

This is where governance design matters more than clicking through a template.

Recommended operating model

A practical model is to treat sponsor lifecycle events as governance review triggers.

When a sponsor changes role or leaves:

Identify all agent identities sponsored by that person.
Notify the defined responsible party.
Transfer sponsorship automatically only if the organisation has approved that default behaviour.
If sponsorship cannot be confidently reassigned, mark the agent as ReviewRequired.
Review related access packages and active access assignments.
Confirm whether the agent should remain active, be reassigned, disabled, or retired.

This keeps the workflow aligned to business accountability rather than just directory changes.

Important caveats

Lifecycle workflows depend heavily on identity data quality.

If manager, department, role, group membership, or leave-date information is inaccurate, the workflow may not trigger correctly or may route sponsorship to the wrong person.

Before relying on lifecycle workflows, validate:

Manager data is populated and reliable.
Role or department changes are reflected in Microsoft Entra ID.
Leave-date attributes or group membership changes are maintained correctly.
Sponsors and co-sponsors are already populated for agent identities.
The organisation has agreed what “transfer sponsorship” should mean.

A workflow cannot fix poor governance data. It can only act on the signals available.

How this connects to access packages

Lifecycle workflows and access packages work well together.

Access packages provide time-bound, approval-based access for agents. Sponsors can be involved in access decisions and extension requests. If a sponsor leaves or changes role, access package governance can become stale unless sponsorship is updated.

That is why sponsor continuity should be part of the access governance design.

If an agent has active access package assignments and the sponsor changes, the organisation should review whether:

The access is still required.
The new sponsor understands the business purpose.
The access should be extended, reduced, or allowed to expire.
The agent should remain approved.

How this connects to custom security attributes

Custom security attributes can also reflect lifecycle state.

For example:

Attribute	Example value
`OwnershipStatus`	`Complete`, `MissingSponsor`, `Orphaned`
`LifecycleState`	`Active`, `UnderReview`, `Retiring`, `Disabled`
`ApprovalStatus`	`Approved`, `ReviewRequired`, `Revoked`

When sponsor continuity breaks, the agent can be moved back to a review state until accountability is restored.

That gives Conditional Access, reporting, monitoring, and governance dashboards a consistent signal.

Recommended policy position

Do not treat lifecycle workflows as optional clean-up.

For agent identities, sponsor lifecycle handling should be part of the production governance model. If an agent has access to business data or operational systems, the organisation should know what happens when the person accountable for that agent changes role or leaves.

A good policy statement could be:

Every production agent must have a valid sponsor. If the sponsor changes role or leaves the organisation, sponsorship must be reviewed, transferred, or the agent must be marked as ReviewRequired until accountability is restored.

Wrap-up

Lifecycle workflows help keep agent governance alive after the initial setup. Inventory, classification, owners, sponsors, custom security attributes, Conditional Access, and access packages create the governance model. Lifecycle workflows help preserve that model when people move, leave, or stop being accountable for the agents they sponsor.

The objective is simple: no active production agent should continue indefinitely without a valid business sponsor.

Next in the series: Monitor risky agents and keep governance current

Use access packages for governed agent access

stepbystep tocloud — Thu, 09 Jul 2026 15:13:07 +0000

Conditional Access helps decide whether an approved agent can access a resource under the right policy conditions. Access packages answer a different question: what access should the agent receive, who approves it, and how long should that access remain valid.

This is the right next step after inventory, classification, owner/sponsor cleanup, custom security attributes, and Conditional Access policy design. At this stage, the organisation should already know which agents are approved, who is accountable for them, what access pattern they use, and what sensitivity or business criticality applies.

Access packages should not be used for every discovered agent. They are most useful for approved agents that need durable access to resources such as groups, Microsoft Entra roles, or API permissions. The aim is to avoid permanent, ad hoc permission assignments and move toward access that is intentional, approved, auditable, and time-bound.

Why access packages matter for agents

Agents may need access to resources to complete business tasks. For example, a fleet of customer support agents may need access to the same set of groups, APIs, or directory roles. Without a governed access model, those permissions can become difficult to track, review, and remove.

Access packages provide a structured way to grant access with governance controls around:

Who can request access
Who approves access
What resources are included
How long access lasts
Whether access can be extended
What happens when access expires

This is especially important for agent identities because they may continue operating without day-to-day human interaction. Access should therefore be granted with clear purpose, expiry, and review expectations.

Where access packages fit in the governance sequence

Access packages should come after the agent has already passed the earlier governance checks.

Stage	Purpose
Inventory	Identify the agent and its source platform
Classification	Understand identity model and access pattern
Owner and sponsor assignment	Establish technical and business accountability
Custom security attributes	Record governance metadata like approval status and sensitivity
Conditional Access	Enforce access policy based on identity, risk, and attributes
Access packages	Grant approved, time-bound access to required resources
Lifecycle workflows and monitoring	Keep sponsorship, access, and risk posture current

The key point is simple: do not grant durable access to an agent until it is classified, accountable, and approved.

What agents can receive through access packages

Access packages are useful when approved agents need access to defined resources rather than broad standing permissions.

Common examples include:

Security group memberships
Microsoft Entra directory roles
OAuth application permissions
API permissions such as Microsoft Graph application permissions

This makes access packages suitable for repeatable access patterns. For example, if several approved agents need the same type of access, create a standard access package instead of assigning permissions manually to each agent.

Recommended access package design

Start with a small number of meaningful access packages rather than creating many narrowly scoped packages too early.

Design area	Recommendation
Scope	Use access packages only for approved agents with known purpose and accountability
Resources	Include only the resources the agent needs for the defined scenario
Approval	Route approval to the sponsor, resource owner, application owner, or security governance team
Expiry	Make assignments time-bound by default
Extension	Require re-approval or extension review for continued access
Auditability	Ensure assignments and approvals can be reviewed later
Naming	Use names that explain the agent scenario and access purpose

Example naming pattern:

AP-Agent-CustomerSupport-GraphRead-Prod
AP-Agent-FinanceAutomation-GroupAccess-Prod
AP-Agent-SOCInvestigation-Privileged-ReviewRequired

The name should help an administrator quickly understand who the access is for, what it grants, and whether it is production or review-based.

Request and approval model

Access packages can support different assignment paths:

Assignment path	When it makes sense
Agent identity requests access	Useful for programme-driven or automated access request scenarios
Sponsor requests access for the agent	Useful when human oversight is required before the agent receives access
Administrator directly assigns access	Useful for controlled rollout, pilot, or emergency remediation scenarios

The sponsor-based model is especially valuable. It keeps a human accountable for why the agent needs access and whether that access should continue.

Expiry and extension behaviour

Access packages should not create permanent access by default. The value comes from giving access a lifecycle.

When an access package assignment has an expiry date, the organisation can review whether the agent still needs that access. If the sponsor remains accountable and the access is still valid, an extension can be requested based on policy. If no action is taken, the assignment expires and the agent loses access to the target resources.

This is a clean governance pattern for agents because access does not remain forever simply because it was once approved.

Design caveats

Access packages are powerful, but they should be used carefully.

Do not use access packages as a shortcut to approve unknown agents. If the agent source, identity model, business purpose, owner, sponsor, or access pattern is unclear, keep the agent in ReviewRequired state.

Also avoid reusing access packages that were originally designed for human users if the resource roles or approval model do not fit agent identities. Agent access packages should be designed with agent scenarios in mind.

Key checks before using access packages:

Is the agent approved?
Does the agent have a valid owner and sponsor?
Is the access pattern understood?
Is the business purpose documented?
Are the required resources clearly defined?
Is access time-bound?
Is there a clear approver?
Is there a review or expiry model?

If the answer is unclear, the access package design is not ready.

Recommended operating model

A practical access package operating model for agents can look like this:

Approved agents are identified from the inventory.
Required resource access is mapped to a business scenario.
Access package is created for that scenario.
Sponsor or approver validates the need.
Access is granted with expiry.
Access is reviewed or extended only when justified.
Expired or unused access is removed automatically through the lifecycle process.

This keeps access aligned to business purpose and reduces long-term permission drift.

Example access package patterns

Scenario	Access package idea
Customer support agents	Standard access to support knowledge groups and approved APIs
Security operations agents	Time-bound access to investigation-related resources
Finance automation agents	Controlled access to finance processing groups or APIs
HR assistant agents	Access only to approved HR resources with stricter review
Test or sandbox agents	Limited non-production access with short expiry

The design should follow least privilege. Agents should receive only the access needed for their approved scenario.

How this connects to the next phase

Once access packages are in place, the next concern is lifecycle. Agents may be approved today, but sponsors can change roles, leave the organisation, or stop being accountable for the agent. If sponsorship becomes stale, access decisions become stale too.

That is why the next phase is Lifecycle Workflows for sponsor continuity. Access packages govern what the agent can access. Lifecycle workflows help ensure the people responsible for that access remain current.

Wrap-up

Access packages give agent governance a proper entitlement layer. Conditional Access controls whether the agent can access resources under policy conditions. Access packages control what access the agent receives, who approves it, how long it lasts, and how it expires.

Use access packages for approved agents with clear business purpose and accountability. Keep access time-bound, auditable, and reviewable. This prevents agent permissions from becoming permanent, unmanaged, or disconnected from business ownership.

Next in the series: Maintain sponsor continuity with lifecycle workflows

Design Conditional Access policies for agent identities

stepbystep tocloud — Thu, 09 Jul 2026 15:11:35 +0000

After agent inventory, ownership, sponsorship and custom security attributes are in place, the next step is to turn that governance metadata into policy enforcement. This is where Conditional Access becomes important.

The goal is not to create one policy per agent. That model will not scale. The better approach is to use the information already captured during inventory and classification — such as approval status, access pattern, environment, data sensitivity and risk — to decide which agents should access which resources, and under what conditions.

Conditional Access is the point where the governance model starts becoming enforceable.

Why Conditional Access matters for agents

Agents can access resources in different ways. Some act on behalf of a signed-in user. Some operate independently using their own identity. Some behave more like user accounts with their own mailbox, collaboration context or persistent access.

Because these patterns are different, one Conditional Access design will not fit every agent type.

Before creating policies, classify each agent by access pattern:

Access pattern	What it means	Conditional Access approach
On-behalf-of flow	Agent acts in the signed-in user’s context	Review existing user Conditional Access policies
Autonomous agent	Agent authenticates using its own identity	Use agent-specific Conditional Access policies
Agent user identity	Agent behaves like a user-like identity with its own access	Use agent-user targeting and supported endpoint/network controls

This distinction matters because the policy subject changes. In an on-behalf-of flow, the user is still central to the access decision. In an autonomous agent flow, the agent identity itself becomes the subject of the policy.

Start by reviewing existing user policies

For agents acting on behalf of users, do not immediately assume a new agent-specific policy is required. First review the existing user Conditional Access baseline.

The organisation should confirm whether existing user policies already enforce the expected Zero Trust posture:

Strong authentication or MFA where required
Compliant device or trusted device requirements
Network or location-based controls
Legacy authentication blocking
Resource-specific controls for Microsoft 365, SharePoint, Exchange, Teams, Graph or other sensitive resources
Risk-based user protections where applicable

If the user access path is already well governed, the on-behalf-of agent scenario benefits from those user-context controls. The agent does not bypass the user’s identity governance model simply because it is performing work for the user.

Screenshot: Existing Conditional Access policy templates from portal

Design separate policies for autonomous agents

Autonomous agents need a different approach. These agents authenticate using their own identity and may run without a signed-in user present. They cannot satisfy interactive controls in the same way a human user can.

For these agents, Conditional Access should use agent-specific signals and metadata.

A practical starting point is to use the custom security attributes populated in the previous phase.

Policy pattern	Suggested targeting	Recommended action
Allow only approved agents	`ApprovalStatus = Approved`	Allow access to selected resources
Block rejected agents	`ApprovalStatus = Rejected` or `Revoked`	Block access
Restrict unknown agents	`ApprovalStatus = New` or `ReviewRequired`	Keep blocked or in report-only validation
Block high-risk agents	Agent risk is high	Block access
Protect sensitive data access	`DataSensitivity = Confidential` or `Restricted`	Apply stricter access decisions
Separate production from test	`Environment = Prod`, `Test`, `Sandbox`	Apply different enforcement rings

The key design idea is simple: approved agents can proceed, unknown or rejected agents should not be trusted by default.

Screenshot: Conditional Access policy targeting agent identities by custom security attributes

Avoid copying human-user controls to autonomous agents

Autonomous agents are not humans. They do not complete MFA prompts. They do not respond to interactive remediation flows. They may not have a compliant device context unless they run through a managed endpoint model.

For autonomous agents, focus on controls that make sense for non-human access:

Block or allow based on approval state
Block based on agent risk
Scope access to specific resources
Use custom security attributes for targeting
Use report-only mode before enforcement
Validate sign-in impact before enabling policy

Avoid applying human-user policy patterns without reviewing the agent access model. A policy designed for a person may not behave correctly for an autonomous agent.

Use report-only mode first

Agent Conditional Access policies should not be enforced blindly. Start with report-only mode and validate the effect.

A safe rollout model looks like this:

Ring	Purpose
Ring 0 — report-only	Understand impact without blocking access
Ring 1 — pilot agents	Apply to selected approved agents
Ring 2 — production approved agents	Expand to known, classified, accountable agents
Ring 3 — broader enforcement	Apply across a wider approved population

This staged approach reduces risk. It also gives administrators an opportunity to validate sign-in logs, policy impact, exceptions and unsupported scenarios before enforcement.

Screenshot: Conditional Access report-only impact for agent identity policy

Recommended baseline policies

A clean Conditional Access design for agents can start with a small number of baseline policies.

Block non-approved autonomous agents

Use this policy to prevent agents without the right approval metadata from accessing corporate resources.

Target agents based on custom security attributes such as:

ApprovalStatus = New
ApprovalStatus = ReviewRequired
ApprovalStatus = Rejected
ApprovalStatus = Revoked

This helps ensure only classified and approved agent identities can proceed to resource access.

Allow approved agents to access selected resources

Use this policy to ensure approved autonomous agents can access only the resources they are supposed to use.

Target agents where:

ApprovalStatus = Approved
Environment = Prod
AccessPattern = Autonomous

Scope the policy to the relevant resources instead of treating all resources the same.

Block high-risk agent identities

Use this policy to respond to risky agent behaviour.

If an agent identity is detected as high risk, block access until the issue is reviewed. The operational response could include reviewing permissions, disabling the agent identity, moving the agent back to ReviewRequired, or retiring the agent if it is no longer valid.

Apply stricter controls for sensitive agents

Agents tagged with higher sensitivity or business criticality may need stricter governance.

Example targeting:

DataSensitivity = Confidential
DataSensitivity = Restricted
BusinessCriticality = High
BusinessCriticality = MissionCritical

These agents may need stricter resource scoping, closer monitoring, shorter access durations and stronger approval before access packages are granted.

Agent user identity considerations

Some agents may operate with their own user-like identity. These scenarios need separate design consideration because controls such as device compliance, network compliance and endpoint execution context may become relevant.

For agent users, consider policies that evaluate:

Agent risk
Execution environment
Device compliance where supported
Network or Global Secure Access signals where applicable
Resource-specific access

Be careful not to apply endpoint-based requirements to cloud-native agents that have no device context. If the agent has no route to satisfy a device or network condition, the result may be unintended blocking.

Screenshot: Conditional Access policy for agent user identity with endpoint-based conditions

Naming and governance standards

Use consistent naming so policies remain readable over time.

Suggested naming pattern:

CA-AgentID-<AccessPattern>-<Control>-<Scope>-<Mode>

Examples:

CA-AgentID-Autonomous-Block-NonApproved-ReportOnly
CA-AgentID-Autonomous-Block-HighRisk-ReportOnly
CA-AgentID-Autonomous-Allow-Approved-Prod
CA-AgentUser-Require-CompliantDevice-Pilot

Good naming helps during operations, troubleshooting and policy review. It also prevents agent policies from being confused with human-user policies.

Common design caveats

Keep these points visible in the design:

Do not assume every discovered agent has a Microsoft Entra Agent ID.
Do not assume every agent can be governed through the same Conditional Access model.
Do not apply user MFA controls to autonomous agents without validating behaviour.
Do not enforce policies before validating in report-only mode.
Do not create individual policies for hundreds or thousands of agents.
Use custom security attributes for scalable targeting.
Keep OBO, autonomous and agent user scenarios separate.
Validate policy impact using sign-in logs before enforcement.
Keep exception handling documented and time-bound.

Where Conditional Access fits in the sequence

Conditional Access should come after inventory, accountability and custom security attributes.

The sequence should look like this:

Inventory agents.
Classify source, identity model and access pattern.
Assign owners and sponsors.
Populate custom security attributes.
Create Conditional Access policies in report-only mode.
Validate impact.
Enforce in rings.
Use access packages for durable resource access.
Monitor risky agents and policy outcomes.

Conditional Access is not the first step. It is the enforcement layer that becomes effective once the governance metadata is trusted.

Wrap-up

Conditional Access turns agent classification into access control. For on-behalf-of flows, review the existing user Conditional Access baseline. For autonomous agents, use agent identity policies driven by approval status, risk and custom security attributes. For agent users, evaluate endpoint, network and device-based controls only where they apply.

Start in report-only mode, validate impact, and then enforce in controlled rings. This keeps agent governance scalable, defensible and safer to operate.

Next in the series: Use access packages for governed agent access

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

stepbystep tocloud — Thu, 09 Jul 2026 15:10:15 +0000

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:

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.
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.

Next in the series: Design Conditional Access policies for agent identities

Establish owners, sponsors, and accountability for AI agents

stepbystep tocloud — Thu, 09 Jul 2026 15:09:13 +0000

Agent inventory tells us what exists. The next question is more important: who is accountable for each agent?

In a real environment, agents can be created by makers, developers, business teams, platform teams, or external systems. If the organisation only knows that an agent exists but does not know who owns it, who sponsors it, or why it is still needed, the agent becomes difficult to govern safely.

This is why owner and sponsor mapping should happen before deeper controls such as Conditional Access, access packages, lifecycle workflows, or enforcement policies.

Why accountability matters

AI agents are not just configuration objects. They can access data, call APIs, use connectors, run workflows, interact with users, and sometimes operate without a human present at runtime.

That means every production-ready agent should have clear human accountability.

At a minimum, the organisation should be able to answer:

Who is technically responsible for this agent?
Who is accountable for the business purpose of this agent?
Who can confirm whether the agent is still required?
Who approves the agent’s access to data or resources?
Who should be contacted if the agent becomes risky, stale, or orphaned?
Who decides whether the agent should be retired?

If these questions cannot be answered, the agent should not be treated as approved or production-ready.

Owner and sponsor are not the same

The owner and sponsor serve different governance purposes.

Role	Primary responsibility	Typical person or team
Owner	Technical administration and operational handling of the agent	Agent maker, platform admin, application owner, automation team, engineering team
Sponsor	Business accountability for the agent’s purpose, lifecycle, and continued need	Business owner, product owner, process owner, department representative

The owner normally understands how the agent is configured, where it runs, what connectors or APIs it uses, and how to troubleshoot it.

The sponsor confirms why the agent exists, whether the business still needs it, whether its access is justified, and whether it should continue to operate.

In simple terms:

Owner = who manages it technically. Sponsor = who is accountable for why it exists.

Recommended accountability states

Once the inventory is collected, agents should be grouped based on ownership and sponsorship status.

Accountability state	Meaning	Recommended action
Owner and sponsor present	Agent has both technical and business accountability	Move to classification and policy-readiness review
Sponsor present, owner missing	Business need is known but technical accountability is unclear	Ask sponsor to nominate or confirm technical owner
Owner present, sponsor missing	Technical contact is known but business accountability is missing	Assign a business sponsor before access governance
No owner and no sponsor	Agent is orphaned or unmanaged	Mark as `ReviewRequired` and start claim-or-retire process
Purpose unknown	Agent exists but business reason is unclear	Keep in `ReviewRequired` until validated
System or built-in object	Object appears platform-generated or not business-owned	Exclude from business-agent review unless risk-relevant

Screenshot: Agent inventory view

Treat missing accountability as a governance gap

An agent with no owner or sponsor should not automatically be considered malicious or unsafe. But it should be considered untrusted from a governance perspective until validated.

The right action is not always immediate blocking. The better approach is to classify the agent into a clear remediation state.

For example:

Finding	Governance interpretation	Next step
Agent has no owner and no sponsor	Orphaned or unmanaged	Ask platform or business team to claim ownership, otherwise move to retire or disable review
Agent has owner but no sponsor	Technically known, business purpose not confirmed	Assign sponsor before granting durable access
Agent has sponsor but no owner	Business need exists, technical support unclear	Nominate technical owner
Agent purpose is unknown	Cannot approve yet	Keep as `ReviewRequired`
Agent is system-generated	May not need business owner/sponsor	Exclude from business-agent workflow after validation

This keeps the model practical. Not every agent needs immediate enforcement, but every agent needs a known state.

Why this matters before policy design

Conditional Access, access packages, and lifecycle workflows all depend on trusted metadata.

If ownership and sponsorship are incomplete, later controls become harder to operate.

For example:

Access package expiry notifications need a responsible sponsor.
Lifecycle workflows need sponsor and manager data to maintain continuity.
Risky-agent review needs someone to validate whether the agent should continue.
Custom security attributes such as ApprovalStatus, OwnershipStatus, or LifecycleState depend on reliable ownership decisions.
Conditional Access policies should not blindly trust agents that are unknown or orphaned.

This is why the accountability layer should be completed before moving into enforcement.

Suggested ownership and sponsorship process

The organisation should define a simple process for existing and new agents.

For existing agents:

Use inventory data to identify missing owner and sponsor values.
Ask platform teams, makers, application teams, or business units to claim agents.
Mark unclaimed agents as ReviewRequired or Orphaned.
Decide whether each unclaimed agent should be retained, disabled, retired, or monitored.
Update governance metadata once ownership and sponsorship are confirmed.

For new agents:

Require owner and sponsor before the agent becomes production-ready.
Capture business purpose, data access requirement, source platform, and access pattern.
Do not mark the agent as approved until accountability is complete.
Keep incomplete agents in ReviewRequired.
Move fully accountable agents into policy design.

Owner and sponsor self-service

Where supported, owners and sponsors should not depend only on central administrators for every action.

A strong operating model allows responsible people to:

View agents they own or sponsor.
Review agent details.
Request governed access for an agent.
Disable or re-enable an agent when action is required.
Participate in access extension or lifecycle decisions.

This helps shift agent governance from a purely central IT activity into a shared accountability model.

Central administrators still own the governance framework, but sponsors and owners help keep the data accurate and the lifecycle healthy.

Recommended metadata to capture

When assigning owners and sponsors, also capture the minimum context required for future governance.

Metadata	Why it matters
Owner	Identifies technical accountability
Sponsor	Identifies business accountability
Business purpose	Confirms why the agent exists
Source platform	Helps determine governance path
Environment	Separates production from test or sandbox agents
Access pattern	Determines whether user, agent identity, or agent-user controls apply
Data sensitivity	Helps decide risk and protection level
Approval status	Determines whether agent can move into enforcement
Lifecycle state	Tracks whether agent is active, under review, retiring, or disabled

This metadata becomes the input for the next stage: custom security attributes.

Design recommendation

Do not treat owner and sponsor mapping as a one-time cleanup exercise.

Use it as a governance gate.

An agent should move forward only when it is:

Classified — source, identity model, and access pattern are known.
Accountable — owner and sponsor are assigned.
Justified — business purpose is documented.
Approved — governance review completed.
Ready for policy — metadata is clean enough for downstream controls.

Agents that do not meet this baseline should remain in ReviewRequired.

Wrap-up

Inventory gives visibility, but ownership and sponsorship create accountability.

Before applying stronger controls, every governable agent should have a clear technical owner, business sponsor, purpose, and lifecycle state. This prevents agents from becoming orphaned, unmanaged, or permanently over-permissioned.

Once ownership and sponsorship are clean, the next step is to use custom security attributes as the structured metadata layer for scalable policy targeting, reporting, and governance.

Next in the series: Use custom security attributes as the governance metadata layer

Start with agent inventory and classification

stepbystep tocloud — Thu, 09 Jul 2026 15:08:05 +0000

Before creating Conditional Access policies, access packages, lifecycle workflows, or custom security attribute rules, start with the simplest question: what agents exist in the environment?

That sounds basic, but it is the most important step in an Agent ID governance journey. Agents can come from different platforms, use different identity models, and have different levels of visibility in Microsoft 365 and Microsoft Entra. If the inventory is incomplete or poorly classified, every later governance decision becomes risky.

The purpose of inventory is not just to create a list. The purpose is to understand which agents are ready for governance, which agents need cleanup, which agents are unknown, and which agents should be excluded from business-agent review.

Licensing note: Microsoft Entra ID Governance for agent identities requires either Microsoft 365 E7, or Microsoft Agent 365 paired with at least Microsoft Entra ID P1 or Microsoft 365 E3. For licensing, refer to the Microsoft Agent 365 plans and pricing.

Why inventory comes first

AI agents may be created or discovered from different places:

Microsoft Copilot Studio
Microsoft 365 Copilot Agent Builder
Azure AI Foundry
Amazon Bedrock
Google Vertex AI
Other third-party platforms
Custom or pro-code agent platforms
Shadow AI or endpoint-discovered tools
System-created or built-in platform objects

These agents should not all be treated the same way.

Some agents may have a Microsoft Entra Agent ID. Some may still use an app registration or service principal model. Some may only be visible through registry sync. Some may be discovered as shadow AI activity. Some may be system-generated objects that should not be handled like customer-created business agents.

That is why the first phase should focus on inventory and classification, not enforcement.

What the inventory should answer

A useful agent inventory should answer the following questions.

Question	Why it matters
What agents exist?	Establishes full visibility of the agent estate.
Which platform created or surfaced the agent?	Determines the likely governance path.
Does the agent have Microsoft Entra Agent ID?	Determines whether Agent ID-specific controls can apply.
Is the agent user-created, system-created, or third-party discovered?	Prevents incorrect governance of built-in or system objects.
Does the agent have an owner and sponsor?	Identifies accountability gaps.
What access pattern does the agent use?	Determines the correct Conditional Access and access governance model.
Is the agent approved, unknown, legacy, unmanaged, or orphaned?	Determines the next corrective action.

Screenshot: Agent inventory table showing source platform, identity type, owner, sponsor, access pattern, and governance state

Minimum inventory fields

The inventory should capture enough information to support governance decisions, not just reporting.

Field	Purpose
Agent name	Basic identification.
Source platform	Identifies where the agent came from.
Environment, tenant, or region	Helps with platform ownership and operational scoping.
Identity state	Captures whether the agent uses Agent ID, app registration, service principal, agent user identity, registry-only visibility, or unknown identity.
Microsoft Entra Agent ID present	Identifies whether Agent ID controls are relevant.
Owner	Technical or operational administrator.
Sponsor	Business accountable person.
Business purpose	Explains why the agent exists.
User-created or system-created	Helps avoid applying business governance to built-in objects.
Access pattern	Classifies whether the agent acts on behalf of a user, acts autonomously, or uses its own user-like identity.
Data sensitivity	Helps prioritise protection and review.
Business criticality	Helps prioritise governance effort.
Approval status	Tracks whether the agent is new, under review, approved, rejected, or revoked.
Governance state	Tracks whether the agent is active, ReviewRequired, orphaned, unmanaged, retired, or policy-ready.
Recommended action	Captures the next step for that agent.

Classification model

Once the inventory is collected, classify every agent into a practical governance bucket. This avoids treating every discovered object as the same type of agent.

Classification bucket	Meaning	Recommended action
Entra Agent ID-backed agent	Agent has a Microsoft Entra Agent ID.	Move to governance design if owner, sponsor, purpose, and access pattern are known.
Agent ID-backed but missing accountability	Identity exists, but owner or sponsor is missing.	Fix accountability before enforcement.
Legacy app registration or service principal-backed agent	Agent uses older app registration or service principal model.	Track separately and validate governance path.
Microsoft 365 Agent Builder agent	Agent created through Microsoft 365 Copilot Agent Builder.	Govern through the appropriate Agent 365 or Microsoft 365 controls. Do not assume Agent ID behaviour without validation.
Third-party registered or synced agent	Agent discovered through registry sync or external platform integration.	Reconcile with the source platform and validate supported governance actions.
Shadow AI or local agent	Agent or AI tool detected through endpoint or security signals.	Review through endpoint and security governance processes.
System-created or built-in object	Platform-generated or connector-like object.	Exclude from business-agent governance review unless risk-relevant.
Unknown or unclassified agent	Source, owner, sponsor, purpose, or identity model unclear.	Mark as ReviewRequired.
Orphaned agent	No valid owner, no sponsor, and unclear business purpose.	Run claim-or-retire process.
Policy-ready agent	Fully classified, accountable, and approved.	Include in Conditional Access, access package, lifecycle workflow, and monitoring design.

Access pattern classification

Identity state alone is not enough. The access pattern also matters.

Access pattern	Meaning	Governance implication
On-behalf-of user	Agent acts using the signed-in user’s delegated context.	Existing user Conditional Access and user permissions are highly relevant.
Autonomous or app-only	Agent operates independently using its own identity or application permission.	Agent identity controls, app permissions, access packages, and agent-specific Conditional Access become relevant.
Agent user identity	Agent behaves like a user-like identity with its own mailbox, Teams presence, or directory identity.	Stronger lifecycle, licensing, content access, and collaboration governance may be needed.
Unknown	Access behaviour is not confirmed.	Do not enforce final policies until clarified.

Corrective actions after inventory

Inventory should not remain a static report. It should drive cleanup.

Inventory finding	Recommended action
Agent has no owner and no sponsor	Treat as orphaned or ReviewRequired. Ask platform or business team to claim ownership, otherwise move to retire or disable review.
Agent has sponsor but no owner	Confirm or nominate the correct technical owner.
Agent has owner but no sponsor	Assign a business sponsor before lifecycle or access governance.
Source platform unknown	Keep in ReviewRequired state until source is validated.
Identity model unknown	Classify as Agent ID, app registration, service principal, agent user, registry-only, shadow AI, or unknown.
Access pattern unknown	Do not move into final Conditional Access design until access pattern is confirmed.
System or built-in object	Exclude from business-agent governance unless risk-relevant.
Agent fully classified and accountable	Move to policy design.

Gatekeeping for new agents

The first inventory helps clean the current state. The next challenge is preventing the same gaps from coming back.

For newly created agents, define a minimum metadata gate before the agent is considered production-ready. At minimum, the agent should have:

Owner
Sponsor
Business purpose
Source platform
Environment
Access pattern
Data sensitivity
Business criticality
Approval status
Governance state

Agents that do not meet the baseline should remain in ReviewRequired state. They should not be treated as approved just because they exist.

This helps the organisation move from manual housekeeping to a repeatable operating model.

Recommended outcome of this phase

By the end of the inventory and classification phase, the organisation should be able to answer:

How many agents exist?
Where did they come from?
Which agents have Microsoft Entra Agent ID?
Which agents are legacy, third-party, shadow, or unknown?
Which agents are user-created versus system-created?
Which agents are missing owner or sponsor?
Which agents are orphaned?
Which agents are ready for policy design?
Which agents need further investigation before enforcement?

Wrap-up

Agent governance should not start with policy creation. It should start with visibility.

Inventory gives the organisation a clear view of the estate. Classification turns that view into action. Once agents are classified, accountable, and approved, the organisation can safely move into the next stage: using custom security attributes as the governance metadata layer.

Next in the series: Establish owners, sponsors, and accountability

Governing AI agents with Microsoft Entra Agent ID and Agent 365

stepbystep tocloud — Thu, 09 Jul 2026 15:04:00 +0000

AI agents are becoming part of the enterprise identity landscape. They can be created across different platforms, access corporate data, call APIs, participate in workflows, and in some cases operate with their own identity.

That makes agent governance more than a discovery exercise. It becomes an identity, access, lifecycle, and risk-management discipline.
The challenge is scale. Administrators cannot govern every agent one by one, especially when agents may come from Copilot Studio, Microsoft 365 Copilot Agent Builder, Azure AI Foundry, third-party platforms, registry sync, or shadow AI discovery. A durable model needs a clear sequence: visibility first, then classification, accountability, metadata, access control, governed access, lifecycle continuity, and monitoring.

This series focuses on the Microsoft Entra side of AI agent governance, with emphasis on Microsoft Entra Agent ID, identity classification, ownership, sponsorship, access control, lifecycle continuity, and monitoring. It is not intended to be a complete governance model for Microsoft Agent 365, Copilot Studio, Power Platform, or every agent-building platform. Those platforms have their own governance controls and should be reviewed separately as part of a complete enterprise agent governance strategy.

This series breaks the AI agent identity governance journey into focused stages, helping administrators build the Microsoft Entra governance foundation step by step.

Governance journey

Part	Article	What it covers
1	Start with agent inventory and classification	Discover agents, capture core metadata, classify identity models, and identify corrective actions.
2	Establish owners, sponsors, and accountability	Define who is technically responsible and who is business-accountable for each agent.
3	Use custom security attributes as the governance metadata layer	Build a scalable attribute model for approval state, sensitivity, access pattern, lifecycle state, and policy targeting.
4	Design Conditional Access policies for agent identities	Apply access controls based on agent access pattern, approval state, identity type, and risk.
5	Use access packages for governed agent access	Provide approved agents with time-bound, auditable access through approval workflows instead of permanent direct assignments.
6	Maintain sponsor continuity with lifecycle workflows	Prevent agent identities from becoming orphaned when sponsors move roles or leave the organisation.
7	Monitor risky agents and keep governance current	Use sign-in logs, audit logs, risk signals, access expiry, and sponsor reviews to keep the model healthy.

The recommended sequence

The governance model should follow a simple sequence:

Inventory the agent estate.
Classify agents by source, identity model, and access pattern.
Assign accountability through owners and sponsors.
Populate governance metadata using custom security attributes.
Apply access controls using Conditional Access.
Grant durable access using access packages.
Maintain sponsorship using lifecycle workflows.
Monitor continuously using logs, risk signals, and review processes.

The important principle is that enforcement should not start before the estate is understood. Once each agent is visible, classified, accountable, and approved, policies can be introduced safely and expanded in phases.

Why this matters

Without a structured model, organisations can quickly end up with agents that are visible but not governed, approved but not accountable, or active without a clear business owner.

A good agent governance model helps answer practical questions:

What agents exist in the environment?
Which platform created or surfaced each agent?
Which agents have Microsoft Entra Agent ID?
Which agents are legacy, third-party, shadow, or unknown?
Who owns the agent technically?
Who sponsors the agent from a business perspective?
What access pattern does the agent use?
Is the agent approved, under review, rejected, or orphaned?
What controls should apply next?

Target outcome

The goal is not to create policy complexity. The goal is to build a repeatable operating model where every agent can be placed into a clear governance state.

A healthy target state looks like this:

Governance state	Meaning
Classified	The agent source, identity model, and access pattern are understood.
Accountable	The agent has a valid owner and sponsor.
Approved	The agent has business justification and required metadata.
Governed	Conditional Access, access packages, lifecycle controls, and monitoring can apply where relevant.
ReviewRequired	The agent is missing key information and should not be treated as production-ready.
Orphaned	The agent has no valid owner or sponsor and must be claimed, retired, or blocked based on the organisation’s process.

How to use this series

Use the articles as a phased design guide.

Start with inventory and classification. Then clean up owner and sponsor gaps. Once the baseline is clean, move to custom security attributes, Conditional Access, access packages, lifecycle workflows, and monitoring.

This keeps the design practical. Instead of trying to govern thousands of agents manually, the organisation builds a metadata-driven model where approved agents can be governed consistently and unknown agents stay under review until validated.

Bonus: Putting the agent governance model into production

Wrap-up

Agent governance should not start with policies. It should start with visibility and accountability.

Once the estate is inventoried, classified, and trusted, Microsoft Entra Agent ID and Agent 365 controls can be applied in a structured way: custom security attributes for metadata, Conditional Access for enforcement, access packages for governed access, lifecycle workflows for continuity, and monitoring for ongoing assurance.

Next in the series: Start with agent inventory and classification