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.
Top comments (0)