01 · Keys
Shared keys in chat and wikis
The pilot team pastes a key into Slack. Within a month nobody can say which applications call the resource, and rotation means an outage.
Governance
Azure OpenAI Entra governance: identity before keys
Azure OpenAI Entra governance means every call runs as a named identity already in your directory, with app registrations security can list and revoke. Pexon puts identity and the sanctioned path in place before more teams get keys, so shadow Azure OpenAI traffic stops being the default for industrial estates.
What breaks first
Three failure modes we see after the first pilot
02 · Apps
App registrations without an owner
Each new workload creates another registration. Security cannot list them, works councils cannot scope them, and revoke becomes a rumour.
03 · Shadow
Personal tenants next to the corporate one
When the sanctioned path is slow, people open Azure OpenAI under a personal subscription. The corporate policy still fails — only quieter.
Entra is the control plane Azure OpenAI already has
Azure OpenAI sits inside a subscription you already govern. The missing piece is usually not another product — it is binding every call to an Entra identity that already exists, with managed identities for services and groups for people, so the same directory that protects SharePoint and SAP also protects the model.
That is also how you prove a denial: if the assistant can read a file its caller cannot, the identity model is wrong, and no content filter will fix it.
What we put in place
- Inventory of Azure OpenAI resources, deployments and the app registrations that call them.
- A default pattern: managed identity or Entra group per workload, no long-lived shared keys in application config.
- A sanctioned path that is easier than a personal tenant, so shadow use has somewhere to go.
- Evidence for security: a denied call showing the assistant cannot exceed the caller's entitlements.
- A short runbook for onboarding the next team without inventing a fifth identity model.
Trade-off
Tight identity slows the first demo by a few days. Loose identity slows every quarter after that, when rotation, audit and a works-council question arrive together. If you have one internal tool and one named owner, you can wait — add this when the second team asks for access.
Where this connects
- Cost and quotas — attributable spend once identities exist to bill against
- EU compliance — residency and logging legal will ask for next
- Shadow-AI lockdown — the broader gateway story across every AI tool, not only Azure OpenAI
Questions buyers ask
Why start with Entra instead of with a use case?
Because every use case that ships without a named identity becomes another ungoverned consumer of the same quota. Fixing identity after five teams hold keys means five redeployments; fixing it first means each new team inherits the same pattern.
What counts as a passing identity model?
Every request assumes an Entra group, managed identity or app registration that already exists in your directory, with a denied call proving the assistant cannot read what its caller cannot read. A shared API key in a wiki fails that test.
How do you handle shadow Azure OpenAI use?
Discovery first from traffic and subscription inventory, then one sanctioned path that is easier than the workaround. Prohibition alone moves the traffic to personal tenants you cannot audit.
Does this replace a broader AI gateway?
No. Entra decides who may call; a gateway decides budgets, routing and audit logging across models. Many programmes need both, and the gateway page under Claude covers the shared routing layer when you also run other providers.
Next step
Start with who may call the model
A two-week blueprint at €4,900. We inventory app registrations and Azure OpenAI consumers, define the Entra pattern, and leave you with a sanctioned path the next team can join without inventing a new key.