An illustrative case, not a client engagement: a consultant builds a Copilot Studio agent for a client eight months ago. It reads and writes against Business Central and the client's ticketing system, then the consultant rolls off the project. The credentials never change. The agent still runs today, on a service principal that outlived the contract, the consultant, and the reason it was built. It was never migrated into Microsoft Entra Agent ID, so nobody was ever named its sponsor. Nobody at the MSP can name the owner. Nobody deprovisioned it, because nobody ever put it on a list to check.
That agent is not a security bug. It is an identity, one with credentials, permissions, and a blast radius the same size as a former employee's laptop that never got wiped. Most of the industry conversation about agent risk still points at the wrong layer: hallucination guardrails, prompt injection defenses, output filtering. None of that touches what is actually sitting in the tenant.
A non-human identity is any credential-bearing entity that is not a person: a service account, an API key, an OAuth app registration, or an AI agent. Microsoft's model for the agent case separates owners from sponsors. Sponsors are, in Microsoft Learn's wording, "business representatives accountable for the agent's purpose and lifecycle decisions, including access reviews and agent retention," and "at least one sponsor is required for each agent identity." The gap is every agent identity that never got one.
This is analysis, not a case study of AI agent governance specifically. The lifecycle automation discipline described below runs today for employee identities: 4,500 users at a managed services provider serving pharma, publishing, and education clients. Applying the same architecture to AI agent identities is the extension argument this article makes. It is not a claim that a separate agent-governance product has shipped, or that an agent has been offboarded through this system.
The AI agent governance gap is an identity and access management failure
Vendors selling agent monitoring tools frame the risk as a model problem: agents hallucinating, agents leaking data through a bad prompt, agents doing something the developer never intended. Those are real failure modes. They are also rarely what shows up when a client's compliance team starts asking questions.
Guardz, a security vendor that sells to MSPs, frames it directly in a 2026 blog post: AI agent governance "is not model safety, prompt engineering, or AI policy writing. It is identity and access management applied to a new population of identities." Every agent carries the same three properties as a human user account: credentials that authenticate it, permissions that scope what it can touch, and an access path into systems that hold client data. What it does not carry is anything resembling HR.
A new hire gets a start date, a manager, a termination date, and a reason someone in the building notices when they stop showing up. An AI agent gets provisioned the moment someone with a Copilot Studio license or a Power Automate connector decides to build something. If it lands in Entra Agent ID, Microsoft requires a sponsor. If it does not, it keeps running until someone remembers it exists.
AI agent identity governance gap: what Microsoft Entra Agent ID covers and what it misses
Microsoft closed part of this gap in 2026. Entra Agent ID is generally available, and its sponsor lifecycle templates "automatically transfer sponsorship when an agent identity sponsor changes roles or leaves the organization, to prevent orphaned agents." The Copilot Studio agent inventory, generally available since 31 March 2026, lets admins find "custom agents created by users who left." Microsoft's agent registry experiences are converging under Microsoft Agent 365. If your client tenants run Agent ID, open it before you tell a client nobody owns their agents.
The gap that remains is the set of agent identities those controls do not see. Four patterns to look for in a client tenant:
- Unmigrated builds. Copilot Studio agents and custom app registrations that never moved into Agent ID (Microsoft lists "Migrate Copilot Studio agents" and "Migrate custom app registrations" as migration paths). A consultant's build left running after the engagement ends is the typical case.
- Agents under a person's or a shared account. In a Cloud Security Alliance and Aembit survey of 228 IT and security professionals (fielded January 2026), 31% allowed agents to operate under human user identities and 43% relied on shared service accounts. Aembit sells identity tooling and co-wrote the questionnaire, and the sample is enterprise teams of various sizes, not MSPs.
- Embedded vendor OAuth grants. A SaaS tool's own AI feature, granted an OAuth connection to the client's tenant during setup and never revisited.
- The view across tenants. The Copilot Studio inventory Microsoft describes is tenant-wide. An MSP with many client tenants needs one list across all of them.
These are the patterns the architecture below is designed to look for. They are not a measured breakdown of where agent sprawl comes from, and no source in this article ranks them. Items 1 to 3 do not route through the request process an MSP already governs for human accounts. Item 4 is a problem only an MSP has.
Agents running under a person's account change what an offboarding trigger does. When the agent runs under its builder's login, the exit-date trigger an MSP already runs for employees disables the agent along with the account, and every client process that depends on it stops. Price that outage in before the trigger goes live. When the agent runs under a shared service account, no exit date fires at all, and that is the case that needs an inventory.
The survey evidence on ownership is directional. A Cloud Security Alliance and Oasis Security survey of 383 IT and security professionals (fielded August to September 2025, published 27 January 2026) found that "51% of organizations reported no clear ownership or accountability" and that "78% of organizations don't have documented and formally adopted policies for creating or removing AI identities." Oasis sells identity security and funded the survey, and the sample is enterprise IT and security teams of unspecified size, not MSPs.
Gartner now puts a date on the consequence, and it did so on a conference stage. At Gartner IT Symposium/Xpo 2026 in Orlando, Gene Alvarez, Distinguished VP Analyst at Gartner, gave the Top Strategic Technology Trends for 2027 session and made this prediction (Day 2 highlights, 20 October 2026): "By 2028, 25% of enterprise security breaches will trace back to AI agent abuse due to unmanaged machine privileges and legacy credential practices." It is a prediction made at a conference, not survey data. The consultant's agent that opens this article, still running on its original service principal, is the kind of failure it describes. For the wider list of trends, see Gartner's Top Strategic Technology Trends for 2027 release.
Where AI agent identity governance breaks against the employee lifecycle it should mirror
IntelliConnectQ already runs this discipline for humans. At a managed services provider serving pharma, publishing, and education clients, the same architecture onboards and offboards 4,500 users across 3 continents through MS Graph and Power Automate, with license deallocation and account deactivation firing automatically on the scheduled exit date instead of during a manual evening rush. The table below lines that architecture up against the same five governance stages for AI agents, with Microsoft's native control and what it misses.
| Governance stage | Employee identity (proven, shipped) | AI agent identity (Microsoft's control, and the gap) |
|---|---|---|
| System of record | Every hire logged through a low-code portal, tied to HR intake | Native: the Agent ID registry and the Copilot Studio inventory, per tenant. Gap: unmigrated app registrations and flows are not agent identities there, and no intake process ties any agent to a request |
| Named owner | Reporting officer assigned automatically at onboarding | Native: Agent ID requires at least one sponsor per agent identity. Gap: unmigrated app registrations, shared service accounts and agents under a person's login have no sponsor |
| Access scoping | License tier set by role and department, no manual selection | For an agent running under its builder's account, scope is whatever permissions that account held |
| Ongoing monitoring | Status tracked automatically against the employee record | Native: the Copilot Studio inventory finds agents of departed users in one tenant. Gap: app registrations, embedded vendor OAuth grants and the other client tenants sit outside it |
| Offboarding trigger | Exit date in the portal fires license deallocation same day | Native: sponsor lifecycle templates transfer sponsorship when a sponsor leaves, for identities in Agent ID. Gap: outside Agent ID no exit date exists, no trigger fires, and the agent runs until someone finds it |
The five stages are identical. Inside Agent ID, Microsoft now supplies the owner and the trigger for agents. What's missing is both of them for every agent outside it, plus one view across client tenants.
The table stops at offboarding. The stage after it is the audit record: which identity made this write, and who sponsored that identity. In the Cloud Security Alliance and Aembit survey, "68% can't clearly distinguish between human and AI agent activity." Attribution is the audit half of decision infrastructure: an agent action tied to an agent identity and a named sponsor, not to whichever person's login it borrowed.
Automating the non-human identity lifecycle: what's proven for employees, what's new for AI agents
Be precise about what is actually built here. The proven part is the lifecycle automation architecture: MS Graph identity operations, Power Automate orchestration, and a portal front end that handles onboarding and offboarding for 4,500 users. Standard cases need no manual steps, and one part-time person handles exceptions, down from three full-time staff, as the case study reports. That is shipped, in production, and documented. The case study also describes a Phase 2 that replaces Power Automate with Python and is still being scoped.
The new part is the argument, not a new product. The same inventory, ownership, scoping, monitoring, and revocation discipline extends to AI agents as a second identity class inside the same tenants. IntelliConnectQ has not shipped a distinct "AI agent identity governance" product. What exists is the architecture that already does this work for humans, and a direct case for pointing it at the agents Agent ID does not reach, because the orchestration layer, provisioning tied to a lifecycle event, does not care whether the identity behind the trigger is a person or a service principal.
Guardz, which sells to MSPs, makes the ownership case directly: "MSPs already control the tenant, the licenses, and the identity layer. Governing the AI agents inside those tenants is the same discipline applied to a new class of identity." The field is not empty. Microsoft ships sponsor workflows and an inventory inside each tenant, its registry is converging under Agent 365, and MSP-channel vendors such as Guardz and Josys already pitch agent governance to MSPs. An MSP-run layer has to earn its place on what those leave out: the four patterns above.
The MSP that owns AI agent identity governance owns the client relationship's next chapter
Client-side IT teams at a 50-person manufacturer or a 200-person distributor are not going to stand up an internal function to inventory and govern AI agent identities. Guardz is blunt about who does: "SMBs will not build this function themselves. The MSP is the only party with both the access and the mandate to do the job." That is a vendor's pitch, not a measurement.
A survey of 333 MSPs across North America, Europe and Asia-Pacific, co-published by Omdia and AvePoint (a vendor selling governance tooling to MSPs), found that 51% named data governance and compliance challenges as the biggest obstacle to customer AI deployment. It also found 94% committed to automating AI data readiness and compliance services, with 43% reporting high maturity delivering them (Channel Insider, 10 April 2026; Channel Dive, 17 April 2026). One unnamed MSP executive named the replication cost: "We could build automations for every single one of our clients, but we'd have to do it 700 times."
That obstacle sits in front of every AI service an MSP sells. What an agent inventory and offboarding service is worth per tenant or per seat, and what it takes to stand up in each client tenant, this article cannot price from evidence: IntelliConnectQ has not published a per-tenant effort or price for agent governance, and no figure here is invented to fill the gap.
The window is narrower than it looks. Microsoft's native controls cover agents registered in Agent ID, and vendors are marketing agent governance to MSPs now. The MSPs that can say "we run your agent inventory the way we run your employee lifecycle, including the agents Agent ID never saw" before a client buys a tool for it set the terms of that conversation.
If you cannot currently list every AI agent with write access into a client tenant, its owner, and the date it was last reviewed, in under a minute, that is the signal. If the answer takes longer to produce than the question took to ask, nobody owns it yet.
The fix starts as an inventory sprint, not a governance program. List every agent with tenant access, starting with the Agent ID registry and the Copilot Studio inventory, then the app registrations and shared accounts neither one shows. Name an owner for each one. Set a scope review date. Wire an offboarding trigger to whatever already ends the project or the license. The mechanism, not the specifics, is the one running in production today for 4,500 human users. Point it at the agents next.
Frequently asked questions
What is a non-human identity, and are AI agents one?
A non-human identity is any credential-bearing entity that is not a person: service accounts, API keys, OAuth app registrations, and AI agents. An AI agent qualifies because it authenticates with credentials, holds a defined set of permissions, and can act inside connected systems without a person at the keyboard. In Microsoft Entra Agent ID, which is generally available, every agent identity requires at least one business sponsor accountable for its lifecycle. Agents outside Agent ID, such as unmigrated app registrations or agents running under a human's or a shared account, have no such sponsor.
Does Microsoft Entra Agent ID already solve AI agent identity governance for MSPs?
It covers the agents registered in it. Entra Agent ID is generally available and requires at least one business sponsor on every agent identity. Its lifecycle workflow templates transfer sponsorship when a sponsor changes roles or leaves, and the Copilot Studio inventory finds custom agents created by users who left. It does not cover legacy app registrations nobody migrated, agents running under a human's or a shared service account, OAuth grants embedded in vendor tools, or a single view across your client tenants. In a Cloud Security Alliance and Aembit survey of 228 IT and security professionals, 31% allowed agents to operate under human user identities and 43% relied on shared service accounts. The survey was funded by a vendor and sampled enterprise teams, not MSPs.
Can MSPs extend employee lifecycle automation to AI agent identities without building a new product?
The core mechanism, an orchestration layer that ties provisioning and deprovisioning to a lifecycle event, does not depend on the identity being human. An MS Graph and Power Automate architecture that already handles onboarding and offboarding for employee accounts can be extended to trigger on an agent's project end date or license removal the same way it triggers on an employee's exit date. That is an extension argument: no agent-governance product has shipped, and Microsoft's sponsor workflows already cover agents registered in Entra Agent ID. The MSP-run layer targets the agents outside it.
How do you automate onboarding and offboarding of AI agent identities?
Run the same orchestration layer that handles employee accounts and tie it to a lifecycle event: for an agent, the project end date or license removal replaces the exit date. At onboarding, list the agent in an inventory, name an owner and set a scope review date. At offboarding, wire a trigger to whatever already ends the project or the license. The MS Graph and Power Automate architecture behind this runs in production today for 4,500 users; IntelliConnectQ has not shipped a distinct agent-governance product.
Who should own AI agent offboarding inside a client tenant?
The MSP owns the process, because it is the party that already controls the tenant, the licenses, and the identity layer. Each agent still needs a named business sponsor on the client side, which is how Microsoft Entra Agent ID models it. The MSP's job is to make sure the sponsor exists, the inventory is complete, and the exit trigger fires. In a Cloud Security Alliance and Oasis Security survey of 383 IT and security professionals, 51% of organizations reported no clear ownership or accountability for non-human identities, and the survey was funded by an identity vendor. That is the gap an MSP-run function closes.