A consultant built a Copilot Studio agent for a client eight months ago. It read and wrote against Business Central and the client's ticketing system, then the consultant rolled off the project. The credentials never changed. The agent still runs today, on a service principal that outlived the contract, the consultant, and the reason it was built. 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, increasingly, an AI agent. Each one holds permissions and can act inside a system on its own. Gartner puts 56% of non-human identities entirely outside structured governance today, no inventory, no assigned owner, no lifecycle, cited via Josys, 2026.
This is analysis, not a case study of AI agent governance specifically. The lifecycle automation discipline described below runs today across 7 enterprise MSP client environments (4,500 users, pharma, publishing, and education) for employee identities. Applying the same architecture to AI agent identities is the extension argument this article makes, not a claim that a separate agent-governance product has shipped.
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's 2026 framing cuts through the noise directly: 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, and it keeps running until someone remembers it exists. That is the actual gap. No one owns the agent once it starts running.
Gartner's 56% non-human identity governance gap is an MSP problem to own
56% is not a niche statistic buried in a vendor report. It describes the majority state of every credential-bearing identity in a tenant that is not a human, service accounts, API keys, OAuth grants, and now agents, sitting with no inventory and no named owner.
AI agents inflate that number faster than any other identity type, and the reason is provisioning speed. A service account request usually still routes through IT. An AI agent gets built by a power user, a consultant, or a SaaS vendor's embedded feature, none of whom file a ticket. Three entry points account for most of the agent sprawl an MSP finds once it starts looking:
- Consultant or partner builds. A Copilot Studio or Power Platform agent built for a specific project, left running after the engagement ends.
- Line-of-business automations. A Power Automate flow with its own service principal, set up directly by a department head, with write access nobody in IT ever scoped.
- Embedded vendor agents. A SaaS tool's own AI feature, granted an OAuth connection to the client's tenant during setup and never revisited.
None of these route through the request process an MSP already governs for human accounts. Each one lands with real write access and no expiration date.
Where AI agent identity governance breaks against the employee lifecycle it should mirror
IntelliConnectQ already runs this discipline for humans. An MSP managing infrastructure for 7 enterprise clients now onboards and offboards 4,500 employees 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 how the same five governance stages currently run, or don't, for AI agents.
| Governance stage | Employee identity (proven, shipped) | AI agent identity (the gap) |
|---|---|---|
| System of record | Every hire logged through a low-code portal, tied to HR intake | No portal. Provisioned by whoever holds a Copilot Studio or Power Platform license |
| Named owner | Reporting officer assigned automatically at onboarding | No equivalent role exists. 56% of non-human identities carry no assigned owner |
| Access scoping | License tier set by role and department, no manual selection | Scope defaults to whatever permissions the builder's own account held |
| Ongoing monitoring | Status tracked automatically against the employee record | No inventory exists to monitor against |
| Offboarding trigger | Exit date in the portal fires license deallocation same day | No exit date exists. No trigger fires. The agent runs until someone finds it manually |
The five stages are identical. What's missing for agents is the trigger that starts and ends each one, because nothing plays the role HR plays for a person.
Extending employee lifecycle automation to a new identity class: what's proven, what's new
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 has run 4,500 employee lifecycle events with zero manual onboarding or offboarding steps. That is shipped, in production, and documented.
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 agents next, 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 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." That is the case for building this now, ahead of a dedicated agent-governance vendor selling the same function back to MSPs as a new category next year.
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 mandate has a shelf life. Identity and security platforms are already building agent-governance dashboards aimed at the MSP channel, and the MSPs that can say "we already run your agent inventory the way we run your employee lifecycle" before that pitch lands are the ones setting the terms of the conversation, instead of buying a seat inside someone else's platform.
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. It is the same test the Decision Latency Diagnostic runs for approval and audit gaps generally: 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. 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 identities. 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 now 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. Identity teams increasingly treat AI agents as the fastest-growing subcategory of non-human identity, because they are provisioned outside the request processes that already govern service accounts.
Does Gartner's 56% non-human identity governance stat include AI agents specifically?
The 56% figure, cited via Josys (2026), covers non-human identities broadly: service accounts, API keys, OAuth grants, and AI agents together. It is not an AI-agent-specific measurement. What makes it directly relevant to agents is provisioning speed: AI agents are the identity type most likely to be created outside a formal request process, by a consultant, a department head, or an embedded SaaS feature, which puts them squarely inside the ungoverned majority the statistic describes.
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. This is an extension of proven infrastructure, not a separate build from zero.
Who should own AI agent offboarding inside a client tenant?
The same party that already controls the tenant, the licenses, and the identity layer: the MSP. Client-side IT teams at mid-market companies rarely have the headcount or the mandate to inventory and govern machine identities on their own. Assigning agent ownership inside the MSP's existing identity governance function, rather than leaving it to whichever department built the agent, closes the ownership gap the 56% statistic describes.