AI agents sign in, hold permissions and act on systems, so they need the same joiner, mover and leaver discipline as people and service accounts. This guide sets out one way to run it. It goes deeper on the identity part of the enterprise AI security implementation guide (pillar 3).
It is a practitioner’s design built on Microsoft’s published documentation for Entra Agent ID, not a tested reference implementation. The model carries over to other platforms: one identity per agent, an accountable human, risk tiers, expiry on every grant, and a kill switch.
Scope: Microsoft Entra Agent ID for identity and access, core ServiceNow (Service Catalog, Flow Designer / IntegrationHub, CMDB, Change, Incident) for request, approval, business context, and records. ServiceNow AI Control Tower is deliberately not used.
The Microsoft details below were checked against Microsoft Learn on 2026-10-01 (sources at the end). Entra Agent ID is generally available, but it is still changing quickly; re-check feature status and licensing before building.
In brief
Core idea: each AI agent is its own identity, tied to one application and one accountable business person (Microsoft calls that person the sponsor).
- ServiceNow is the front door and holds the business context: which application, who owns it, the risk level, approvals and changes.
- Entra holds the identity and enforces the rules: credentials, access, sign-in conditions and logs.
- ServiceNow decides and records, Entra enforces, and no approval is done twice.
How agents map to applications:
- Each application gets a template for each kind of agent and each environment. Entra calls this template a blueprint, and it holds the credentials. For example, “Claims Portal - Triage - PROD” is one blueprint.
- Each running agent gets its own identity created from that template.
- Owners come from the CMDB. The application’s business owner becomes the sponsor, and its technical owner becomes the owner.
- Each side stores the other’s IDs. The ServiceNow record holds the Entra IDs, and the Entra identity carries the CMDB app ID, environment and risk level, so the two can be matched daily.
- Disabling a template stops every agent built from it, which gives each application its own kill switch.
Manual vs fully automated, decided by risk level:
| Risk level | Workflow | Example | Access lasts |
|---|---|---|---|
| Standard | Fully automated | Read-only access, or acting on behalf of the signed-in user, using only pre-approved access bundles | Up to 12 months |
| Elevated | Business owner approves | Access to confidential data | Up to 6 months |
| Privileged | Manual, several approvers | Agent acts on its own with write or admin rights, or touches regulated data. Needs business owner, security architecture, data owner and change board, plus a threat model and test evidence | 30 to 90 days |
A request that doesn’t meet every standard-level condition moves up a level automatically. Full automation is still least privilege because security approves each small, scoped access bundle once, and every grant expires.
The full lifecycle: register, approve, create the identity, grant access, enforce sign-in rules, monitor, change, recertify, suspend, retire, plus a daily match between Entra and ServiceNow. Section 6 has six flow diagrams:
- Register a new agent through the ServiceNow catalog.
- Request access through Entra access bundles. Privileged requests pause in Entra, open a ServiceNow change for approval, then resume.
- Recertify: business owners confirm each agent every 6 to 12 months, and access is removed if they don’t respond.
- Owner leaves: Entra automatically moves the agent to that person’s manager, who must confirm the agent is still needed.
- Emergency kill switch from security operations: disable one agent or the whole application’s template, and log a linked ServiceNow incident.
- Retire and daily match: agents found in Entra but not in the CMDB are treated as unapproved.
Things to know:
- Licensing: these Entra features need Microsoft 365 E7, or a Microsoft Agent 365 license on top of Entra P1 or Microsoft 365 E3.
- Several pieces are new and change often, so recheck their status before building. Externally determined approvals, for one, were still documented as a public preview when checked.
- Not verified: whether your ServiceNow version has a ready-made CMDB record type for AI agents. Check that and create a custom one if needed.
1. The core idea in one paragraph
Every AI agent is a governed, non-human identity tied to an application and a human sponsor. ServiceNow is the front door and system of record for business context (which application, who owns it, what risk tier, which approvals and changes happened). Entra is the system of record for identity and enforcement (the agent’s identity, its credentials, what it can access, the conditions it can access under, and the logs). ServiceNow decides and records; Entra enforces. Neither duplicates the other’s job.
2. Entra Agent ID building blocks (what you have to work with)
| Object / feature | What it is | How you use it |
|---|---|---|
| Agent identity blueprint | Template and authentication foundation for a kind of agent. Holds the credentials and acquires tokens for all agent identities created from it. Policies on the blueprint (e.g. Conditional Access) apply to all its agents. | One blueprint per application per environment (see section 3). Disabling it blocks every agent from it: your per-application kill switch. |
| Agent identity blueprint principal | The blueprint’s presence in a tenant; lets it get tokens and appear in logs. | Created automatically when the blueprint is added to the tenant. |
| Agent identity | The identity a single agent uses. Has no credentials of its own; authenticates with tokens issued via its blueprint. | One per agent instance. Never share between agents. |
| Agent’s user account (optional) | A 1:1 user object paired with an agent identity, for systems that need a user (mailbox, calendar, Teams presence). | Only when truly needed; it adds licenses, group memberships and user-level policy complexity. |
| Owner | Technical administrator of the agent. | Engineering lead of the application. |
| Sponsor | Human business owner accountable for purpose, access, and retention decisions; no technical admin rights. Required on every blueprint and agent identity. | Business application owner from the ServiceNow CMDB. |
| Manager | Hiring manager / operational owner for an agent’s user account. | Only when an agent’s user account exists. |
| Access packages (entitlement management) | Time-bound, approved access bundles. Agents can hold: security group memberships, application OAuth API permissions (including Graph application permissions), and Entra roles. | Main way to grant access. Three request paths: the agent requests programmatically, the sponsor requests on its behalf, or an admin assigns directly. |
| Expiry and sponsor notifications | Before an agent’s access package expires, the sponsor is notified and can request an extension (which can trigger re-approval) or let it lapse. | Built-in recertification for every grant. |
| Access reviews | Periodic attestation, including agent identities. | Sponsors attest every 6-12 months (Microsoft’s recommendation). |
| Lifecycle Workflows - sponsor tasks | Mover/leaver tasks: email the manager about sponsorship changes, email cosponsors, transfer agent sponsorships to the manager. Sponsorship also transfers to the manager automatically when a sponsor leaves. | No agent is ever left without an accountable human. |
| Conditional Access for agents | CA policies that target agent identities, with agent risk from ID Protection. Can be applied at blueprint level. | Block high-risk agents; block non-prod agents from prod resources; restrict locations. |
| Custom security attributes | Org-defined attributes (e.g. Environment, Department, DataSensitivity) assigned to agent identities and used in CA conditions. |
Carry your application and risk metadata into enforcement. |
| Sign-in and audit logs for agents | Every token acquisition and every config change. | Stream to the SIEM. |
| Entitlement management custom extensions | Call a Logic App at access package events; can “launch and wait” for a callback. Microsoft documents a ServiceNow ticket pattern. Custom extensions can also determine approval requirements externally. | The bridge from Entra access workflows back to ServiceNow. |
Authentication patterns (pick per agent):
- Interactive agent acts for a signed-in user: on-behalf-of (OBO) flow with delegated permissions. The user’s own access limits what the agent can do. Prefer this whenever a user is in the loop.
- Autonomous agent acts as itself: client credentials flow with only the required application permissions. Highest-risk pattern; governs most tightly.
- Microsoft’s rule: avoid application permissions when delegated permissions would do.
Credentials: managed identity / federated credentials (no stored secret) or certificates in Key Vault in production. Client secrets only in dev, rotated out before go-live. Separate credentials per blueprint and per environment.
Licensing (checked 2026-10-01): Entra ID Governance features for agents need Microsoft 365 E7 (includes Agent 365 and Entra Suite), or a Microsoft Agent 365 license with at least Entra P1 or Microsoft 365 E3. Admin roles involved include Agent ID Administrator, Agent ID Developer, and Lifecycle Workflows Administrator.
3. Mapping agents to applications (the data model)
ServiceNow CMDB Microsoft Entra
--------------- ---------------
Business Application (e.g. "Claims Portal")
owner = business owner ------------------> Sponsor
tech owner ------------------> Owner
risk tier / data class ------------------> Custom security attributes
| (AppId, Environment,
| DataSensitivity, RiskTier)
Application Service (Claims Portal - PROD)
|
+--> Agent CI "agt-claims-triage-prod" <==> Agent identity blueprint
| entra_blueprint_id "Claims Portal - Triage - PROD"
| entra_agent_ids[] |
| auth pattern (OBO / autonomous) +--> Agent identity (instance 1)
| approved access packages[] +--> Agent identity (instance 2)
| risk tier, review date, status |
| +--> Access packages (time-bound)
+--> Agent CI "agt-claims-summarizer-prod" <==> another blueprint ...
Rules:
- One blueprint per application + agent type + environment. Keeps credentials, CA, and the kill switch scoped: disabling “Claims Portal - Triage - PROD” does not touch other apps or non-prod.
- One agent identity per running agent instance. Traceability and surgical disable.
- The CMDB agent CI stores the Entra object IDs, and the Entra objects carry the CMDB identifiers (custom security attributes and description/tags). Two-way reference, so reconciliation is a simple join.
- Sponsor = the business application owner; Owner = the application’s technical owner. Both come from the CMDB, so they stay right when the application’s owners change.
- Naming convention enforced by the workflow, e.g.
agt-<app>-<function>-<env>. - For the CMDB class: use the AI/agent CI classes in your ServiceNow release’s CSDM if present; otherwise extend a custom “AI Agent” class under the application service. (Verify what your instance’s release provides.)
4. Risk tiers decide automated vs manual
Classify every agent at registration. The tier chooses the workflow.
| Criterion | Tier 1 - Standard (fully automated) | Tier 2 - Elevated (single approval) | Tier 3 - Privileged (manual, multi-stage) |
|---|---|---|---|
| Auth pattern | Delegated (OBO) only | Delegated, or autonomous with read-only app permissions | Autonomous with write/admin app permissions |
| Data | Public / internal | Confidential | Restricted (PII, financial, regulated) |
| Environment | Non-prod, or prod read-only | Prod | Prod |
| Access requested | Only pre-approved “standard” access packages | Access packages outside the standard set | Entra roles, Graph application permissions on sensitive scopes, access to production change or external communication |
| Actions | Read, summarize, draft | Create/update records within one application | Delete, payments, prod changes, sending externally, acting across applications |
| Agent’s user account | No | By exception | By exception, with justification |
| Approvers | None (policy approves) | Sponsor (or sponsor’s manager) | Sponsor + security architecture + data owner; Change Advisory Board for prod |
| Max access duration | 12 months, auto-review | 6 months | 30-90 days, renew with re-approval |
| Pre-requisites | Registration complete | + threat model | + threat model, red-team pass, human-approval step for high-impact actions |
Auto-escalation rule: any request that doesn’t match every Tier 1 condition goes to the next tier up automatically. The requester never chooses the tier.
Why fully automated is still least privilege: Tier 1 is automated because the catalog is pre-approved and narrow, not because checks are skipped. The security team approves each standard access package once (scoped, time-bound, low risk); after that, agents that fit it get it without a human in the loop, with expiry and review built in.
5. The lifecycle, stage by stage
| Stage | ServiceNow | Entra | Automation |
|---|---|---|---|
| 1. Request / register | Catalog item “Register AI agent”: application (CMDB lookup), purpose, auth pattern, data class, environment, requested access, sponsor auto-filled | - | Form validation, auto-tiering |
| 2. Approve | Approvals per tier (none / sponsor / multi-stage + Change) | - | Flow Designer approval rules |
| 3. Provision identity | Agent CI created (status: Provisioning) | Blueprint created or reused; agent identity created; owner + sponsor set; custom security attributes set; credential = managed identity / federated credential | Flow Designer + IntegrationHub calling Microsoft Graph, or the supported creation channel (Foundry, Copilot Studio, Agent 365 CLI) followed by registration |
| 4. Grant access | Record requested and granted access on the CI | Access package assignment with expiry | Tier 1: auto-assign; Tier 2/3: Entra access package approval, or approval in ServiceNow then assignment |
| 5. Enforce | - | Conditional Access for agents (by blueprint and attributes), risky-agent block | Policies built once, inherited |
| 6. Operate / monitor | Incidents linked to the agent CI | Sign-in and audit logs to the SIEM; ID Protection risk | SIEM detections (section 8) |
| 7. Change (mover) | Change request when scope, permissions, or environment changes; sponsor or owner change synced from CMDB | Update access packages, attributes, sponsor | Re-tier on every change; a permission increase re-runs approval |
| 8. Recertify | Attestation evidence stored on the CI | Access reviews every 6-12 months; access package expiry notifications to sponsor | Non-response = access removed |
| 9. Suspend (kill switch) | Security incident created and linked | Disable agent identity (one agent) or blueprint (all agents of that app/env); revoke access packages if compromised | SOC playbook one-click action |
| 10. Decommission | Retire request; CI status Retired; evidence kept | Remove access package assignments, delete agent identities, delete blueprint when no instances remain, remove credentials | Scheduled cleanup; nothing left behind |
| Continuous: reconcile | Discovery report: agents in Entra without a CI, CIs without an Entra identity | Graph list of agent identities, blueprints, owners, sponsors, last sign-in | Daily sync job; mismatch = ticket |
6. Workflows
Workflow A - Register a new agent (ServiceNow-led)
Requester (app team)
| ServiceNow catalog: "Register AI agent"
v
[Validate] app exists in CMDB, sponsor = app owner, naming, auth pattern, data class
|
[Auto-tier] Tier 1 / 2 / 3 from the criteria in section 4
|
+-- Tier 1 --> no human approval
+-- Tier 2 --> sponsor approves
+-- Tier 3 --> sponsor + security architecture + data owner; attach threat model
| and red-team evidence; Change request for prod
v
[Provision via Graph] blueprint (reuse if app+type+env exists) -> agent identity
-> owner + sponsor -> custom security attributes -> federated credential / managed identity
|
[Create agent CI] store Entra object IDs, tier, review date; status Active
|
[Request standard access] (Workflow B)
|
[Notify] requester and sponsor, with the kill-switch and review details
Where teams create agents through Foundry or Copilot Studio (which auto-provision agent identities), run the same workflow as a registration of an existing identity: the reconciliation job (Workflow F) opens the registration ticket when it finds an unregistered agent, and access beyond the defaults stays blocked until the ticket completes.
Workflow B - Access request (the least-privilege heart)
Use Entra entitlement management for access, because expiry, sponsor notifications, reviews, and audit are native there. ServiceNow gets the record.
Agent needs access
|
+-- path 1: agent requests programmatically (Graph accessPackageAssignmentRequest)
+-- path 2: sponsor requests on its behalf (My Access portal)
+-- path 3: ServiceNow catalog request -> Flow Designer calls Graph to request
v
Entra access package policy (scoped to agent identities)
|
+-- Standard package (Tier 1): no approval, fixed expiry --> ASSIGNED
+-- Elevated package (Tier 2): sponsor approval --> ASSIGNED / DENIED
+-- Privileged package (Tier 3): multi-stage approval, short expiry
| custom extension "launch and wait" -> Logic App -> ServiceNow Change/RITM
| -> CAB / security approve in ServiceNow -> callback resumes Entra --> ASSIGNED
v
Custom extension on "assignment granted" -> Logic App -> update agent CI in ServiceNow
Rules that keep it least privilege:
- Package design is the control. Many small, purpose-specific packages (e.g. “Claims read - Graph Sites.Selected on claims site”) rather than broad ones.
- Prefer resource-scoped permissions (Sites.Selected style, specific groups, specific APIs) over tenant-wide ones.
- Every assignment has an expiry. No “never expires” for agents.
- Autonomous agents never get Graph application permissions on mail, files, or directory write without Tier 3.
- One approval engine per step. Either Entra approves or ServiceNow approves (via launch-and-wait); never both for the same decision.
- Launch-and-wait has a clock. Microsoft’s ServiceNow tutorial notes that a paused request shows as failed if it is not resumed within 14 days, so the ServiceNow approval has to finish inside that window.
Workflow C - Recertification
Scheduled Entra access review (6-12 months; 90 days for Tier 3)
reviewers = sponsors
|
+-- Approve -> access continues; evidence written to CI (custom extension / sync)
+-- Deny -> access removed
+-- No reply -> access removed (auto-apply results, default "remove")
Plus: access package expiry -> sponsor notified -> extend (re-approval) or lapse
Plus: quarterly orphan check -> no sponsor, stale metadata, or no sign-in for N days
-> ServiceNow task to the owner: justify or decommission
Workflow D - Sponsor or owner leaves / moves (joiner-mover-leaver for agents)
HR event -> Entra Lifecycle Workflow (mover/leaver)
-> email manager and cosponsors about sponsorship change
-> transfer agent sponsorships to manager
-> ServiceNow task to the new sponsor: confirm the agent is still needed (7 days)
no confirmation -> suspend agent (Workflow E, non-emergency path)
CMDB application owner change -> sync job updates the Entra sponsor
Workflow E - Emergency kill switch
Trigger: SIEM detection, ID Protection high risk, red-team finding, or human report
|
SOC playbook (SOAR) one action:
scope = one agent -> disable agent identity
scope = whole app -> disable blueprint (blocks all its agents)
compromised creds -> remove blueprint credential; revoke access package assignments
|
ServiceNow Security Incident auto-created and linked to the agent CI; sponsor + owner paged
|
Recovery = Change request: root cause, fixed, re-approved per tier, re-enabled
Plus a standing Conditional Access policy that blocks high-risk agents automatically, so the platform acts before a human does.
Workflow F - Decommission and reconciliation
Decommission request (catalog) or retirement of the parent application
-> remove access package assignments
-> delete agent identities
-> delete blueprint if no instances remain; remove its credentials
-> CI status Retired, evidence retained
-> verify: no sign-ins after date X (SIEM check)
Daily reconciliation (Graph list vs CMDB):
Entra agent with no CI -> registration ticket (Workflow A); treat as shadow agent
CI with no Entra identity -> fix record or retire
Agent with no sponsor -> escalate to app owner
Agent unused for N days -> sponsor asked to justify or retire
Permissions outside approved set -> security ticket; remove
Agents outside Agent ID (plain app registrations / service principals used as agents)
-> migration ticket
7. Integration pattern recommendation
| Option | How | Verdict |
|---|---|---|
| Hybrid (recommended) | ServiceNow owns registration, change, incident, decommission, and the CMDB record. Entra entitlement management owns access grants, expiry, reviews, and sponsor mover/leaver. Custom extensions and a daily sync keep ServiceNow current. | Uses each product’s native strength; minimal custom code; no duplicated approvals. |
| ServiceNow-only | Every step, including access approval, lives in ServiceNow and pushes to Entra via Graph. | Rebuilds expiry, reviews, and sponsor notifications that Entra already has. More code to maintain. |
| Entra-only | Everything in Entra; ServiceNow not involved. | Loses CMDB business context, Change, and the single front door; auditors and app owners live in ServiceNow. |
Integration mechanics:
- ServiceNow -> Entra: Flow Designer + IntegrationHub REST step (or the Microsoft Entra/Azure AD spoke where it covers the call) to Microsoft Graph, authenticated with its own tightly scoped workload identity (certificate or federated credential), holding only the Agent ID and entitlement permissions it needs. This integration identity is itself a Tier 3 identity: review it like one.
- Entra -> ServiceNow: entitlement management custom extensions to a Logic App that calls ServiceNow (through its Logic Apps connector or the Table API); “launch and wait” when ServiceNow must approve, “launch and continue” for record updates. Follow Microsoft’s custom-extension security guidance for the Logic App.
- Logs: Entra sign-in and audit logs (agents included) to the SIEM through diagnostic settings; the SIEM creates ServiceNow security incidents.
- Config as code: blueprint definitions, access package definitions, and CA policies in source control, deployed by pipeline, so changes are reviewed and drift is visible.
8. Least-privilege control checklist
- Every agent created through the Agent ID framework (never a plain app registration or service principal).
- One agent identity per instance; one blueprint per app + type + environment.
- Sponsor and owner set at creation; sponsor auto-transfers on leaver.
- Delegated (OBO) by default; application permissions only with justification and tier.
- Resource-scoped permissions; no tenant-wide Graph write for autonomous agents below Tier 3.
- All access via access packages with expiry; no direct standing grants.
- Managed identity / federated credentials in prod; no client secrets.
- Separate CA policies for agents (they can’t do MFA): block high risk, block non-prod agents from prod, named locations.
- Existing user CA policies reviewed so they don’t break or mis-apply to agents.
- Custom security attributes on every agent (AppId, Environment, DataSensitivity, RiskTier).
- Agent’s user accounts only when a user object is required.
- Human approval inside the agent for high-impact actions, independent of identity.
- Kill switch tested per blueprint.
9. Detections to build in the SIEM
- Spike in token requests or failed token acquisitions for an agent.
- Agent calling an API or resource it has never used before.
- Agent sign-in from an unexpected IP range or location.
- Credential added to a blueprint, permission grant, or role assignment made outside the deployment pipeline.
- Agent blocked by Conditional Access or flagged by ID Protection.
- Credential nearing expiry (operational, prevents outages).
- Access package granted to an agent outside the approved list for its tier.
- Sign-ins by a decommissioned agent.
10. Metrics
| Metric | Target |
|---|---|
| Agents registered in CMDB and Entra Agent ID / all discovered agents | 100% |
| Agents with a current sponsor and owner | 100% |
| Agents using managed identity or federated credentials in prod | 100% |
| Agent access assignments with an expiry | 100% |
| Agents with application permissions / all agents | Low, trending down |
| Tier 1 requests fulfilled with no human touch; median time to fulfil | High share; minutes |
| Tier 2/3 median approval time | Tracked, stable |
| Access review completion rate; access removed per review | ~100% completion |
| Orphaned or unused agents found / removed per quarter | Found count trending down |
| Shadow agents found by reconciliation | Trending to zero |
| Time to disable an agent from detection | Minutes |
| Permissions granted vs permissions actually used per agent | Gap trending down |
11. Where to start
- Turn on agent sign-in and audit log streaming, and run a one-time inventory of agents already in Entra (and app registrations acting as agents).
- Define the tiers and build 3-5 standard Tier 1 access packages.
- Build the ServiceNow “Register AI agent” catalog item and the agent CI; wire provisioning via Graph for one application end to end.
- Add the agent Conditional Access baseline (block high-risk agents, non-prod-to-prod block) in report-only, then enforce.
- Add the reconciliation job, then the access reviews, then the leaver workflow.
12. Sources (Microsoft Learn, checked 2026-10-01)
- Fundamental concepts in Entra Agent ID - https://learn.microsoft.com/en-us/entra/agent-id/key-concepts
- Best practices for Entra Agent ID - https://learn.microsoft.com/en-us/entra/agent-id/best-practices-agent-id
- Governing agent identities (access packages, CA, licensing) - https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview
- Owners, sponsors, and managers - https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers
- Agent sponsor tasks in Lifecycle Workflows - https://learn.microsoft.com/en-us/entra/id-governance/agent-sponsor-tasks
- ServiceNow ticket creation from entitlement management - https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-ticketed-provisioning
- External approval via custom extensions - https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-dynamic-approval
- Securing custom extensions to Logic Apps - https://learn.microsoft.com/en-us/entra/id-governance/custom-extension-security
- What’s new in Entra Agent ID - https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id