Skip to main content

Azure Integration — W1

1. Purpose​

This integration defines how Azure (Entra identity plane) supports W1: Agentic AI Exposure Discovery & Assessment.

Azure’s role in W1 is limited to:

  • Providing a deterministic inventory of execution-capable identities.
  • Providing a standing authority configuration snapshot for those identities.
  • Providing ownership and account state metadata.
  • Providing first-party identity execution evidence (where available and deterministically linkable).

Azure does not:

  • Discover automations in Azure execution surfaces (e.g., Functions, Logic Apps, AKS).
  • Evaluate exposure.
  • Compute effective access.
  • Expand RBAC graphs.
  • Model downstream blast radius.
  • Classify egress.
  • Detect drift.

Exposure logic is defined separately in product/wedges/w1-exposure/.

Azure is the identity-plane authority substrate underlying ServiceNow and Foundry execution.

2. Identity Artifacts Collected​

W1 requires deterministic identification of execution identities used by ServiceNow and Foundry, as well as baseline visibility into identity-plane artifacts in Azure.

The following Azure identity artifacts are collected:

2.1 Service Principals​

  • Identity object ID
  • Application (app) ID
  • Display name
  • Account enabled/disabled state
  • Creation metadata (if available in first-party metadata)
  • Ownership metadata (if present)

Service principals represent non-human execution identities.

2.2 Managed Identities​

  • System-assigned managed identities
  • User-assigned managed identities

For each:

  • Object ID
  • Associated resource (if deterministically observable)
  • Account state
  • Ownership metadata (if present)

Managed identities are treated as non-human execution identities.

2.3 App Registrations (Execution-Linked Only)​

Where app registrations are deterministically linked to execution identities:

  • Application ID
  • Display name
  • Ownership metadata
  • Account state (if applicable)

If an app registration cannot be deterministically linked to an execution identity used by a supported surface, it is not expanded further in W1.

2.4 Human Principals (When Used as Execution Identity)​

Where a supported surface records execution as running under a user principal (e.g., delegated / OBO):

  • User object ID
  • Account state (enabled/disabled)
  • Ownership (implicit — user identity)

This does not imply interactive session presence; it only reflects the identity recorded as the execution principal.

3. Standing Authority Snapshot​

Azure integration captures a configuration snapshot of standing authority associated with collected identities.

Captured artifacts include:

  • Role assignments bound to the identity.
  • Scope of assignment (as explicitly recorded in Azure metadata).

Constraints:

  • Configuration snapshot only (point-in-time).
  • No RBAC graph expansion.
  • No effective permission computation.
  • No inheritance resolution beyond directly observable assignments.
  • No modeling of downstream data access.
  • No privilege escalation simulation.

The integration records what is explicitly configured — nothing inferred.

4. Ownership Signals​

Ownership metadata is collected for identity artifacts where available.

Observable ownership signals:

  • Presence or absence of owner metadata.
  • Owner type (individual vs group, if deterministically recorded).
  • Owner account state (enabled/disabled).

This document defines collection only.

Interpretation of ownership validity (valid/invalid/ambiguous/unknown) is performed in the W1 exposure layer and is not defined here.

If ownership metadata cannot be deterministically resolved, the ownership state remains unknown.

5. Execution Evidence (Identity Plane)​

Where first-party Azure sign-in telemetry is available and the connector has access, the integration may capture execution_evidence for collected identities.

Purpose:

  • Provide evidence-backed confirmation that an identity has authenticated/executed recently in Azure context.
  • Support W1’s “proven vs unproven” posture without inferring downstream data access.

Constraints:

  • First-party records only.
  • Deterministic linkage to the identity object (e.g., by object ID / app ID as recorded in the evidence source).
  • No inference about what was accessed or changed beyond what the evidence record deterministically proves.

If evidence cannot be deterministically linked or is unavailable, execution evidence for that identity remains unknown / unavailable (explicit, not inferred).

6. Deterministic Linkage​

Azure identities may link to execution systems (ServiceNow, Foundry) only through deterministic identifiers.

Permitted linkage mechanisms:

  • Exact identifier alignment (e.g., object ID, application ID) explicitly recorded in both systems.
  • Direct authentication configuration references that resolve to a unique Azure identity object.

Not permitted:

  • Name matching.
  • Partial identifier matching.
  • Heuristic correlation.
  • “Best effort” joins.

If deterministic linkage cannot be established, the identity remains unlinked.

Unlinked identities are preserved in the identity-plane baseline inventory.

7. Reachability and Authorization Modeling Constraints​

Azure provides identity and standing-authority artifacts, but W1 reachability claims require a deterministic path to resource entities via role → permission → resource.

Accordingly:

  • This integration does not compute effective access.
  • This integration does not expand RBAC inheritance.
  • Reachability may remain unknown in W1 when role-to-permission and permission-to-resource edges are not available as directly observable artifacts.

W1 must surface this as an explicit unknown outcome, not an inferred conclusion.

8. Determinism Requirements​

The Azure integration adheres to strict determinism:

  • First-party Azure metadata only.
  • Deterministic joins only.
  • No heuristic inference.
  • No probabilistic reasoning.
  • No expansion beyond directly observable metadata.
  • Explicit representation of unknown states where resolution is not possible.

Azure provides a standing authority baseline, identity inventory, and (where available) identity execution evidence.

Exposure evaluation, reachability analysis, egress classification, risk grouping, and prioritization occur outside this integration.