Anomity Integrates with Azure AI Foundry
- Anomity now connects to Azure AI Foundry and Azure OpenAI. Across your subscriptions, the connector reads each Foundry or Azure OpenAI account, its model deployments and projects, and the governance settings around them.
- It checks the things that decide whether a model service is governed: diagnostic settings (whether prompts are logged anywhere), content filters and whether they block or only annotate, API-key versus Entra-only authentication, public network access and managed identity.
- Findings come from the same cloud AI posture policy as AWS Bedrock, so a rule like 'require prompt logging' is written once and holds in both clouds.
- Setup reuses the tenant your Microsoft Entra connector already proved, so there is no second consent. The only extra step is giving Anomity the built-in Reader role on a subscription or management group, with a one-click Deploy to Azure template.
- No secret is stored. Revoking access is removing one role assignment in your own portal.
- A fact Anomity could not read is reported as a gap, never as a pass: 'no content filter' and 'could not read the content filters' never look the same.
Anomity now integrates with Azure AI Foundry and Azure OpenAI. Connect your Azure subscriptions and Anomity reads every Foundry and Azure OpenAI account in them, their model deployments and projects, and the settings that decide whether those model services are governed: logging, content filters, authentication and network exposure. The results land in the AI Applications inventory, under the same cloud AI posture policy that governs AWS Bedrock. The connector is available today from Settings, under Integrations, and ships together with the Microsoft Entra connector, whose consent it reuses.
Why Azure AI Foundry, and why now
Plenty of companies run models in their own Azure tenant rather than calling an AI vendor directly, because the data agreement, the region and the identity plane are already in place. That is a sound choice, and it moves the governance questions into Azure: is anything recording what is sent to the model, is a content filter actually blocking, and can someone call the service with a key that sidesteps Entra entirely? None of that runs on a laptop, so no endpoint sensor will see it.
They are the same questions we ask of Bedrock, and they deserve the same answers in the same place. Prompt and response logging is the foundation of an audit trail for AI agents, and a static key on a model endpoint is exactly the kind of credential our explainer on AI identity security argues should give way to a scoped identity.
What the connector reads
| From Azure | What Anomity records |
|---|---|
| Foundry and Azure OpenAI accounts | One row per account, carrying its posture: whether API-key (local) authentication is enabled or the account is Entra-only, whether public network access is open, whether it has a managed identity, and whether diagnostic settings send its activity anywhere. |
| Content filters | The content-filter policies defined on the account and their mode: blocking, or annotate-only, which records what it finds and lets the response through. |
| Model deployments | One row per deployment, with the content-filter policy it uses. |
| Projects | One row per Foundry project. |
| What could not be read | A visible row naming subscriptions or facts discovery could not reach, so a gap never reads as a clean account. |
Only AI Services (Foundry) and Azure OpenAI accounts are swept. Speech, Vision and Translator accounts share the same resource provider but answer none of these governance questions.
What it flags
Azure findings come from the cloud AI posture policy, the same type that governs Bedrock. Each cloud's settings map onto the same checks, so a customer writes 'require prompt logging' once rather than once per cloud.
| Check | AWS Bedrock | Azure AI Foundry |
|---|---|---|
| No log of prompts and responses | Model invocation logging off | No diagnostic settings |
| No guardrail | No guardrail defined | No content filter defined |
| Guardrail does not block | Guardrails defined, none enforced account-wide | Content filter in annotate-only mode |
| Access outside identity controls | Static API key in the AgentCore credential vault | API-key authentication enabled |
| Open network | - | Public network access enabled (off by default) |
| Discovery gap | Account could not be read | Subscription or fact could not be read |
Two of the Azure checks have their own defaults. Requiring Entra-only authentication is on, because a key bypasses Entra and therefore every Conditional Access policy the organization relies on. Flagging public network access is off, because plenty of legitimate services are public behind their own network rules. An annotate-only filter is reported as a filter that does not block, not as a guardrail that is not enforced: the filter is applied, it simply lets everything through, and the finding says so. Findings route to the SIEM, Slack or ticketing like every other Anomity finding.
How setup works
Azure needs no new consent and stores no secret. The Entra connector has already proved which tenant is yours; what Azure additionally requires is a role assignment, the Azure counterpart of deploying the read-only role for AWS.
- Connect Microsoft Entra ID first. The Azure card reuses that tenant, and refuses to be created before it exists.
- On the Azure card, click Deploy to Azure. It opens your own Azure portal with a template that assigns the built-in Reader role to Anomity's application. Deploy it at a subscription, or at a management group to cover every subscription under it, including ones created later. Redeploying is a no-op, not a duplicate assignment.
- Alternatively, assign the Reader role to Anomity's application by hand in the Azure portal, at the same scope.
- Test, then sync.
One sentence on the card saves the most common mistake: Azure RBAC is not an Entra role. An administrator who has just granted Entra consent reasonably assumes access is in place, and assigning something called reader in the Entra admin center grants Global Reader, which reads the directory and grants nothing in Azure. The Reader role has to be assigned on the subscription or management group. Revoking Anomity's access is removing that one assignment.
Built to tell a gap from a pass
Every call is independent, so a setting one subscription will not return costs that one fact, not the sweep. The connector distinguishes 'no content filter is defined', which is a finding, from 'the content filters could not be read', which is a gap, because collapsing the two would turn every unreadable account into a false finding or every false finding into silence. A whole subscription that fails is counted separately from a single unreadable setting, and a sync fails outright only when every subscription failed, so one unreadable diagnostic setting never aborts an otherwise good inventory.
How Anomity and Azure fit together
Azure provides the controls: content filters, diagnostic settings, Entra authentication, private networking. Anomity checks whether they are switched on across every subscription, and puts the model services you run in Azure in the same inventory as everything else. Inside the same tenant, the Entra connector covers the agent identities and consented apps, a split we explore in Microsoft Agent 365 and Entra Agent ID. Across clouds, the same posture policy covers AWS Bedrock, Google Cloud Vertex AI and Cloudflare, and direct vendor accounts are covered from the OpenAI API platform.
On the endpoint, the Endpoint Sensor inventories agents, MCPs, extensions, skills, secrets, hooks, CLIs and local LLM runtimes and decides allow, deny or log at the agent hook before a tool call runs, and the Browser Sensor covers AI web services. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. To see the AI running in your own Azure subscriptions, book a 30-minute demo.
Frequently asked questions
What does the Anomity Azure AI Foundry integration do?
It connects your Azure subscriptions to Anomity's cloud discovery and reads every Azure AI Foundry and Azure OpenAI account in them, with their model deployments and projects. For each account it records how callers authenticate, whether it is reachable from the public internet, whether it has a managed identity, whether diagnostic settings send its activity anywhere, and which content-filter policies exist and in what mode, plus the content filter each deployment uses. All of it lands in the AI Applications inventory, and the cloud AI posture policy turns governance gaps into findings.
Do I need the Microsoft Entra connector first?
Yes. The Azure connector reuses the tenant your Entra connector proved at admin consent, so there is no second consent, and Anomity never accepts a tenant ID typed into a form, which would let one customer point it at another's subscriptions. Creating an Azure connector before Entra is refused up front rather than failing at the first sync.
What access does Anomity need in Azure?
The built-in Reader role for Anomity's application, assigned at a subscription or a management group. A management group covers every subscription under it, including ones created later. The connect card offers a Deploy to Azure link that opens your own portal with a template assigning exactly that role, and redeploying it changes nothing. Nothing is stored on Anomity's side, and revoking access is removing the role assignment.
I assigned 'Reader' in Entra and the connector still cannot see anything. Why?
Azure role-based access control is not an Entra directory role. Assigning a reader role in the Entra admin center grants Global Reader, which reads the directory and grants nothing in Azure. The Reader role has to be assigned on the Azure subscription or management group, in the Azure portal, which is what the Deploy to Azure template does. This is the most common mistake with this connector, so the card says it in those words.
What does the integration flag?
Diagnostic settings that leave a model service with no log of prompts or responses, no content filter, a content filter that only annotates and lets everything through, API-key authentication left enabled so callers can bypass Entra and Conditional Access, and accounts or facts discovery could not read. Flagging public network access is available and off by default, since plenty of legitimate services are public behind their own network rules.
Why is API-key authentication flagged by default?
Because a caller holding a key reaches the model service without an Entra identity, and therefore outside every Conditional Access policy the organization relies on. Requiring Entra-only authentication puts the model service behind the same identity controls as everything else.
Which Azure resources are covered?
Azure AI Foundry (AI Services) and Azure OpenAI accounts, their model deployments and their projects. Speech, Vision and Translator accounts share the same Azure resource provider but answer none of these governance questions, so they are not swept.
Why is Azure a separate connector from Microsoft Entra?
They are different planes. Entra is the directory and Azure Resource Manager is the resource plane; they fail independently, are often owned by different teams, and a tenant can exist with no Azure subscription at all. Keeping them separate means a problem in one never marks the other as broken.
