Agents are being created faster than you can inventory them

The AI conversation in most IT functions is still about whether to adopt. That conversation is over and it was decided without us. People are building agents in Copilot Studio, in Azure AI Foundry, in partner platforms, in open source frameworks, and in whatever came out of the departmental hackathon in March.

Most organisations do not have an AI problem. They have a visibility problem, and it is the same visibility problem they have always had, moving faster.

The permission inheritance issue

This is the part that should worry infrastructure people specifically, because it is our historical debt coming due.

An agent built by a user typically operates with that user's access. If your permission model is tidy, that is a manageable position. If it is a decade of accumulated SharePoint sites with broken inheritance, over-shared drives, and groups nobody has audited since a reorganisation, then the agent does not create a new problem. It makes the existing one queryable in natural language.

A document that was technically accessible but practically buried three folder levels down in a site nobody visits was protected by obscurity. It is not any more. Someone asks a plain question and gets an answer assembled from everything they can technically reach.

The industry data supports the shape of this: a majority of organisations report having no AI governance programme at all, and breach costs run materially higher where shadow AI is widespread, because agents amplify existing permission problems into enterprise-wide exposure.

Why the usual control does not apply

Our instinct is to gate creation. That worked for software installation and it will not work here, for two reasons.

First, agent creation is spread across platforms, several of which are outside your tenant. Blocking one route redirects the traffic rather than stopping it.

Second, the people building these are producing real value. A finance analyst who has automated three days of monthly reconciliation is not going to stop because a policy appeared, and they should not have to. A control that makes the useful thing impossible gets routed around and takes your visibility with it.

Where the effort actually pays

Three things, in this order:

• Fix the permission model. Unglamorous, overdue, and the only intervention that reduces risk regardless of which platform wins. Every hour spent here is an hour that pays back against a problem you already had.
• Get an inventory. You cannot govern what you cannot see. Microsoft's Agent 365 became generally available in May and reaches beyond Microsoft's own platforms to agents built on other stacks, provided they speak Model Context Protocol. Whatever tool you land on, the requirement is the same: a list, with owners.
• Put agents in the joiners and leavers process. When the finance analyst leaves, their agent keeps running with their access. Nobody's offboarding checklist has a line for this yet, and it is the failure that will show up in an audit first.

The position I have landed on

Treat agents as a new class of identity rather than a new class of application. They act on behalf of someone, they hold permissions, they need an owner, a lifecycle and a review date. All of that is machinery we already have and understand, applied to a new object.

An agent is a service account that a non-technical user created without knowing that is what they were doing.

Framed that way, most of the answer is already in your existing controls. The work is extending them, not inventing a governance discipline from scratch, and that framing is what has made the conversation tractable with the people who have to approve it.