AI Agent Inventory and Lifecycle Governance Implementation

Because they answer different questions. AI Security for Microsoft 365 Copilot and Agents is the security baseline: it inventories your Copilot and agent estate as a finding, configures Purview, Defender and Entra controls, and configures agent guardrails where you approve them. This engagement is the operating system those guardrails sit inside — a registry where every agent has an owner and a sponsor, an approval path a maker actually follows, identity controls tied to agent identities, and a review cadence and retirement procedure that are run rather than written. Either can go first; if the security review has already told you that 40 agents have no owner, this is the engagement that fixes it.

Not for most of it. The Microsoft 365 admin center's registry, ownerless-agent view, export, block and delete, the Requests approval queue, allowed-types, sharing and user-access settings, and the read-only data-and-tools view are available to Microsoft 365 Copilot-licensed tenants without Agent 365, and Microsoft Entra Agent ID itself is available to every Entra tenant. Agent 365 is required to extend Entra's security features to agents: Conditional Access for agent identities (with Entra ID P1 or P2) and access packages for agent identities (Microsoft 365 E7, or Agent 365 with at least Entra ID P1 or Microsoft 365 E3), plus Agent 365's own observability and risk views. We read your entitlements at intake, configure what they allow and hand you a gap register naming which control waits on which license — at $15 per user per month standalone at the time of writing, or inside Microsoft 365 E7, bought at Microsoft's list price whether through us or not.

By not trusting any single list. The admin-center registry export gives thirty-plus attributes per agent it knows about; the Copilot Studio and Power Platform admin centers list agents by environment, including ones never published to Microsoft 365; Microsoft Entra shows the enterprise applications Copilot Studio created for older agents, which carry a tag naming their origin, and the agent identities newer agents and Foundry projects receive; SharePoint agents are found site by site; and the registry's own "unmanaged agents" tile flags agents created or managed outside Agent 365. We reconcile those sources into one inventory and then ask the makers what is missing — the last step usually finds the agent running on someone's personal connection.

Microsoft Entra Agent ID separates them deliberately. The owner is the technical administrator — the person who can change the agent's configuration and credentials, re-enable it, restore it. The sponsor is the business representative accountable for whether the agent should exist and what it may access: they approve or decline renewal, request access on the agent's behalf, and can disable or soft-delete it, but cannot change its settings. Microsoft requires a sponsor on every agent identity and blueprint, and if a sponsor leaves, sponsorship transfers to their manager so someone accountable always remains. We record both for every agent, including those whose platform holds no field for it, because an agent with only a technical owner is an agent nobody will ever decide to switch off.

Probably not. Copilot Studio began creating an agent identity automatically for every new agent on 18 March 2026; agents created before that, or in an environment that had opted out, authenticate with platform-managed service principals that Entra treats as ordinary applications — so agent-specific Conditional Access and governance do not apply to them. There is no in-place conversion and republishing does not create one. Microsoft's guidance is to classify those agents by usage: decommission the unused ones, recreate medium-usage ones with an agent identity, and leave production-critical ones alone until an automated migration path ships — Microsoft has said existing app-registration agents will be migrated in a future update. We do the classification and the decision record here; recreating an agent is development work, scoped separately.

A maker builds in Copilot Studio, Foundry or the agent builder and publishes to the organization; the agent lands in the Requests queue in the Microsoft 365 admin center as pending review, with its description, owner, data sources, tools and permissions attached. The reviewer we define — with a checklist and a turnaround you chose — checks those against the allow-list for the agent's tier, then either publishes it to a scoped audience with a policy template applied and permissions consented, or rejects it with a reason. Updates to a published agent queue the same way and the old version stays live until approved. Around that queue sit the settings that decide who may share agents and who may use them at all, and the maker page that says what gets approved quickly. We test the whole path with a real submission before calling it live.

Not if it is introduced the way we do it. Policies targeting agent identities and blueprints are created in report-only mode first, so the sign-in log shows what would have been blocked before anything is; enforcement follows your approval. The patterns matter: an agent acting on a user's behalf is evaluated as that user, so the user's existing policies already apply; an autonomous agent using its own identity is where an agent policy bites; an agent reaching your data with an API key is invisible to Conditional Access altogether. We document which of your agents fall into which pattern, and we say plainly that Conditional Access does not apply while security defaults are enabled — a tenant still on security defaults has an earlier conversation to have.

Today, usually nothing — the agent keeps running on a disabled person's ownership until the admin center's "Agents without owners" tile catches it or a connection expires. After this engagement three things catch it: the registry record names a sponsor as well as an owner; the admin-center management rule that reassigns ownerless agent builder agents to the previous owner's manager is enabled where you chose it; and for agents with a Microsoft Entra Agent ID, sponsorship transfers to the departing sponsor's manager automatically, with lifecycle-workflow notifications where licensed. The monthly review then treats any ownerless agent as an action, not a statistic.

Order matters, which is why it is written down. Unpublish or delete the agent in its authoring tool first — Microsoft warns that deleting a Copilot Studio agent's app registration before unpublishing breaks its authentication; then remove its API permissions and connections, disable its Entra identity or block it in the admin center, soft-delete rather than hard-delete so there is a recovery window, and record the retirement with who approved it. The mechanics differ by platform — blocking a SharePoint or Foundry agent in the admin center affects only its availability in Copilot Chat, and only agent builder agents can be deleted from there — so the runbook is per platform. We run it once with you on a real agent so the first retirement is not the one that matters.

All of them, with the honest per-platform differences stated. SharePoint agents are governed by site settings and by the registry once they surface there; agent builder agents are the only ones the admin-center sharing control governs and the only ones the ownerless-reassignment rule can act on; Copilot Studio agents are additionally governed by Power Platform data policies and environment rules and carry Entra agent identities when created after March 2026; Foundry agents receive agent identities automatically and are managed largely from Foundry. The inventory records the platform for every agent, and the runbook says which lever works on which.

Your admins and the sponsors, from the runbook — the monthly checks are ownerless agents, agents at risk, pending requests, expiring access and unused agents, and the quarterly pass re-reads allow-lists and tiers. That is why the first review is run with you inside the engagement rather than described in a document. If you would rather we run it, Managed AI Agent Operations and Optimization is a monthly service with no lock-in; you can stop it at any time. Organizations that buy their Microsoft licensing through IT Partner also have business-hours break-fix support included, so a question about the registry after handover is a ticket, not a quote.

Only if something in your tenant registered agents directly through the old Microsoft Entra agentRegistry Graph API. Microsoft retired the Entra admin center's registry blades on 1 May 2026 in favour of the Microsoft 365 admin center, and retired the legacy API in August 2026 after moving the date back from June; agents created in Copilot Studio or Foundry were never affected, and the replacement Agent 365 registration API requires an Agent 365 license in the tenant. Discovery includes checking whether any custom or vendor agent depended on the old API, and the inventory records what it was replaced with.

Three weeks: discovery and the decisions workshop in the first, registry population, the approval workflow and the identity controls in the second, Power Platform enforcement, the retirement drill, the first review and handover in the third. $4,950 per project, fixed, for one tenant and up to 25 agents, quoted in writing before work begins — you pay after you approve delivery. More agents, several tenants, a Government cloud or a sprawling multi-environment Power Platform estate change the quote, not the shape; recreating legacy-identity agents and testing individual agents are separate engagements and are named as such rather than absorbed.