Enterprises approve models. But it isn't models that make requests. People, applications and agents do.
You can approve GPT-5, Claude or Gemini all you like. This still won't tell you whether Alice in marketing is allowed to send her document to endpoint A on this particular occasion. The approval answers a question about the model, but the true risk is sitting in the request, and your approved-model spreadsheet has remarkably little to say about requests.
Hence the model is the wrong unit of AI governance. Let's dig in:
Same model, different answer
Picture a firm that has approved one AI model for its staff.
Alice asks it to summarise this morning’s press release. Nobody cares. Then she asks it to summarise a draft acquisition agreement, and the situation changes entirely:
- Should Alice be reading the agreement at all?
- Is it allowed to leave the building?
- Where exactly is it going?
Now suppose an internal app makes the request on her behalf. It’s the same document, but the thing asking is no longer Alice:
- Is the app allowed to fetch the agreement?
- Is Alice?
- Can anyone prove it afterwards?
Then suppose an AI agent does it unprompted, because it decided the agreement was relevant to a task Alice gave it last week. What exactly did she authorise it to do?
Finally, change only the route. Reached through the firm’s enterprise account, the same model may handle the data under agreed terms. Reached through someone’s personal account, it may not. Even with a single provider, how long your data is kept can depend on which service you call.[1]
In every case, the model and organisation stay the same. What changes is the identity, the data, the delegation or the route, and therefore potentially the governance decision.
Your approved-model spreadsheet simply says YES to ALL of them, because it knows about the model and nothing about the request.
Us DevSecOps people have seen this mistake before:
Zero Trust, the thinking behind much of modern security architecture, stopped assuming that anything inside the corporate network could be trusted and started checking each access on its own merits.[2]
An approved-model list risks a related mistake: treating approval of the model as if it authorised every request made to it.
Somewhere along the way, Alice disappears
I hope by now you agree that each request should be checked. However, there's a snag. In many firms, the information you'd need to check it has already been lost. Bear with me:
Here's the usual journey of Alice's request to the AI model:
Alice → internal app → that app's own login → AI model
The app talks to the AI model using one shared login of its own, not Alice's.
So when the request arrives, the AI service can see that the app is calling. It can't see:
- which authenticated user initiated the request;
- what that user is authorised to access;
- whether the application is acting on their behalf, and within what authority.
Every user of the app looks the same. It's kinda like a courier signing for a parcel. You know the courier collected it, but you have no idea who sent it.
This rarely comes down to carelessness. A shared login is easy, but carrying each person's identity through every system takes deliberate effort, and if the AI rules were agreed in procurement rather than by the people building the systems, nobody ever asked for it.
The slightly embarrassing thing is that much of the machinery for this already exists! An extension to OAuth, the standard that lets apps act on your behalf online, already separates two questions that AI governance now badly needs:[3]
- Subject: on whose authority is this being done?
- Actor: who or what is actually doing it?
Microsoft's identity platform uses the same idea to let one system call another while carrying the original user's identity and permissions with it.[4] Many AI systems just don't carry that information on through.
Agentic workflows make this distinction harder to ignore. An agent has its own workload identity; when it acts on a user's behalf, that delegated authority needs to be represented separately. Microsoft's guidance for AI agents treats these as two separate identities.[5]
So "who made this request?" may no longer have a single answer.
You need both: who acted, and on whose authority. Lose either, and any rule you try to apply is working from only half of the story.
Auditability doesn't mean "logging everything"
Once organisations start getting concerned about this, the instinct is to start to log every prompt and response. In a confidential environment this achieves almost the complete opposite.
If Alice's acquisition agreement is sensitive enough to need governance before it reaches a model, copying the whole thing into a second searchable repository called the "AI audit log" deserves more than some cursory examination.
OWASP's logging guidance lists categories that should generally stay out of logs, including:
- access tokens,
- commercially sensitive information,
- sensitive personal data and
- anything classified above what the logging system is cleared to hold.[6]
A confidential prompt archive can very quickly accumulate several of those in the same place.
The evidence governance actually needs is mostly just metadata. That means:
- the subject,
- the actor,
- the requested resource,
- the policy evaluated and its version,
- the decision and its reason,
- the endpoint selected,
- the outcome,
- a timestamp and
- a unique request or correlation ID
Together, these records can show which policy was evaluated, what decision was made and how the request was handled, without building a second copy of the material being governed.
Some cases may justify capturing content, but that should be a policy decision, not just a side effect of someone switching on verbose logging.
Your provider shouldn't be your system of record
A provider can only record the identity and context that reach it. If your application discarded Alice three services upstream, the provider won't be able to recover her from an API key. Nor does it know which internal policy applied, or which version, unless of course you tell it.
Nevertheless, provider telemetry is still useful, but it shouldn't be considered the authoritative record of your firm's governance decisions. The provider executes inference, but your organisation makes the governance decision and should own the evidence.
There is also a portability problem. If your audit trail lives in a vendor's console, changing provider means changing your control system and your audit history as well as where inference happens. Models should be replaceable; governance tied to one vendor makes the control layer less portable.
Proportionate, or bypassed
None of this means every AI request needs a battery of checks.
Alice summarising a public press release barely needs checking at all.
An agent fetching a confidential acquisition agreement deserves a good deal more. The effort should match the risk.
Get the balance wrong, and people will begin to find a way round it. If the approved route becomes slow and fiddly, someone will sign up for their own AI account and put it on expenses. At that point all your carefully written rules are left guarding an empty road.
From inventory to transactions
Approved-model lists remain useful; they tell you which models may be used. But they can't tell you whether a particular use should be allowed.
For that, governance has to see the request: the subject, the actor, the data, the destination, the policy and, increasingly, the action that follows.
This is the shift: from governing an inventory of AI to governing AI transactions.
It also means the decision has to be made somewhere that requests are actually flowing. NIST's cloud-native extension to Zero Trust already names:
- API gateways,
- sidecar proxies and
- application identity infrastructure
as the places where identity-based policy is enforced at runtime.[7] A similar layer is starting to form around enterprise AI.
That raises the question for our next article:
Once governance is in the request path, should the gateway carrying the traffic own the decision, or merely enforce one made by a control plane sitting above it?
*Jason Southgate leads Parakletos AI, a London-based AI and cloud consultancy focused on production AI systems where governance, reliability, and accountability matter.*
He has completed a University of Cambridge programme in data science, machine learning and AI.
Parakletos AI helps organisations use AI without losing control. They put identity, permissions and an audit trail around AI models and tools, so teams can move quickly and the business can account for what happened. This makes the governed route easier than the unmanaged one.
If you would prefer to buy a product rather than build, they can also help you.
References
[1] OpenAI, Data controls in the OpenAI platform. Storage behaviour and Zero Data Retention eligibility by API capability.
[2] NIST SP 800-207, Zero Trust Architecture, 2020. Per-session access to individual resources, determined by dynamic policy including identity and contextual attributes.
[3] IETF RFC 8693, OAuth 2.0 Token Exchange, 2020. Distinguishes delegation from impersonation. The actor claim represents the party exercising delegated authority on behalf of the subject.
[4] Microsoft Identity Platform, On-Behalf-Of flow. Propagating a user's delegated identity and permissions through a middle-tier API.
[5] Microsoft Foundry, Use on-behalf-of flow with hosted agents. Separate workload authentication and delegated user context for agents calling downstream APIs.
[6] OWASP, Logging Cheat Sheet. Data to exclude from application logs, including access tokens, commercially sensitive information and higher-classification data.
[7] NIST SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments, 2023. Runtime enforcement of identity-based policy using API gateways, sidecar proxies and application identity infrastructure.