SecurityV0 Pilot — Microsoft Azure Discovery Scope & Permissions
Date: 2026-07-20 Supersedes: SecurityV0 Pilot — Azure Permissions Required (2026-02-23) Audience: TPX security and identity teams
Overview
SecurityV0 performs a read-only discovery scan across your Microsoft estate to map AI-agent authority paths — which agents and automations exist, what identities they run as, what permissions those identities hold, what resources they can reach, and who is accountable for each.
The pilot covers three discovery areas, all Microsoft-only:
| Area | What it maps |
|---|---|
| Entra ID identity discovery | Service principals and app registrations: credentials, permission grants, ownership, account status, sign-in recency |
| Azure / AI Foundry agent discovery | AI Foundry accounts, projects, and agents: the identities they run as, their role assignments, connections to downstream resources, and execution activity |
| Microsoft Sentinel SOC automation discovery | Sentinel automation rules and the Logic App playbooks they invoke: the identities those playbooks run as, the permissions they hold, and what actions they can take |
No configuration changes are made to any Azure or Entra resource — every API call the scan makes is a read. The scan runs on our infrastructure using a single app registration you provide; there is nothing to install in your environment.
What We Need
One Entra app registration with the permissions below. Total setup time is ~20 minutes. All access is read-only. The consent model has two parts: the Graph permissions are approved together in one admin consent, and the two Azure RBAC roles (Reader, plus a Foundry read-only role) are separate role assignments you make in the Azure portal — they are not part of the Graph consent.
The License required column lets your team pre-check entitlements before granting: where a Microsoft license is required, the underlying Microsoft API refuses the call on an unlicensed tenant — the scan then runs without that data and marks it as unavailable, rather than failing.
The permission model is deliberately least-privilege: the Baseline tier below is the entire ask for this pilot — exactly the set of APIs our connectors call today, nothing held in reserve. The Future tier is a transparency roadmap of access we do not request now; see that section for how each would be introduced later.
Baseline — required for this pilot
This is the whole ask. Every permission here maps directly to an API our connectors call today.
| # | Permission | Type | Where to assign | What it unlocks | License required |
|---|---|---|---|---|---|
| 1 | Reader | Azure RBAC role | Subscription(s) in scope | Discover Foundry accounts and projects, managed identities, ARM role assignments, Log Analytics workspaces, and Logic App resources. This same grant covers Microsoft Sentinel discovery — no extra role is needed. | — |
| 2 | Foundry read-only role | Azure RBAC role | AIServices / Foundry account(s) | List AI agents, their connections (Azure OpenAI, Search, Storage, etc.), and execution activity. Our connector issues only read (GET) calls; we assign either the least-privileged built-in role that enables agent discovery or, preferred, a custom read-only role scoped to agent and connection reads — see Setup Step 3. | — |
| 3 | Application.Read.All | Graph API (Application) | App registration > API permissions | Read service principal details, credentials, and application-permission grants — needed to map which identity each agent or playbook runs as and what it is allowed to do | — |
| 4 | Directory.Read.All | Graph API (Application) | App registration > API permissions | Read service principal owners and delegated (OAuth2) permission grants — needed to determine who is responsible for each identity | — |
| 5 | User.Read.All | Graph API (Application) | App registration > API permissions | Read owner account status (enabled/disabled) — detects when an owner has left the organization while the agent keeps running. The scan only looks up users registered as technical owners of service principals; it does not enumerate the user directory. | — |
| 6 | AgentIdentity.Read.All | Graph API (Application) | App registration > API permissions | Read the Microsoft Entra Agent ID inventory — discovers AI-agent identities registered in Entra that would otherwise be invisible to the scan. This is Microsoft's least-privileged application permission for the Agent ID list API; it is not covered by Application.Read.All. | — |
| 7 | AuditLog.Read.All | Graph API (Application) | App registration > API permissions | Sign-in activity for service principals and managed identities — enables detection of dormant (unused) identities and stale credentials. This is also the least-privileged application permission for MFA / authentication-method registration posture (the userRegistrationDetails API) of the humans who own and approve agents — no separate permission is needed for that. | Entra ID P1/P2. Without it the scan runs and dormancy analysis is skipped (not failed) and marked unavailable. |
Future — not requested for this pilot
We list these for full transparency so there are no surprises about where the analysis could go. Our current connectors do not call any of these APIs, and we are not requesting them for this pilot. Each is read-only, and each would be introduced as a separate, explicit consent at the point the matching analysis actually ships — never bundled silently into the baseline.
| Permission / role | Type | What it would unlock (future) | License required |
|---|---|---|---|
RoleManagement.Read.Directory | Graph API (Application) | Directory role assignments, plus Privileged Identity Management data (eligible and time-bound role assignments) — which identities could escalate via JIT, not just which are currently privileged | Permission itself: none. PIM data present only on Entra ID P2 / Governance tenants. |
Policy.Read.All | Graph API (Application) | Conditional Access policy inventory, plus the Conditional Access context inside sign-in records — which guardrails applied when an agent identity signed in | — |
Group.Read.All | Graph API (Application) | Group memberships — extends access-path analysis to permissions granted through group membership | — |
IdentityRiskyServicePrincipal.Read.All | Graph API (Application) | Microsoft's own risk assessments for workload identities, correlated with our authority-path findings | Microsoft Entra Workload ID Premium (a separate SKU — not included in P2 or E5) |
| Microsoft Sentinel Reader + Log Analytics Data Reader | Azure RBAC roles | Deeper Sentinel analytics and direct KQL queries against the Log Analytics workspace, beyond the automation-rule and playbook discovery the baseline Reader grant already covers | — |
Setup Steps
Step 1 — Create an App Registration
Entra ID > App registrations > New registration
- Name: any (e.g.
sv0-scanner) - Supported account types: Single tenant
- Note the Application (client) ID and Directory (tenant) ID
- Under Certificates & secrets, create a client secret and save the value — we recommend an expiry of 90 days or less (the pilot fits comfortably inside one rotation window)
Step 2 — Assign Reader role on subscription(s)
Azure Portal > Subscriptions > your subscription > Access control (IAM) > Add role assignment
| Field | Value |
|---|---|
| Role | Reader |
| Assign access to | User, group, or service principal |
| Select | Your app registration |
Repeat for each subscription in scope. Please tell us the exact subscription IDs you assigned — we scope the scan to that explicit list rather than everything the identity can see.
Step 3 — Assign a Foundry read-only role on AIServices / Foundry account(s)
Azure Portal > AIServices / Foundry account > Access control (IAM) > Add role assignment
Our connector only ever issues read (GET) calls against Foundry — it lists agents and their connections and reads execution activity; it never creates, modifies, or deploys anything. Note that Microsoft's built-in Foundry User role (role ID 53ca6127-db72-4b80-b1b0-d745d6d5456d, formerly named "Azure AI User") is not a read-only role: it also grants build/develop data actions (create and modify agents) and listKeys. So that the access you grant matches our read-only behavior, we recommend one of two options:
| Option | What to assign | Notes |
|---|---|---|
| Preferred — custom read-only role | A custom Azure role scoped to agent and connection reads — data actions such as Microsoft.CognitiveServices/accounts/AIServices/agents/*/read and Microsoft.CognitiveServices/accounts/AIServices/agents/connections/read, with no write, action, or listKeys data actions | The granted access is exactly what the scan does — read-only, agent discovery only |
| Alternative — least-privileged built-in role | The least-privileged built-in role that enables agent discovery (e.g. Foundry User) | Simpler to assign, but grants more than the scan uses; choose this only if a custom role is impractical |
Repeat for each account, or assign at resource group level to cover all accounts in the group.
Step 4 — Add Graph API permissions
Entra ID > App registrations > your app > API permissions > Add a permission > Microsoft Graph > Application permissions
Add the baseline set:
Application.Read.AllDirectory.Read.AllUser.Read.AllAgentIdentity.Read.AllAuditLog.Read.All(requires Entra ID P1/P2 for the data to populate; skipped, not failed, if unlicensed)
Then click Grant admin consent for [tenant]. This single admin consent covers the Graph permissions; the Reader and Foundry read-only roles from Steps 2 and 3 are separate Azure role assignments and are not part of this consent.
Step 5 — Share credentials via the 1Password vault
We provision a 1Password shared vault for TPX and send you an invitation. Place the three values below in that vault — never send them by email, chat, or ticket:
Directory (tenant) ID
Application (client) ID
Client secret
See Credential Handling below for how the secret is stored, rotated, and destroyed.
What the Scan Reads
Microsoft Graph (Entra)
- Service principal and app registration details (display name, enabled/disabled, credential types and expiry — never credential values)
- Application and delegated permission grants (which APIs each identity can call)
- Service principal owners (display name, UPN — identifies who is responsible for each identity)
- Owner account status (enabled/disabled — detects orphaned agents after offboarding)
- Entra Agent ID inventory (AI-agent identities registered in Entra)
- Sign-in timestamps (when
AuditLog.Read.Allis granted and the tenant is P1/P2 licensed)
Azure Resource Manager
- Foundry account and project metadata (name, location, endpoints)
- Managed identity principal IDs
- ARM role assignments (role name, scope)
Azure AI Foundry (data plane)
- AI agent metadata (name, model deployment, tools configured, and agent instructions — the instructions are returned inline in the agent list response and are read transiently for classification but never persisted or analyzed)
- Connections to downstream resources (Azure OpenAI, Search, Storage, etc.)
- Execution activity (thread timestamps over the past 30 days)
Microsoft Sentinel (when in scope)
So that there are no surprises, this is the full list of what the SOC-automation discovery reads:
- Sentinel automation rules — triggers, conditions, and which playbooks they invoke
- Recent Sentinel incidents — up to 50 most recent, metadata only (title, severity, status, timestamps), used solely as context linking automation to real activity
- Logic App playbook workflow definitions — the steps a playbook is configured to perform, parsed to classify what actions it can take (e.g. isolate a machine, retrieve device data)
- Logic App run history — timestamps and outcomes of recent playbook runs, as evidence of what actually executed
- API connections — which downstream services each playbook is wired to (connection metadata only; connection secrets are not visible via this API and are never requested)
Coverage note — Consumption vs. Standard Logic Apps: playbook analysis in this phase covers Consumption Logic Apps. Standard Logic Apps are detected and counted, and this is reported transparently, but their internal workflows are not analyzed in this phase. If you use Standard Logic Apps as Sentinel playbooks, tell us up front (see Scoping Questions) so we can agree how to handle them.
What the scan does NOT access
- End-user or customer business data
- User mailboxes, calendars, or files
- Azure resource content (blob data, database records, raw log content)
- Agent conversation messages (user or agent prompts, responses, tool outputs)
- Model weights or training data
- Credential or secret values of any kind (only metadata such as credential type and expiry date)
Note on directory metadata: The scan reads display names and UPNs of technical owners (IT/infrastructure staff registered as service principal owners in Entra). This is directory metadata used for ownership validation — not customer or end-user data. Agent and playbook names and descriptions are captured — review these if they may contain sensitive information.
What the scan does NOT write
- No write, update, or delete operations against any Azure, Entra, or Sentinel resource
- No credential rotation or permission changes
- No configuration changes to Foundry accounts, projects, agents, automation rules, or playbooks
Network Requirements
The scan makes outbound HTTPS calls from our infrastructure to:
| Endpoint | Purpose |
|---|---|
login.microsoftonline.com | OAuth2 token acquisition |
management.azure.com | Azure Resource Manager API (includes Sentinel and Logic App resource reads) |
*.services.ai.azure.com | Foundry Agent Service API (current) |
*.api.azureml.ms | Foundry Agent Service API (legacy Azure ML endpoints) |
*.cognitiveservices.azure.com | Foundry Agent Service API (legacy Cognitive Services endpoints) |
graph.microsoft.com | Microsoft Graph API |
No inbound ports or firewall changes are required on your side.
Credential Handling
How we handle the app registration credentials you share with us:
- Intake — exclusively via a dedicated 1Password vault we provision for TPX alone. We invite up to two of your named administrators as guests (a guest has access to this one vault and nothing else); you place the tenant ID, client ID, and client secret there. The credential must belong to a dedicated app registration — never a person's account, password, or MFA seed. Credentials are never accepted by email, chat, or ticket, and access is limited and auditable on both sides.
- At rest — once loaded into our platform, the client secret is stored AES-256-GCM encrypted in our platform's credential store. It is not kept in plaintext files or configuration. (A managed Azure Key Vault is the production runtime we are standing up for key custody; it is not yet the operational path, and we will not describe it as one until it is.)
- Rotation — you can rotate the client secret at any time; we swap to the new value from the vault with no action needed beyond telling us. We will also rotate immediately on your request or on any suspicion of exposure, on either side.
- Destruction — at pilot end, we delete the stored credential and confirm the deletion to you in writing. You should then delete the client secret (or the entire app registration) on your side, which revokes our access permanently.
- Expiry — we recommend setting the client secret to expire in 90 days or less, so that even an unrevoked credential ages out on its own.
Scoping Questions
Three things we'd like to know before the scan — each affects scope, not permissions:
- Estate size — approximately how many app registrations / service principals does your tenant have, and how many Azure subscriptions are in scope for the pilot? A rough order of magnitude is enough; it lets us size the scan and set expectations for turnaround.
- Standard Logic Apps — do you use any Standard Logic Apps as Sentinel playbooks (as opposed to Consumption)? See the coverage note above; if yes, we will agree explicitly how those are handled in the pilot.
- Pilot boundary — is the pilot scoped to TPX's internal estate only, or should it also cover environments TPX manages for downstream customers? These are different engagement models with different isolation requirements, and we want to agree the boundary in writing before any scan runs.
Checklist
- Answer the three scoping questions above
- Create app registration and client secret (expiry ≤ 90 days recommended)
- Assign Reader role on in-scope subscription(s); send us the subscription IDs (this grant also covers Microsoft Sentinel discovery — no extra role)
- Assign a Foundry read-only role on target AIServices / Foundry account(s) — a custom read-only role scoped to agent + connection reads (preferred), or the least-privileged built-in role that enables agent discovery
- Add the baseline Graph permissions: Application.Read.All, Directory.Read.All, User.Read.All, AgentIdentity.Read.All, AuditLog.Read.All (P1/P2 for data; skipped if unlicensed)
- Click Grant admin consent on the Graph permissions (the two Azure RBAC roles above are separate role assignments, not part of this consent)
- Accept the 1Password vault invitation and place the three credential values there
What We Provide
- The scan runs on our infrastructure — nothing to install in your environment
- A SecurityV0 platform instance for analysis and reporting
- Authority-path analysis and exposure findings for your AI-agent fleet and SOC automation: which agents and playbooks exist, what they run as, what they can reach, who owns them, and the evidence behind each finding
- Written confirmation of credential destruction at pilot end