There is a pattern I have watched repeat across cloud programmes for years, and AI has not changed it — it has accelerated it. A new capability arrives. The organisation wants it quickly. Someone provisions an identity for it, grants it the permissions that make the demo work, and moves on. The demo becomes a pilot, the pilot becomes a service, and the identity keeps every permission it picked up along the way.
With a conventional application this is bad hygiene. With an AI workload it is something worse, because the workload's whole purpose is to read broadly, connect things, and act on what it finds.
Where the risk actually lives
Consider a fairly typical retrieval-augmented assistant: a model endpoint, a search index, a handful of connectors into document stores, and an application identity holding it together. In most of the deployments I have reviewed, the interesting question was never the model. It was the service principal.
What can that identity read? Frequently the honest answer is: far more than the use case needs. A connector granted tenant-wide read access to SharePoint because scoping it properly was fiddly. An IAM role with s3:GetObject on a bucket wildcard because the data team "might add sources later". A managed identity that inherited the permissions of the platform team's deployment pipeline because that was the path of least resistance on a Friday afternoon.
None of these decisions is reckless on its own. Each one was made by a sensible engineer under delivery pressure. But the AI workload sitting on top of them now does something no previous application did: it surfaces whatever it can reach, fluently, to whoever asks. The over-broad permission that used to be a dormant finding in an access review becomes a live disclosure channel. The model is not leaking data. The identity boundary already had a hole in it; the model is simply the first thing that ever walked through.
Why boards don't see it
Partly it is a language problem. "Prompt injection" and "model risk" sound like AI topics, so they end up in the AI section of the risk register, owned by whoever owns AI. "Service principal permissions" sounds like infrastructure plumbing, so it stays buried in the cloud team's backlog. The two registers rarely meet, and the actual exposure sits precisely in the gap between them.
Partly it is a tooling problem. The AI governance products coming to market are built around the model layer — usage policies, content filtering, prompt logging. Useful, but they assume the workload's access to data is somebody else's problem. It usually is somebody else's problem. That is the problem.
And partly, honestly, it is that identity work is unglamorous. Nobody gets a conference talk out of tightening the scopes on an app registration.
What good looks like
The organisations that handle this well do a few unfashionable things. They treat the AI workload's identity as a first-class design artefact — drawn, reviewed and signed off, not generated as a side effect of deployment. They can answer, in one diagram, what the workload can read, what it can write, what it can invoke, and which human approved each of those grants. They scope retrieval to the data the use case needs rather than the data the platform happens to hold. And they re-run that review when the workload changes, because agents and copilots accrete connectors the way old applications accreted firewall rules.
None of this requires new technology. It requires someone with the standing to ask the boring question in the design review and keep asking until the answer is specific.
If your board is discussing AI risk this quarter, here is a more useful question than most of what will be on the slide: for each AI workload we run, can anyone in this room say what its identity can access, and who decided that? If the answer takes more than a week to assemble, that is the finding.