Promptective journal / Guide

Shadow AI in Azure: read the resource inventory

Interpret cloud resource records with permissions, freshness and activity evidence intact.

A navy equipment chassis has an open tray holding two silver modules and one blue module beside a blank ivory tag.
Editorial illustration: the opened equipment tray represents the resources visible inside a defined inventory scope.

Azure resource inventory can reveal organisation-owned AI services that need an owner or policy review. Its results depend on the querying identity, subscription scope, supported resource types and indexing freshness. Pair that inventory with appropriate activity evidence before concluding that a resource is used, unused or unauthorised.

This guide reviews Microsoft's documentation and proposes a read-only reconciliation process. No Azure tenant was tested. Employee use of external or personal AI services remains a separate discovery task covered by the shadow AI coverage guide.

Search across the resource models you operate

Microsoft Foundry's architecture documentation describes resources under the Microsoft.CognitiveServices provider, including accounts with the AIServices kind and projects beneath them. Azure OpenAI accounts and classic hub-based resources have related but different resource models.

An inventory scoped only to one product label or account kind can miss another model used by the organisation. Record the actual resource type and kind, subscription, resource group and location. Use the current provider documentation to interpret those identifiers.

Confirm supported types in the Resource Graph schema browser before relying on a query. The parent account appearing in inventory does not establish that every nested project or model deployment is represented. Reconcile any missing detail with the owning service's API or administrative view.

Place this cloud inventory alongside the other application surfaces:

Start with the path that needs a decision

Browser AI

Typed text, paste, file upload, account instance and delivery state.

Desktop and IDE

Native clients, coding assistants, local files, output and command proposals.

Custom application

Application-to-model APIs, retrieval, responses and application-owned actions.

Agent and MCP

Prompts, tool calls, tool results, server identity and external effects.

Map each claimed control point to a real browser, desktop, API or agent workflow before comparing products.


Treat read permissions as part of the result

The Azure Resource Graph overview requires at least read access to the resources being queried. Microsoft explicitly warns that a REST request spanning subscriptions can return the accessible subset without indicating that the result is partial. When none of the listed subscriptions is accessible, the response is forbidden.

Record the querying principal, intended subscription list and confirmed read scope beside every export. Compare that list with the organisation's authoritative subscription inventory. If a subscription was added during an active session, refresh the context before assuming its resources were included.

Resource Graph's data guidance also documents a default 1,000-record limit. Check truncation and pagination before describing an export as complete. Preserve an explicit unresolved count for subscriptions or pages that could not be inspected.

Record when the inventory became true

Resource Graph maintains an asynchronous index. Microsoft describes change notifications and periodic full scans, while stating that its data is not strongly consistent. A newly created or recently changed resource can therefore temporarily disagree with an inventory response.

The query-strategy guidance recommends checking the source of truth before an irreversible action. Capture the query time, then confirm important discrepancies with the owning resource provider. Avoid converting a momentary absence into a deletion or decommissioning decision.

Our desktop inventory guide asks a similar freshness question for installed software. Keep its collection intervals separate from Azure's indexing behaviour; the two reports have different sources and operating conditions.

Separate configuration, changes and requests

An account record shows resource existence and available configuration fields. Network-access settings and authentication configuration help scope a review. Whether a particular identity may use the resource requires a separate permissions check.

Resource Graph can expose recent configuration changes. The Azure Monitor activity log records management operations, also called control-plane operations. Creating or updating a service is a different event from making an inference request.

Azure Monitor distinguishes those management events from resource logs covering data-plane operations. Resource logs require diagnostic configuration and are not collected by default. Their absence leaves an evidence gap; it cannot establish that a resource received no requests. Review collection timing, scope and retention before interpreting a quiet window.

Separate decision facts from conversation content

Minimum decision facts

Identity, path, policy and detector versions, finding category, outcome and delivery or execution state.

Potentially sensitive content

Prompts, responses, files, screenshots, tool arguments, tool results and excerpts.

Document where each field is processed, retained, accessed and deleted. Verify a content-minimised mode independently for every product.


An available request count still needs context. It may describe an application workflow without identifying the employee, business purpose or information involved. Verify what the specific metric or log actually contains. Avoid collecting prompt or response content simply to fill an inventory field.

Reconcile a bounded set before expanding

Choose a small approved set with known examples: an active AI resource, an idle resource, a recently changed resource and one deliberately outside the querying identity's read scope. Predict the expected inventory result for each before the read-only exercise.

Compare the query with the provider's current record. Check pagination, access gaps and the timing of changes. Where activity evidence is available, compare the stated window and observation point. Label each finding as confirmed, needs owner review or unresolved.

Give every confirmed resource an accountable owner, business purpose and approval status. An unfamiliar resource name can start a review; it supplies no evidence by itself of policy violation. An approved resource may still need a configuration correction.

Test documented claims against observed evidence

Map

Name the exact users, apps, data, devices, providers and agent tools.

Verify

Confirm prerequisites, enforcement points and content boundaries in writing.

Exercise

Run representative allow, warn, redact, approve, block and outage cases.

Decide

Choose the control model that closes the priority paths with acceptable operations and privacy.

Use the same controlled cases for every shortlisted product, then record coverage, outcome, latency, evidence and failure behaviour.


Keep remediation separate from discovery. Restricting access, enabling additional logs or deleting a resource requires its own approval and impact review. The useful deliverable is an inventory whose scope and gaps are visible enough to support that decision. Bring it to a Promptective demo to discuss how cloud evidence fits your wider workforce AI review.

Security review

Map policy to the AI paths your team uses.

Discuss supported browser monitoring, submitted prompt history and the governance decisions your team needs to make.

Map your AI workflows

Website analytics are off.

Shadow AI in Azure: inventory checks | Promptective