1Security + Azure AI Foundry
Foundry runs your agents. 1Security shows what they can reach - and what they burn.
Azure AI Foundry is where platform teams build production agents: models, tools, knowledge, deployments. What no project view shows is the Microsoft 365 side of those agents - which SharePoint sites their knowledge sources resolve to, what sensitive data sits inside, and which Entra identity each one acts as. 1Security walks your subscriptions with two reader roles, matches every Foundry agent to its Entra identity, and brings its instructions, tools and knowledge sources onto the same graph as your users and files. Grant the metrics roles too, and its tokens and dollars land next to its reach.
- 2 rolesReader + Azure AI User - all the Azure-side access discovery needs
- 0Microsoft 365 licenses involved - Foundry coverage is an Azure role assignment
- Same dayfrom role grant to the first Foundry agent inventory with reach
What Foundry does
The workshop where the serious agents get built.
Three design decisions that make Foundry the platform-team choice - and the reason its agents deserve estate-level visibility.
Models, tools and knowledge in one place
Model deployments, tool wiring, knowledge indexes and evaluation in one project. Foundry is where production-grade agents get built - the ones that will still be running in three years.
Agents with real identities
Foundry agents carry Entra Agent ID identities, so each one is a principal your directory already knows - the precondition for holding an agent to the same standard as an account.
Grounded on your tenant
SharePoint grounding and knowledge bases let a Foundry agent answer from your Microsoft 365 content, permission-trimmed to the asking user - the same sound design decision Copilot made.
The estate question
A project shows one agent from the inside. Who sees them all?
A Foundry project shows the agent from the inside: its model, its instructions, its connections. Nobody standing inside one project sees the estate - how many agents exist across all subscriptions and projects, which of them ground on SharePoint, and what those knowledge sources actually contain once resolved to files.
The inventory signal lives on the Azure side. Foundry interaction records reach the Microsoft 365 audit log as prompt-only skeletons, so the configured knowledge surface - subscriptions, AI accounts, projects, typed connections, knowledge bases - is where an agent census has to be read from.
And spend lives in a third place: Azure Monitor meters tokens per deployment and model, Cost Management meters dollars per resource. None of it joins itself to identity or data reach. That join is exactly what a security team needs and exactly what no single console holds.
What 1Security adds
Every subscription walked, every agent on the graph.
1Security reads the Azure side with reader roles and the Microsoft 365 side with the same read-only consent as everything else - and joins the two.
- 01
Discovery across subscriptions
The walk goes subscriptions → AI accounts → projects → agents, and matches each agent to its Entra identity. Instructions and tools are captured with drift hashes, so "someone edited the system prompt" is a diff and a notification, not a mystery.
- 02
Knowledge resolved to content
SharePoint grounding connections and search knowledge bases are resolved to the sites and files behind them, with the sensitive types inside. Declare a type off-limits to AI, and a Foundry agent still reaching it is a listed violation.
- 03
Watched like every other identity
Each agent gets an anomaly baseline of its own, and a grounding-escalation detector raises an episode when a knowledge source widens onto restricted data. Injection payloads planted in grounding sites are flagged before the agent reads them.
- 04
Tokens and dollars, metered
Add Monitoring Reader and Cost Management Reader, and prompt and completion tokens per deployment and model, dollars per meter, and per-run usage from the project data plane land in one ledger - kept as history beyond Azure's retention window, next to interaction counts from the audit log.
How the two fit together
Foundry builds and runs. 1Security measures and joins.
Foundry stays the workshop: models, deployments, evaluation. 1Security connects on the Azure side with reader roles on the subscriptions and projects, and on the Microsoft 365 side with the same read-only consent that maps your users, files and apps. The two halves meet on one graph: the agent, its Entra identity, its knowledge reach into sites and files, the people who run it, its anomalies and its spend. No SDK changes, nothing deployed into your projects, nothing in the request path.
The recurring meeting
Which Foundry agents can reach the finance site?
A platform team runs dozens of agents across several subscriptions. Security asks the estate question: which of them can reach the finance site, and what else do their knowledge sources cover? Answering from inside Foundry means opening every project and reading every connection by hand.
With the walk in place, it is a filter: every Foundry agent, its knowledge sources resolved to sites, the sensitive types inside, sorted by reach. An instructions edit shows up as drift the same day it happens, attributed and diffable.
And each quarter, the other number arrives in the same row: tokens and dollars per agent, next to reach per agent - the two columns that decide which agents earn their keep and which were an experiment nobody switched off.
Integration status
Where the integration stands.
Discovery uses ARM with Reader on the subscriptions and the Azure AI User role on the Foundry projects; agent definitions and per-run usage come from the project data plane, and knowledge bases from the search service they live on. Token metrics add Monitoring Reader; dollars add Cost Management Reader. Everything is read-only, revocable in Azure at any time, and none of it involves a Microsoft 365 license. The Microsoft 365 half - identities, sites, files, audit log - rides the standard 1Security read-only consent.
Count your Foundry agents before the next audit asks.
Two reader roles on the Azure side, and by the end of the day: every agent across your subscriptions, what it can reach in Microsoft 365, and what it burns.
Or keep the agent list in a spreadsheet per project.