Microsoft permissions

Every Microsoft Graph, Azure Resource Manager, Dataverse and Exchange permission Softwarden requests, which feature needs it, which phase introduces it, and whether the current code already uses it. Also lists the non-Microsoft services that receive data or credentials (HaloITSM, Okta, Google Workspace, Anthropic), because an administrator reviewing access needs them in the same place.

Adapted from IT1’s docs/PERMISSIONS.md (IT1: the earlier Django monolith, stackbox) and reorganized by this repository’s discovery sources (DEVELOPMENT_PLAN.md §2.5), sign-in and email. Keep it current: any change to a Microsoft endpoint or permission updates this file in the same commit (CLAUDE.md working rule 5).

How to read this file

Status of each permission:

Verification. Every endpoint and permission must be verified on Microsoft Learn before the phase that implements it (CLAUDE.md working rule 5; IT1 working rule 8). The Learn check column records what has actually been checked:

• “IT1, date” means IT1 recorded a Microsoft Learn check on that date. It is carried over as a citation, not re-verified in this repository. The implementing phase re-checks it and replaces the entry with its own date.
• “Not verified” means no Learn check is on record for this repository or its donors.

No permission in this file has been verified on Microsoft Learn from this repository yet (Phase 0, 3 November 2026).

Principles

• Read-only. Every discovery permission reads. No Softwarden feature writes to Entra, Azure, Power Platform or Halo. The one send permission (Mail.Send) is scoped to a single shared mailbox through Exchange RBAC for Applications.
• Softwarden never grants permissions or consent itself. Settings pages and the guided walkthrough explain what to grant; an administrator grants it.
• Separate app registrations. Use one registration for sign-in (delegated only, which holds only when it is not shared with discovery) and a separate one per background purpose (mail, discovery), so each holds only its own permissions. IT2 today reuses the sign-in registration for the Entra connector (core/oidc.py docstring: “they name the same app registration as the discovery connector”); from Phase 6 the walkthrough recommends separate registrations, following IT1.
• Secrets are write-only. Client secrets entered in the UI are Fernet-encrypted under the credential keyring (core/credentials.py: SOFTWARDEN_CREDENTIAL_KEYS, or the key generated on first start; the pre-Phase-1 SOFTWARDEN_SECRETS_KEY only decrypts) with the id of the key stored beside each value, and never appear in responses, audit snapshots, logs, exports or job arguments.
• Checks need no extra permission. Connection tests and access checks make the same reads as a run, limited to one item. A token alone doesn’t prove every subscription, environment or mailbox works; results say which parts were verified.

Summary

The current code requests from Microsoft the delegated openid profile email sign-in scopes and, for the discovery connectors, client-credentials tokens: one for https://graph.microsoft.com/.default, and since Phase 6 Sources B one for https://management.azure.com/.default (azure), one per Dataverse environment https://<env>.crm[N].dynamics.com/.default and, with All environments, one for https://service.powerapps.com/.default (powerplatform). Each token is sent only to its own resource’s host (discovery/graph_source.Audience). The Graph token relies on the consented application permissions above: Application.Read.All (entra), LicenseAssignment.Read.All (entra_licenses), AuditLog.Read.All and Directory.Read.All (entra_shadow_it), Synchronization.Read.All and Policy.Read.All (entra_coverage, Phase 11, with Application.Read.All), and optionally User.ReadBasic.All and AgentIdentity.Read.All. IT2 sent email over SMTP only (SOFTWARDEN_SMTP_*); Phase 5 adds per-organization Graph sendMail (client credentials, Mail.Send through Exchange RBAC for Applications) with SMTP as the fallback, on the same token endpoint and Graph host.

---

Sign-in: Entra OIDC

Status: built, simulated providers only. Per-organization OpenID Connect (core/sso.py, core/oidc.py, core/oidc_discovery.py): authorization code flow with PKCE (S256), state and nonce; the provider’s discovery document and signing keys (RS256 or ES256 only, and only those the document lists; one refetch of the key set on an unknown key id); ID token checks for issuer, audience (azp too when present), expiry, nonce and the preset’s own rules. The Entra preset takes the tenant GUID and builds https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration (never common, organizations or consumers); the document’s and the token’s issuer must be https://login.microsoftonline.com/{tenant}/v2.0, the token’s tid must be the tenant, and an identity is pinned on tid + oid (sub is pairwise per app). The secret is sent in the form (client_secret_post), as before. The redirect URI is {SOFTWARDEN_BASE_URL}/api/v1/auth/oidc/callback. The installation-wide SOFTWARDEN_OIDC_TENANT, SOFTWARDEN_OIDC_CLIENT_ID, SOFTWARDEN_OIDC_CLIENT_SECRET remain as a legacy Entra configuration for a single-organization installation.

Learn check, 2026-11-07 (researcher, Phase 8 research digest): the discovery URL for a tenant GUID, the issuer https://login.microsoftonline.com/{tid}/v2.0, using the tenant GUID rather than common, pinning on (tid, oid), sub being pairwise per application and email / preferred_username being mutable. Not verified in this repository: the scope names below and the token endpoint’s client_secret_post (carried over from IT2’s working code); nothing has contacted a real tenant.

• No offline_access; no tokens are stored. No application permissions on the sign-in registration, provided it is a separate registration (the legacy environment settings were documented as the discovery connector’s registration; per-organization settings should name a sign-in-only registration). No group claims: roles are assigned in-app (D6).
• Sign-in matches an existing member of the organization only; nobody is created by sign-in (a later Phase 8 package adds optional auto-provision with no role).
• The test sign-in (draft / test / activate) is a real delegated sign-in with the same scopes and needs no extra permission.
• Okta and Google (not Microsoft, no Microsoft permission). Okta: discovery https://{domain}/.well-known/openid-configuration (org authorization server, issuer https://{domain}) or https://{domain}/oauth2/{id}/.well-known/openid-configuration (custom server, issuer https://{domain}/oauth2/{id}, default for the default one); pinned on iss + sub; email_verified required. Google Workspace: discovery https://accounts.google.com/.well-known/openid-configuration; iss is https://accounts.google.com or accounts.google.com (both accepted, pinned as the first); pinned on sub; hd must be a configured Workspace domain (checked on the server); email_verified required, also as the string “true”. Scopes openid profile email; the secret goes by HTTP Basic (client_secret_basic) when the document lists it, else in the form. From the same research digest, 2026-11-07; not checked against a real Okta or Google tenant.

Sign-in: SAML (enterprise)

Status: built (Phase 8, ee/saml, capability sso.saml), simulated identity provider only. No permission is requested and Softwarden calls no Microsoft (or other) endpoint: the browser carries the AuthnRequest (HTTP-Redirect) to the IdP and the signed Response (HTTP-POST) back, and the IdP’s metadata is pasted into the settings, never fetched. To use Entra ID as the IdP, an Entra admin creates an enterprise application with SAML single sign-on and gives it the organization’s SP values from Admin › Sign-in (saml in GET /sso/settings): Identifier (Entity ID) {SOFTWARDEN_BASE_URL}/api/v1/auth/saml/<slug>/metadata and Reply URL (ACS) {SOFTWARDEN_BASE_URL}/api/v1/auth/saml/<slug>/acs, then pastes the app’s Federation Metadata XML into Softwarden. Assigning users to that enterprise application is Entra’s own setting and needs no Graph permission. Not checked against a real Entra tenant.

Discovery source: entra

Status: built (Phase 6 Sources A), run against the simulated tenant only; live acceptance on the owner-approved dev tenant is pending. discovery/entra.py on discovery/graph_source.py (client, throttling, error wording) and core/graph.py (transport). Client credentials against https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token, scope https://graph.microsoft.com/.default, from the connector’s tested MicrosoftConnection. Learn check 2026-11-06: docs/research/phase6-discovery-microsoft-learn.md §0 and §1.

GET https://graph.microsoft.com/v1.0/servicePrincipals?$expand=owners($select=id,displayName,mail,userPrincipalName)&$top=100
GET https://graph.microsoft.com/v1.0/applications?$expand=owners($select=id,displayName,mail,userPrincipalName)&$top=100
GET https://graph.microsoft.com/v1.0/servicePrincipals/microsoft.graph.agentIdentity?$top=100     only with scope include_agent_identities
GET https://graph.microsoft.com/v1.0/{applications|servicePrincipals}/{id}/owners?$select=id,displayName,mail,userPrincipalName&$top=100
    only for an object whose expanded owners hit the 20-item $expand limit
    (every list follows @odata.nextLink, only on graph.microsoft.com; a full listing every run, no delta query)

• Merged by application (client) ID. A registration and its enterprise app are one observation, keyed by appId (an agent identity by its object ID). Since discovery 0010 the IT2-era observations are re-keyed in place (they were keyed by the service principal’s object ID), so decisions stay.
• Credentials. passwordCredentials and keyCredentials come with the default properties of both lists; the lists use no $select, because $select=keyCredentials is throttled to 150 requests a minute per tenant (Learn, verified). Key material is null on lists; the secret’s hint (its first three characters) is never stored. One credential per keyId (registration before enterprise app, certificate before secret: a certificate-backed credential appears in both lists). Stored in DiscoveredCredential with the end date’s UTC day.
• Owners. Expanded on each list. With Application.Read.All alone, a user owner comes back with its id and @odata.type and every other property null (Learn, verified); the run notes how many owners came back unnamed and the API shows each as resolved: false, the named gap “owner not resolved”. Owners are matched to People by Entra object ID (a Person whose user signed in with Entra under that ID, core.UserIdentity), else by email. $expand=owners on the two list calls is what IT2 already used on service principals; that it behaves the same on /applications is to confirm live. $expand returns at most 20 related objects and no next link, so an object whose expansion comes back with 20 owners has its owners read again from /{applications|servicePrincipals}/{id}/owners, paged (same permission); only those objects cost an extra call.
• Microsoft first-party apps are skipped by default and counted under “published by Microsoft”: appOwnerOrganizationId in the scope’s first_party_tenants, by default f8cdef31-a31e-4b4a-93e4-5f571e91255a (Microsoft Services: verified on Learn) and 72f988bf-86f1-41af-91ab-2d7cd011db47 (Microsoft’s corporate tenant: kept from IT1, not on Learn). The list is editable per connector. Managed identities, legacy and social-IdP principals are skipped as “not an application”; disabled apps by default.
• AI agents (DECISIONS 2026-11-06 Phase 6 (a)): tags AgentCreatedBy:CopilotStudio, AgenticApp, AIAgentBuilder, AgenticInstance or power-virtual-agents-* (verified on Learn, Copilot Studio to Agent ID migration page, 2026-06-15), or servicePrincipalType ServiceIdentity / #microsoft.graph.agentIdentity, make the observation kind ai_agent. Learn has no tag named AIAgent. Whether Application.Read.All alone returns agent identities in GET /servicePrincipals is to confirm live; both paths are handled (same object ID, one observation), and include_agent_identities decides for both: off, an agent identity from either list is skipped and counted as “agent identity (not included)”. Agent identity blueprints (#microsoft.graph.agentIdentityBlueprint in /applications, …BlueprintPrincipal in /servicePrincipals) are kept as applications flagged agent_blueprint, never as agents, and the run notes how many it saw; how they list on a real tenant is to confirm live.
• Throttling and time limits. 429 (and 503) are retried after Retry-After seconds, else with exponential backoff (2, 4, 8 … s, capped at 120 s), at most 8 retries per request, within 15 minutes of waiting per run (core/graph.Budget). A Retry-After above 120 s stops the run instead (retrying early only counts against the limit). Every run also has a 40-minute wall-clock limit, requests and waits together, checked before each request (discovery/graph_source.RUN_DEADLINE), so a slow or throttled tenant can’t hold the worker past the one-hour stuck-run reaper. Either way the run fails readably and changes nothing.
• 401 is the token not being accepted (authentication, not a permission): the run signs in again once and retries; a second 401 fails with “didn’t accept the app’s token”.
• Errors. A refused list names the permission: 403 Authorization_RequestDenied reads “Microsoft Graph refused to list app registrations (403 Authorization_RequestDenied): the app needs the application permission Application.Read.All with admin consent”. Messages carry the status and Graph’s error.code, never Microsoft’s message text, a token or a secret.
• Empty-listing guard. If a list comes back empty (200 with an empty value: revoked consent, a filtered or faulty page) while live observations or discovered credentials came from it, the run fails with “Nothing was changed”, naming the list: no observation goes “no longer seen” or loses its enterprise app or registration, and no discovered credential is removed. That holds for both lists together and for each on its own (the enterprise app list alone would make apps without a registration go; the app registration list alone would remove the registrations’ credentials). The same guard covers entra_licenses and halo (their one list), azure (each resource list per subscription and Automation account) and powerplatform (each environment’s agent and flow lists). Observations already gone, in a scope the run couldn’t read, or out of the connector’s scope don’t count, and a new connector has nothing to lose. When they really were deleted, the refusal says what to do: an Admin runs the connector once with “accept empty listing” (accept_empty_listing: true on POST /connectors/{id}/run): that one run skips the guard, marks those observations “no longer seen” and removes their credentials, and is recorded on the run (counts.accept_empty_listing) and the connector.run_requested audit event; scheduled runs never set it and later runs are guarded again. Deleting the connector and adding it again also works but loses its candidates’ links to records and its dismissals.
• The simulated tenant (discovery/entra_simulator.py, tenant simulated) answers these calls as Learn documents them, including 403 Authorization_RequestDenied per missing permission, id-only owners without User.ReadBasic.All, and 429 with and without Retry-After.

Discovery source: entra_licenses

Status: built (Phase 6 Sources A), simulated tenant only. discovery/entra_licenses.py, its own connector (source entra_licenses, capability discovery.entra), usually on the same Microsoft connection as entra. Learn check 2026-11-06 (List subscribedSkus).

GET https://graph.microsoft.com/v1.0/subscribedSkus?$select=skuId,skuPartNumber,appliesTo,capabilityStatus,consumedUnits,prepaidUnits

• The list supports $select only (no $filter); no paging is documented, but a next link would be followed (on graph.microsoft.com only).
• Seats (DECISIONS 2026-11-06 Phase 6 (e)): purchased is prepaidUnits.enabled, assigned is consumedUnits; warning, suspended and lockedOut are stored beside them (seats_warning, seats_suspended, seats_locked_out) and never count as purchased. A suspended SKU therefore shows 0 purchased.
• Counts are assignment, not usage. Discovery updates seat counts only on a pool explicitly bound to the SKU with seat sync on (D8 exception, audited as a system edit; the reconciliation package); SKUs no pool has are listed as unbound proposals (money/licences.unbound).

Discovery source: entra_shadow_it

Status: built (Phase 11, item 1), simulated tenant only; nothing has contacted a real tenant. discovery/entra_shadow_it.py, its own connector (source entra_shadow_it, capability discovery.entra), usually on the same Microsoft connection as entra. It finds third-party apps people sign in to or consented to that nobody registered, and shows them as discovery candidates with usage counts. Separate from entra so an organization without Entra ID P1 or P2, or without these consents, leaves it off. Learn check: the Phase 11 research package (researcher, with Learn citations, 2026-11-09), summarized below.

GET https://graph.microsoft.com/v1.0/organization?$select=id                                   the tenant's own ID
GET https://graph.microsoft.com/v1.0/servicePrincipals?$select=id,appId,displayName,appOwnerOrganizationId,publisherName,verifiedPublisher,servicePrincipalType,homepage,accountEnabled,description&$top=999
GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants
GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=createdDateTime ge {start} and createdDateTime le {end}&$top=1000
    (every list follows @odata.nextLink, only on graph.microsoft.com; the sign-in read only with the scope's sign_ins on)

App role ID of AuditLog.Read.All: b0afded3-3588-46d8-8b3d-9842eff778da (Learn permissions reference, 2026-11-09). Directory.Read.All’s is left out until confirmed on Learn (DECISIONS 2026-11-06 Phase 6 (h)).

• What a run reads. From the connector’s cursor (ShadowItState.read_until: every sign-in created before it was counted) to 15 minutes ago, never further back than the rolling window: exactly 30 UTC days (today and the 29 days before, from midnight UTC), which is within Entra’s 30-day retention; a first run reads all of it. Windows start at the size the last run ended with (ShadowItState.window_minutes, 3 days at first). A throttled first page (429, 503) is waited out (Retry-After, else exponential backoff, within the run’s throttling budget) and the same window read again. A window is halved (down to an hour) and read again when any page answers 504 or when it has more than 2,000 pages of 1,000; when a window can’t finish within the run’s time (30 minutes of reading, checked before every page against the time a page has taken, or the run’s 40-minute deadline), the run stops there and the halved size is stored for the next run. After a complete window the size doubles back towards 3 days, but only when a window twice as long (about twice its pages, at the time a page has taken so far) fits in the run’s time left. Later pages are retried as every Graph read is (core/graph.Budget). Reads are spaced 2.2 s apart on a real tenant (5 per 10 s per app, with a margin for the entra connector on the same registration). A window counts only when read completely; the cursor moves to the end of the last complete one, so a later run never counts a sign-in twice. A run that stops after at least one complete window (its time, a throttle it can’t wait out, a 500 or 502) keeps what it counted, says so in its notes, and the next run continues; a run that ran out of time before any window completed succeeds with a note and a smaller window for the next run, so a large tenant advances run by run; a run whose first window fails otherwise fails and stores nothing. v1.0 returns interactive and federated sign-ins only, which is what is counted; failed sign-ins (status.errorCode not 0) are counted apart and aren’t use. The 15-minute lag behind now is an assumption about log latency, not from Learn.
• What counts as third-party. The app’s service principal appOwnerOrganizationId isn’t the tenant’s own ID and isn’t in the scope’s first_party_tenants (the entra source’s list and defaults). An app with no service principal in the tenant (typically a Microsoft app) is skipped as “no enterprise app”, the tenant’s own apps as “published by this tenant”, managed identities and legacy principals as “not an application”. Consent: consentType AllPrincipals is admin consent (principalId null), Principal one user’s; clientId is the client’s service principal object ID, mapped to its application ID through the service principal list; scope is space-separated.
• High-risk scopes (risky_scopes), compared case-insensitively: offline_access, Mail.Read, Mail.ReadWrite, Mail.Send and their .Shared forms, MailboxSettings.ReadWrite, Files.Read.All, Files.ReadWrite.All, Sites.Read.All, Sites.ReadWrite.All, Sites.Manage.All, Sites.FullControl.All, Notes.ReadWrite.All, Calendars.ReadWrite, Contacts.ReadWrite, User.ReadWrite.All, Group.ReadWrite.All, Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All, full_access_as_user, EWS.AccessAsUser.All, and anything starting Directory. or RoleManagement..
• Privacy: what is stored. Per connector, the cursor and a random 32-byte key (ShadowItState.sketch_key; never in a response, log, audit event or organization export). Per third-party app per UTC day: the successful sign-in count, the distinct users that day, and a HyperLogLog sketch (4,096 one-byte registers, zlib-packed) of HMAC-SHA256(key, user object ID), from which distinct users over several days are counted (about 1.6% standard error, exact in practice for small numbers); days older than the rolling 30 are deleted by the next run. Per app, the overview summary: users and sign-ins over 30 days, last sign-in time, consent type, how many people consented, the scopes. Never stored: sign-in rows or their IDs, user IDs, names, addresses, IP addresses, locations, devices, correlation IDs, or who consented. User IDs are hashed into the sketch in memory and dropped. A sketch can’t list its users; with the key, someone could test whether one known user is likely among an app’s users on a day, which is why the key never leaves the database.
• Apps the catalog has (a live application record with the app’s Entra application ID, or an observation of an entra connector) are not candidates: skipped as “already in the catalog”, and kept in the overview with their usage. Nothing writes to Entra or to a curated record.
• Inactive apps aren’t gone. An app this connector observed whose enterprise app is still in the tenant but which has had no sign-in in the rolling window and has no consent grant is skipped as “inactive” (with sign_ins off, “not read”): its candidate is out of scope, never “no longer seen”, so a record linked to it isn’t flagged missing. An app whose enterprise app was deleted from the tenant becomes “no longer seen” at the next run, whatever its recent usage and with or without the sign-in logs, so a record linked to it shows as missing. A dismissed candidate comes back only when its risk rises: a consent type more permissive, or a high-risk scope, than it ever had; usage, a lost scope or a reduced consent never bring it back, and usage changes never count as a change of the candidate.
• Errors. 403 Authorization_RequestDenied names the permission (AuditLog.Read.All for the sign-in logs, Directory.Read.All for the rest). The license refusal reads “Microsoft Graph refused to read the sign-in logs (403 Authentication_RequestFromNonPremiumTenantOrB2CTenant): reading them needs a Microsoft Entra ID P1 or P2 license in the tenant, and this tenant has none. Add one, or turn off Read sign-in logs in this connector’s scope to find shadow IT from consent grants only.” Either way the run fails and stores nothing.
• The simulated tenant (discovery/entra_simulator.py) answers these reads as Learn documents them: third-party apps nobody registered, a fixed sign-in schedule with failures and fractional timestamps, the window filter (an unfiltered read is refused), paging, 429 with Retry-After through simulated_throttle, the 30-day retention, and a tenant without P1 (simulated_no_premium).

Discovery source: entra_coverage

Status: built (Phase 11, item 3), simulated tenant only; nothing has contacted a real tenant. discovery/entra_coverage.py, its own connector (source entra_coverage, capability discovery.entra), usually on the same Microsoft connection as entra. For every catalog application linked to an Entra app (its entra_app_id, or a linked entra or entra_shadow_it candidate) it records whether it is behind single sign-on, whether SCIM provisioning is on, and whether conditional access requires MFA, for all users or only some (discovery_appcoverage, docs/DATA_MODEL.md). Separate from entra so an organization without Entra ID P1, or without these consents, leaves it off. It writes nothing to Entra and never writes a catalog record. Learn check: the Phase 11 research package (researcher, with Learn citations, 2026-11-09), summarized below.

GET https://graph.microsoft.com/v1.0/servicePrincipals?$select=id,appId,displayName,appOwnerOrganizationId,servicePrincipalType,preferredSingleSignOnMode,preferredTokenSigningKeyThumbprint,samlSingleSignOnSettings&$top=999
GET https://graph.microsoft.com/v1.0/servicePrincipals/{id}/synchronization/jobs          per linked app, at most 100 a run
GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies                 once a run
    (every list follows @odata.nextLink, only on graph.microsoft.com)

App role IDs (Learn permissions reference, 2026-11-09): Synchronization.Read.All 5ba43d2f-fa88-4db2-bd1c-a67c5f0fb1ce, Policy.Read.All 246dd0d5-5bd0-4def-940b-0421030a5b68.

• Single sign-on (sso): saml, oidc, password (Entra’s password-based SSO: the app is behind My Apps but not federated; it counts as SSO for the record’s sso_enabled, as Entra counts it), none (notSupported) or unknown. A null mode is unknown, never “no SSO”, unless the app has a SAML token signing certificate or SAML settings, which make it saml.
• Provisioning (scim): on when a job’s schedule.state is Active and its status.code is neither Paused nor Quarantine; off with no job (an empty list, or a 404), a paused or quarantined job, or a schedule that isn’t active.
• Conditional access (mfa), per app (entra_coverage.evaluate_policy): only enabled policies enforce (report-only ones are listed as report_only, disabled ones ignored). The app must be in conditions.applications.includeApplications (its app ID or All) and not in excludeApplications; Office365 and MicrosoftAdminPortals may cover a Microsoft-published app and never a third-party one, so including or excluding either makes a Microsoft app unknown and leaves a third-party app as the rest of the policy says; an applicationFilter can’t be evaluated, so a policy whose coverage of the app depends on one is unknown. conditions.users.includeUsers All is all users (exclusions such as break-glass accounts are counted and shown, not judged); roles (an admin-only policy), groups, guests or listed people are some users, as is a policy limited to some locations, device platforms, client app types, devices (a device filter, or the legacy includeDevices / excludeDevices), sign-in, user, service principal or insider risk levels, authentication flows (device code flow, authentication transfer), workload identities, or any condition Softwarden doesn’t know (an unknown shape can never give “all users”); users None covers nobody. An enabled policy whose grant is block is effect blocked; one that blocks all users with no exclusion and no narrowing makes the app blocked, not a missing MFA policy; a block with exclusions (“everyone except Sales”, or break-glass accounts) decides nothing, and the other policies say what the excluded people get. MFA is required when grantControls.builtInControls contains mfa or authenticationStrength.requirementsSatisfied is mfa, unless the operator is OR with another control beside it (MFA optional; Graph writes OR even for a single control, which still requires MFA). The app is blocked if one policy blocks everyone, else all_users if one requires MFA of everyone, else some_users, else unknown if a filter or group decides it, else none.
• License and errors. A tenant without P1 (the code isn’t on Learn for this endpoint; Softwarden expects 403 Authentication_RequestFromNonPremiumTenantOrB2CTenant as for the sign-in logs) or without Policy.Read.All (any other 403) doesn’t fail the run: SSO and provisioning are reported, MFA is “unknown” with the reason (“needs Microsoft Entra ID P1”), and the run’s notes say so. The access check marks the license as a warning (missing_licence), not a failure. A refused provisioning read (Synchronization.Read.All missing) stops the provisioning reads for that run (provisioning unknown, with a note); a 404 is “no provisioning job”. Transient failures keep the last answers: a conditional access read throttled past its retries, answering a 5xx, or unreachable keeps every app’s last mfa, detail and policies; a provisioning read answering a 5xx keeps that app’s last answer, and throttling past the run’s budget or an unreachable Graph stops the provisioning reads and keeps the rest’s last answers. An answer is kept only for the same service principal (a tenant change or a re-created app is another one) and for at most 7 days after it was read (mfa_checked_at, scim_checked_at); older, it becomes unknown saying since when. Apps waiting their turn past the provisioning cap keep their answer whatever its age. The run notes what was carried over; only a 401 or 403, or the scope turned off, resets them to unknown. The access check names both causes (the permission or the P1 license) for any 403 on conditional access other than the license code. Security defaults (MFA without conditional access, in tenants without P1) aren’t read (GET /policies/identitySecurityDefaultsEnforcementPolicy not researched yet).
• Empty-listing guard (this source only). If the service principal listing comes back empty while the connector has coverage from earlier runs, the run fails with “Nothing was changed” rather than deleting every row.
• The simulated tenant (discovery/entra_simulator.py) has a single sign-on mode per app (null included), provisioning jobs in every state, conditional access policies of every shape above, a tenant without P1 (simulated_no_premium) and a 429 without Retry-After (simulated_throttle with retry_after null).

Discovery source: entra_licence_usage

Status: built (Phase 11, item 10, license waste), simulated tenant only; nothing has contacted a real tenant. discovery/entra_licence_usage.py, its own connector (source entra_licence_usage, capability discovery.entra), usually on the same Microsoft connection as entra and entra_licenses. It stores which licenses each licensed user holds and the date of their last successful sign-in, for the license waste report (discovery/licence_waste.py, GET /api/v1/reports/licence-waste). It is the first source that reads per-user data, so it is separate from entra_licenses (seat counts, LicenseAssignment.Read.All): an organization that only wants seat counts never grants these consents. Learn check: the Phase 11 research package (researcher, with Learn citations, 2026-11-09).

Both permissions are tenant-wide admin consents. User.Read.All lets the app read every user’s full profile in the tenant, and AuditLog.Read.All every audit and sign-in log. A Privileged Role Administrator (or Global Administrator) must grant them in the app registration before a live run; Softwarden never asks for them by itself, and this repository hasn’t granted them on any tenant. Grant only User.Read.All to count licenses without sign-in activity.

GET https://graph.microsoft.com/v1.0/users?$select=id,accountEnabled,assignedLicenses,licenseAssignmentStates,userType,createdDateTime,mail,userPrincipalName,signInActivity&$top=500
GET https://graph.microsoft.com/v1.0/users?$select=id,accountEnabled,assignedLicenses,licenseAssignmentStates,userType,createdDateTime,mail,userPrincipalName&$top=999
    (the second only when the first is refused with 403, runs past 25 minutes (it is paced at ten pages a minute),
     or the scope's sign_in_activity is off; both follow @odata.nextLink, only on graph.microsoft.com)

App role IDs (Learn permissions reference, 2026-11-09): User.Read.All df021288-bdef-4463-88db-98f22de89214, AuditLog.Read.All b0afded3-3588-46d8-8b3d-9842eff778da (discovery/graph_source.USER_READ_ALL, AUDIT_LOG_SIGN_IN_ACTIVITY).

• Without P1 or the AuditLog consent the run degrades instead of failing. A 403 on the read with signInActivity (the license code, or Authorization_RequestDenied) makes the run read the users again without it. Licenses are counted, every last sign-in is “unknown (needs Entra ID P1 / AuditLog.Read.All)”, nothing is counted as inactive, and the run’s note names the cause. The access check shows the license as a warning (missing_licence) and a missing AuditLog.Read.All as optional. Without User.Read.All the run fails and names it. A Graph listing of users without assignedLicenses is refused rather than read as “nobody is licensed”.

• Privacy: what is stored (discovery_licenseduser, docs/DATA_MODEL.md). Only licensed users are stored, one row each, holding:

  • an HMAC-SHA256 of the object ID keyed by the installation’s secret key and the connector (never the object ID itself);
  • the SKU IDs;
  • whether the account is enabled, whether it is a guest (userType Guest, or #EXT# in the user principal name), and whether it is a service account (the scope’s user principal name prefixes or object IDs);
  • the date (not the time) of the last successful sign-in and of creation, and whether any sign-in was recorded;
  • the Person here it is linked to.

  Never stored: a name, an email address, a user principal name, the object ID, an IP address, a location or a device. Mail and user principal name are held in memory during the run only to link a member to a Person (by email, the user principal name before mail; guests are linked by identity only, and an ambiguous match is left unlinked) and to match service-account prefixes. The object ID is used only to link through a Person’s Entra sign-in identity of this tenant and to hash.

  Every run rewrites the connector’s rows, so the next run deletes any user who is no longer licensed or no longer in the tenant, and deleting the connector deletes them all. The rows are left out of organization exports and tenant backups (personal data the next run reads again), and the organization purge removes them.

• Who sees what. The report, its CSV, and the pool and contract blocks are counts and money, open to any role. The per-SKU drill-down of users is Admin-only. It shows a linked Person’s name, otherwise “Unlinked user” and the first 8 characters of the keyed hash. Its CSV is audited, and both are refused while platform staff impersonate. The offboarding footprint lists the SKUs a Person holds, without sign-in dates.

• Group-based licenses. assignedLicenses includes licenses inherited from groups (Learn, user resource). A seat held only through a group can only be reclaimed by changing the user’s group membership, not by removing the license from the user. The run therefore also selects licenseAssignmentStates (same User.Read.All) and keeps which SKUs a user holds only through groups (assignedByGroup on every state of the SKU). The drill-down flags them as group_assigned.

• One connector per tenant. A second entra_licence_usage connector on the same connection or tenant ID is refused, since it would count every licensed user twice. Each run also reads the tid claim of its access token (the token is read, not verified; Softwarden reads nothing else from it) and stores a keyed hash of the tenant in its counts (tenant_key). A run is refused, changing nothing, when another enabled license usage connector’s last successful run read the same tenant. That catches a tenant named by domain on one connection and by GUID on another, or changed later in Connections.

• Empty-listing guard. If the user listing comes back empty, or with no licensed user, while the connector has rows from earlier runs, the run fails with “Nothing was changed” rather than deleting them.

• The simulated tenant (discovery/entra_simulator.py) answers GET /users as Learn documents it:

  • only the selected properties, and the $top limits (999, or 500 with signInActivity);
  • every combination of enabled or disabled, member or guest, no, one or several licenses, and a sign-in that is recent, old, never or failed only;
  • AuditLog.Read.All and P1 required for signInActivity (simulated_no_premium);
  • paging (simulated_user_page) and 429 with Retry-After (simulated_throttle).

Discovery source: azure

Status: built (Phase 6 Sources B, enterprise capability discovery.azure), run against the simulated tenant only; live acceptance needs an Azure role assignment the owner hasn’t approved yet. discovery/azure.py on discovery/graph_source.py. Client credentials from the connector’s tested MicrosoftConnection, scope https://management.azure.com/.default; the token is sent only to management.azure.com (every request and every nextLink is checked before the token is attached). No Graph permission. Learn check 2026-11-06: docs/research/phase6-discovery-microsoft-learn.md §3.

GET https://management.azure.com/subscriptions?api-version=2022-12-01                                    no subscription chosen: every one the app has a role on
GET https://management.azure.com/subscriptions/{id}?api-version=2022-12-01                               each chosen subscription
GET https://management.azure.com/subscriptions/{id}/providers/Microsoft.Logic/workflows?api-version=2019-05-01
GET https://management.azure.com/subscriptions/{id}/providers/Microsoft.Web/sites?api-version=2024-04-01
GET https://management.azure.com/subscriptions/{id}/providers/Microsoft.Automation/automationAccounts?api-version=2024-10-23
GET https://management.azure.com{automation account id}/runbooks?api-version=2024-10-23
    (each list follows nextLink, only on management.azure.com; a full listing every run)

az role assignment create --assignee <app client id> --role Reader --scope /subscriptions/<subscription id>
# or once for a management group: --scope /providers/Microsoft.Management/managementGroups/<group id>

• Per-type lists, not the generic Resources list (DECISIONS 2026-11-06 Phase 6 (f)): the generic list returns no properties (IT1’s descriptions came out empty). Resource Graph isn’t used.
• Subscriptions. With none chosen, every subscription Subscriptions - List returns is read, so Reader on a management group covers all the subscriptions under it (no management-group API call is made). Only Enabled, Warned and PastDue subscriptions are read; others are noted and their candidates keep their state. A chosen subscription the app can’t read is noted (its candidates keep their state); Subscriptions - Get answers 404 SubscriptionNotFound for a subscription the app has no role on (research §3), reported as “no Reader on this subscription, or the ID is wrong”. Each resource type is its own scope: one list refused leaves that type’s candidates as they were while the others update. A resource provider the subscription never registered (409 MissingSubscriptionRegistration) is an empty list, noted (and ok in the access check). The run fails only when nothing could be read.
• Web apps by kind. workflowapp is read as a Standard Logic App (Learn shows only the APP_KIND setting workflowApp: to confirm live), functionapp as a Function App (Learn: functionapp, functionapp,linux), app, api or no kind as an App Service (kept only with scope include_app_services). Any other kind (Flex Consumption is to confirm live) is skipped as “not recognized” and the run notes the kind strings.
• Errors. A missing role is 403 AuthorizationFailed; the run and the access check name the action and scope ARM gave (read with a strict pattern; nothing else of Microsoft’s message is kept) and the fix: “Assign the Azure role Reader to the connection’s app on subscription X”. Role changes can take minutes to reach tokens. 429/503 are retried after Retry-After as for Graph.
• Kept: name, resource ID, type, subscription, resource group, location, tags (50 at most), state, kind, runbook type and description, managed identity type. Never kept: a Logic App’s definition or a site’s configuration (either can hold secrets).

Discovery source: powerplatform

Status: built (Phase 6 Sources B, enterprise capability discovery.powerplatform), simulated tenant only; live acceptance needs Dataverse application users the owner hasn’t approved yet. discovery/powerplatform.py. Power Platform doesn’t use Entra API permissions for service principals. Learn check 2026-11-06: research §4.

Least privilege (default): environments selected by URL (scope environment_urls, https://<name>.crm[N].dynamics.com; anything else is refused when saved). Each environment gets its own token, scope https://<env host>/.default, sent only to that host.

GET {env}/api/data/v9.2/bots?$select=botid,name,schemaname,statecode,statuscode,authenticationmode,accesscontrolpolicy,language,publishedon,componentstate,_ownerid_value
    Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue",odata.maxpagesize=500
GET {env}/api/data/v9.2/workflows?$select=workflowid,name,statecode,description,_ownerid_value&$filter=category eq 5     only with include_cloud_flows
    (each follows @odata.nextLink, only on that environment's host)

• Set-up: register the app in Entra, then Power Platform admin center > Environment > Settings > Users + permissions > Application users > New app user, with the business unit and the security role above (Learn, verified). Avoid System Administrator.
• Errors. Dataverse answers a caller that isn’t a user of the environment with 401 and a missing privilege with 403 (types PrivilegeDenied, AccessDenied, …; codes are often empty or hex): both are “needs an application user with read on Agent (bot) rows”, naming the privilege when Dataverse’s message names one (prv..., read with a strict pattern; the message wording is not verified). A Dataverse host the tenant doesn’t know fails sign-in with AADSTS500011 (not verified), shown as “not found: check the address”.
• An environment that can’t be read (refused, no token, unreachable, throttled out) is noted and its candidates keep their state; only the run’s 40-minute limit stops the whole run. Flows that can’t be read are a note and the agents are still read. Rows without an ID are skipped and counted (“no ID”). Agents in component state Deleted (2, 3) are skipped. A flow’s clientdata (its definition) is never asked for.
• RetrieveCurrentOrganization (IT1) isn’t called: an environment chosen by URL is named by its host, and its environment ID is known only through All environments.

All environments (opt-in, scope all_environments): the Power Platform admin API (BAP).

GET https://api.bap.microsoft.com/providers/Microsoft.BusinessAppPlatform/scopes/admin/environments?api-version=2020-10-01     token for https://service.powerapps.com/

• Microsoft treats such an app like a user with the Power Platform Administrator role, and granular roles can’t limit it. The SPA shows this warning; selected-by-URL remains the default.
• The newer Power Platform API (api.powerplatform.com, EnvironmentManagement.Environments.Read) wasn’t used: its service-principal roles couldn’t be verified (DECISIONS 2026-11-06 Phase 6 (g)). Open.
• An environment’s instanceUrl is used only when it is a Dataverse host; any other is noted and never sent a token. Environments without a Dataverse database are noted; if no environment is left to read, the run fails with those notes. If the list is refused (401 after a fresh token, or 403: not registered) the run fails (an environment it would have read could otherwise look gone); the access check names “Power Platform management app”.

Discovery source: halo

Status: built (Phase 6 Sources B, enterprise capability discovery.halo), against the synthetic Halo only. Not Microsoft; listed so every outbound credential is in one place. discovery/halo.py with the connector’s HaloConnection (encrypted secret; core/halo.py). The API conventions are IT1’s from Halo’s integration guides: confirm against the instance’s own {base}/apidoc during live acceptance.

POST {base}/auth/token                                   client credentials, scope default "read:assets"
GET  {base}/api/Asset?paginate=true&page_size=100&page_no=N     {"record_count", "assets": [...]}, until a short page or record_count

• base_url must be https, with no user name, password, query or fragment (core/outbound.check_service_url). Private networks are allowed (an on-premises Halo) unless the installation sets SOFTWARDEN_ALLOW_PRIVATE_SERVICE_HOSTS=false (a hosted, multi-organization install), which refuses RFC 1918, ULA and carrier-grade NAT too; loopback, link-local (169.254.169.254 included), cloud metadata (fd00:ec2::254, 100.100.100.200), unspecified, multicast and reserved addresses are always refused, for a literal on save and for every address the name resolves to when connecting (the token POST and every asset GET), which goes to the checked address with no redirects and a deadline (core/outbound.request(..., private_ok=True)). IT1 urlsafety.py had the same rule. The token is sent only to the connection’s own host and port.
• A refused read (403) is “missing permission: read:assets”; 401 is the token not being accepted. 429 is retried after Retry-After. Assets without an ID are skipped and counted; paging stops (with a note) if Halo answers a page with the same first asset as the page before.
• Kept: the asset ID, key field (else inventory number), asset type, inventory number, client, site, inactive. Inactive assets are skipped by default; scope asset_types limits the types.
• The host halo.simulated.invalid selects the synthetic Halo (discovery/halo_simulator.py, tokens from core/halo.SimulatedTransport): nothing leaves the machine.

Ticket connections: Jira, ServiceNow, Halo

ServiceNow and Halo are preview features in 1.0.0: no request is made to either unless the installation sets SOFTWARDEN_PREVIEW_FEATURES (docs/CAPABILITIES.md). The same applies to Okta and Google Workspace below.

Status: built (Phase 11 ticket links, capability ticket_links), against the synthetic systems only. Not Microsoft; no Microsoft permission is involved. Listed so every outbound credential is in one place. tickets/clients.py with the organization’s TicketConnection (Jira and ServiceNow keep an encrypted secret; Halo uses the Phase 6 HaloConnection).

Jira Cloud (REST v3, basic auth: account email + API token)
GET  {base}/rest/api/3/issue/{key}?fields=status,summary       status name, statusCategory.key, summary
GET  {base}/rest/api/3/myself                                    the connection test
POST {base}/rest/api/3/issue                                     create (opt-in): project key, issue type, summary, ADF description
ServiceNow (Table API, basic auth)
GET  {base}/api/now/table/{table}?sysparm_query=number={key}&sysparm_fields=number,state,short_description&sysparm_display_value=all&sysparm_limit=1
GET  {base}/api/now/table/task?sysparm_limit=1&sysparm_fields=number      the connection test
POST {base}/api/now/table/{table}                                create (opt-in): short_description, description
HaloITSM (client credentials through the Halo connection)
POST {base}/auth/token                                           scope from the Halo connection (must include read:tickets)
GET  {base}/api/Tickets/{id}                                     summary, status_id (status_name when sent)
POST {base}/api/Tickets                                          create (opt-in): [{summary, details, tickettype_id}]

• Where checked (2026-11-09). Jira: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/ (Get issue GET /rest/api/3/issue/{issueIdOrKey} with fields a comma-separated list; Create issue POST /rest/api/3/issue) and https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/ (basic auth needs an API token; passwords are deprecated), fetched and read. The status category keys new, indeterminate and done are Jira’s long-standing keys (/rest/api/3/statuscategory); the reference page’s examples use placeholder keys, so they weren’t confirmable there. ServiceNow: https://www.servicenow.com/docs/r/api-reference/rest-apis/c_TableAPI.html (Table API) is rendered by script and couldn’t be read from here; sysparm_query, sysparm_fields, sysparm_display_value (true, false, all) and sysparm_limit are the Table API’s documented parameters, to confirm during live acceptance, as are the state labels. Halo: no public reference could be fetched (the instance’s own {base}/apidoc is the reference, as for the Phase 6 source); GET /api/Tickets/{id}, POST /api/Tickets and the status IDs (1 New, 9 Closed) are to confirm during live acceptance.
• Every request goes through core/outbound under the service rule, like the Halo source: https only; no user name or password in the URL; loopback, link-local (169.254.169.254 included), cloud metadata, unspecified, multicast and reserved addresses always refused, and private networks too when SOFTWARDEN_ALLOW_PRIVATE_SERVICE_HOSTS=false, for a literal on save and for every address the name resolves to when connecting, which goes to the checked address with no redirects, a 10 s socket timeout and a 20 s deadline. The address is always the connection’s own base URL: a link’s stored URL is never fetched, and a link on another site isn’t read with the connection’s credentials.
• Errors are stored in Softwarden’s words only (status_error, the test’s detail): never the server’s text, the Authorization header, a token or the secret. The credential object’s repr leaves the secret out, and job payloads carry no secret (the job reads the connection row when it runs).
• The hourly refresh runs in the worker’s long lane with a 180 s budget per run, one Halo token per run, and stops reading a system at its first timeout, missing answer, busy answer, refused access, refused credentials or refused address, so a slow system can’t hold up the worker or another organization’s reads.
• Creating tickets is off by default per connection (create_enabled), needs the connection tested at its current revision, and every attempt is audited (ticket_link.ticket_created, ticket_link.create_failed). Only the title and description are sent.
• The hosts jira.simulated.invalid, servicenow.simulated.invalid and halo.simulated.invalid select the synthetic systems (tickets/simulator.py): nothing leaves the machine.

Discovery source: okta

Status: built (Phase 11, enterprise capability discovery.okta), against the synthetic Okta only. No real Okta org has been contacted; live acceptance is the owner’s. Not Microsoft; listed so every outbound credential is in one place. discovery/okta.py with the connector’s OktaConnection (core/okta.py; the private key is Fernet-encrypted and write-only). Checked on 2026-11-10 against:

• Implement OAuth for Okta with a service app: client credentials with private_key_jwt (the only client authentication for service apps that get Okta-scoped tokens), assertion iss = sub = client ID, aud = https://{okta domain}/oauth2/v1/token, at most an hour; token lifetime one hour; each service app needs an admin role, and a scope works only within it.
• The Okta Management API OpenAPI document (okta/okta-management-openapi-spec, dist/current/management-minimal.yaml, version 2026.44.0): GET /api/v1/apps (listApplications; limit at most 200, includeNonDeleted, after cursor; security okta.apps.read) and GET /api/v1/apps/{appId}/users (listApplicationUsers; limit at most 500; security okta.apps.read). Errors {"errorCode": "E0000006", ...} for 403, E0000047 for 429.
• Pagination: the link header’s rel=“next” URL, followed as an opaque value.
• Rate limit best practices: X-Rate-Limit-Limit, X-Rate-Limit-Remaining, X-Rate-Limit-Reset (UTC epoch seconds); 429 when exceeded.
• DPoP: opt-in per app (“Require Demonstrating Proof of Possession (DPoP) header in token requests”). Softwarden sends no DPoP proof; the test tells the Admin to leave it off.

POST https://{okta domain}/oauth2/v1/token          grant_type=client_credentials, scope=okta.apps.read,
                                                     client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer,
                                                     client_assertion=<JWT signed with the service app's private key>
GET  https://{okta domain}/api/v1/apps?limit=200&includeNonDeleted=true       then the link header's rel="next"
GET  https://{okta domain}/api/v1/apps/{appId}/users?limit=500                per kept app, while assignment_counts is on

• Why a service app, not an SSWS API token. An SSWS token carries every permission of the administrator who created it, isn’t scoped, and is a bearer secret valid until revoked. The service app is scoped to okta.apps.read, bounded by a read-only admin role, and its private key never leaves Softwarden: only a five-minute signed assertion is sent. The key is a PEM private key (PKCS#8 or PKCS#1) or a private JWK, RSA of 2048 bits or more (RS256) or EC P-256 (ES256); key_id is its kid when the app has several keys (a JWK’s own kid is used otherwise).
• The address. https://{org}.okta.com, .oktapreview.com, .okta-emea.com (one label, never the -admin console host or the bare suffix) or a custom domain; https on 443, no path, query, user name or IP address. Every call goes through core/outbound’s public rule (outbound.PublicTransport): the name is resolved once, refused unless every address is public (a custom domain resolving to loopback, RFC 1918, link-local or a metadata address is refused before anything is sent), and the request goes to the checked address with no redirects and a deadline. The token goes only to that host on 443, also for next-page links.
• Rate limits. The limit is the org’s, shared with every other integration, so once X-Rate-Limit-Remaining falls below 10 % of X-Rate-Limit-Limit (or reaches 0 without a limit header) the next request waits until X-Rate-Limit-Reset, leaving the rest to the others. A 429 waits Retry-After if given, else until the reset, within the run’s waiting budget (core/graph.RUN_BUDGET); a wait over two minutes stops the run (the next run tries again).
• Errors. Token: invalid_client / unauthorized_client = wrong client ID or key; invalid_scope = the scope isn’t granted; invalid_dpop_proof = DPoP required. Reads: 403 E0000006 = the admin role can’t read (names Read-only Administrator); 401 re-signs in once. A refused user count is a note, never a failed run.
• Kept: the app’s ID, label, key (name), sign-on mode, status, whether it has provisioning features, created and last-updated times, and the assigned-user count (a number only, never a user). Okta apps have no owners in the API. Filters: inactive apps and Okta’s own apps (saasure, okta_enduser, okta_browser_plugin) skipped by default, bookmark apps optional, name exclusions.
• Empty-listing guard. An empty application list while the connector has live observations fails the run with “Nothing was changed”. If every application really was deleted, an Admin runs the connector once with “accept empty listing” (see the entra section).
• The host okta.simulated.invalid selects the synthetic Okta (discovery/okta_simulator.py, tokens from core/okta.SimulatedTokens): nothing leaves the machine.

Discovery source: google_workspace

Status: built (Phase 11, enterprise capability discovery.google), against the synthetic Workspace only. No real Google Workspace has been contacted; live acceptance is the owner’s. Not Microsoft. discovery/google_workspace.py with the connector’s GoogleWorkspaceConnection (core/google_workspace.py). Checked on 2026-11-10 against:

• Using OAuth 2.0 for server to server applications: POST https://oauth2.googleapis.com/token with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer and an RS256 assertion (kid the key ID; claims iss the service account, sub the user to act as, scope, aud the token URL, exp at most an hour after iat); errors unauthorized_client (client not authorized under domain-wide delegation, or authorized by email instead of the numeric client ID), access_denied (a scope not authorized), invalid_grant (unknown sub, deleted or wrong key, clock skew).
• Reports API: activities.list: GET https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/token, eventName, startTime, endTime, maxResults (default and maximum 1000), pageToken / nextPageToken; data goes back 180 days; scope https://www.googleapis.com/auth/admin.reports.audit.readonly.
• OAuth Token Audit Activity Events: the authorize event (“A user authorized access to an application for their data”) with app_name, client_id, client_type and scope.
• Reports API limits and quotas: 2,400 queries per minute per user per project; activities.list also 250 filter queries per minute (eventName makes it one); quota errors are 503, retried with exponential backoff (Google’s example starts at 5 seconds).
• Reports API scopes and Control API access with domain-wide delegation (super admin privileges required; authorize the service account’s client ID with the scopes).

POST https://oauth2.googleapis.com/token            grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, assertion=<JWT>
GET  https://admin.googleapis.com/admin/reports/v1/activity/users/all/applications/token
     ?eventName=authorize&startTime={now - days}&endTime={now}&maxResults=1000[&pageToken=...]

• Domain-wide delegation is a tenant-wide grant and an owner action. It lets the service account act as any user in the Workspace for the scopes listed, so only a super administrator can make it, and Softwarden never makes it. Authorize exactly one scope, https://www.googleapis.com/auth/admin.reports.audit.readonly, for the service account’s numeric client ID (shown on the connection), under Security, Access and data control, API controls, Domain-wide delegation. It can take from minutes to a day to apply. Use a service account made for Softwarden only.
• Why the token audit log. It is the least-privileged way to see third-party apps: one read-only scope and one paged list for the whole domain. The Directory API’s per-user tokens.list would need admin.directory.user.security (which can also revoke tokens) and a call per user. admin.directory.user.readonly isn’t needed.
• The key. The service account key file (JSON) is pasted once; Softwarden keeps only its private key and key ID (Fernet, write-only, never returned, logged or exported) and shows its client_email and client_id. The file’s token_uri is ignored: tokens are only asked from oauth2.googleapis.com. Calls go through core/outbound’s public rule; the token goes only to admin.googleapis.com.
• Privacy. Only app-level aggregates are stored: the app’s name, client ID and type, how many distinct people authorized it in the window, how many authorizations, when the last one was, the scopes granted and the high-risk ones. No event, email, profile ID or IP address is stored, logged or kept past the run: distinct people are counted in memory with HMAC-SHA256 under a key made for the run and discarded with it, and the window is re-read every run, so no sketch or per-person state is kept.
• Window and scope. days (30 by default, 1 to 180), min_users (1 by default), name exclusions. An app nobody authorized in the window is out of scope (“no authorization in the reporting window”), never “no longer seen”: its grants may still be live. High-risk scopes (Softwarden’s list): full mail (https://mail.google.com/, gmail.* except gmail.labels), full Drive (drive, drive.readonly), admin.* and cloud-platform; a dismissed candidate comes back on a new one.
• Errors. Token errors as above, with the advice naming the client ID and the scope. Reads: 403 = the administrator lacks the Reports privilege; 401 re-signs in once; 503 and 429 back off.
• No empty-listing guard. authorize fires only when someone consents, so a window with no authorization at all is normal in a small tenant. Such a run succeeds with the note “No authorization in the last N days: nothing was changed” and every observation keeps its state (nothing moves out of scope or goes).
• An administrator address in google.simulated.invalid selects the synthetic Workspace (discovery/google_workspace_simulator.py, tokens from core/google_workspace.SimulatedTokens): nothing leaves the machine.

Email via Microsoft Graph

Status: built, not yet run against a real tenant. Learn check: 2026-11-05 (this repository). Sending uses Graph sendMail as the application, from one mailbox, with SMTP as the fallback; both are configured per organization in EmailSettings (Administration › Email settings, PATCH /api/v1/notification-settings/email; the Graph client secret and the SMTP password are Fernet-encrypted, write-only). An organization without settings, or with transport installation_default, uses the server’s SOFTWARDEN_SMTP_*. Code: core/graph.py (the client discovery also uses), notify/channels.py, notify/deliveries.py; tests use core/graph_simulator.py (tenant ID simulated).

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token     client credentials, scope https://graph.microsoft.com/.default
POST https://graph.microsoft.com/v1.0/users/{sender mailbox}/sendMail
     {"message": {"subject", "body": {"contentType": "HTML", "content"},
                  "toRecipients": [{"emailAddress": {"address"}}],
                  "internetMessageHeaders": [{"name": "x-softwarden-notification-id", "value": <delivery id>}]},
      "saveToSentItems": false}
     headers: client-request-id: <a GUID per attempt, stored on the delivery>, return-client-request-id: true

• Why not Entra: Entra and Exchange grants are a union, so an Entra Mail.Send consent makes the app able to send as anyone in the tenant, whatever the Exchange scope says. Remove any Entra Mail.Send application permission and its consent. Application Access Policies are replaced by this feature.
• Setup (an Exchange admin with Organization Management, or an Entra Exchange Administrator, in Exchange Online PowerShell):

Connect-ExchangeOnline
# IDs from Entra > Enterprise applications (not App registrations)
New-ServicePrincipal -AppId <app client id> -ObjectId <enterprise app object id> -DisplayName "softwarden-mail"
New-ManagementScope -Name "softwarden sender" -RecipientRestrictionFilter "PrimarySmtpAddress -eq 'softwarden@contoso.com'"
New-ManagementRoleAssignment -App <enterprise app object id> -Role "Application Mail.Send" -CustomResourceScope "softwarden sender"
Test-ServicePrincipalAuthorization -Identity <enterprise app object id> -Resource softwarden@contoso.com    # InScope = True
Test-ServicePrincipalAuthorization -Identity <enterprise app object id> -Resource someone-else@contoso.com # InScope = False

• Exchange caches app permissions for 30 minutes to 2 hours, so a fresh grant can fail a test email for a while. A license-free shared mailbox can be the sender (≤ 50 GB; block sign-in); to verify in a test tenant.
• What Softwarden checks. Test connection only gets a token: Microsoft issues one even when no permission is granted, so it proves the tenant, client ID and secret, not the mailbox scope. Send test email sends a real message to the signed-in Admin’s own address and is what proves the scope (a 403 ErrorAccessDenied names the RBAC role and scope to check).
• Answers. Success is 202 Accepted with an empty body: accepted, not delivered. Errors are {"error": {"code", "message", "innerError" | "innererror"}}, read case-insensitively and matched on error.code. 429 and 503 carry Retry-After.
• Limits and retries. 10,000 requests per 10 minutes and 4 concurrent requests per app and mailbox: Softwarden sends at most 4 at a time per sender mailbox across all workers (PostgreSQL advisory locks) and honors Retry-After (capped at an hour), else backs off 1, 4, 16 minutes, 4 attempts in all. There is no idempotency header. Softwarden dedupes itself: each delivery has a unique key written before the call, and it never retries after an ambiguous failure (a timeout or a dropped connection after the request was written, a 5xx other than 503): the delivery is marked failed with the reason and an Admin can check and resend. Only 429 and 503 (“not accepted”) are retried.
• To verify live on the owner-approved dev tenant: sendMail from a license-free shared mailbox; the Application Mail.Send role id; the PrimarySmtpAddress scope filter.

SMTP fallback

For generic SMTP servers (a relay, a hosted mail service). An organization’s host may be a private relay, but loopback, link-local (cloud metadata) and unspecified addresses are refused, also after DNS resolution and inside IPv6 forms; the server’s own SOFTWARDEN_SMTP_HOST is not restricted. Host, port (default 587 for STARTTLS, 465 for implicit TLS, 25 for none), security, optional user name and password, from address. No Microsoft permission. SMTP AUTH with a password against Exchange Online is on a retirement path (off by default for existing tenants from the end of December 2026; final removal in the second half of 2027: Exchange team blog); for Microsoft 365 use Graph. Development uses Mailpit (compose.dev.yaml, the dev stack’s installation default).

Teams notifications

Status: built, not yet run against a real workflow. Learn check: 2026-11-05 (incoming webhooks, connectors). No Graph permission and no Entra registration.

• Office 365 Connectors were retired in May 2026: Softwarden refuses their addresses (*.webhook.office.com, outlook.office.com). Admin setup: in the channel, ... › Workflows › “Send webhook alerts to a channel” › Save › copy the link, and add a co-owner to the workflow (a workflow belongs to the person who made it). Paste the link into Administration › Teams destinations (POST /api/v1/notification-settings/teams-destinations).
• The link is a bearer secret: stored Fernet-encrypted in TeamsDestination (write-only; only its host is shown), never logged, audited or put in a job argument.
• Payload (notify/render.py):

{"type": "message", "attachments": [{"contentType": "application/vnd.microsoft.card.adaptive", "contentUrl": null,
  "content": {"$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.2",
              "body": [...], "actions": [{"type": "Action.OpenUrl", ...}]}}]}

• Cards: any element except Action.Submit; Markdown, not HTML; the request body stays under 28 KB (long lists end with “and N more”). More than 4 requests per second is throttled: Softwarden spaces posts to one destination and honors 429 with Retry-After.
• Posts go to the address checked at resolution (no second lookup), under a 30 s wall-clock deadline; IPv6 forms that embed or translate IPv4 (NAT64, IPv4-compatible, SIIT, 6to4, Teredo) are refused.
• Not documented, so assumed until checked against a real workflow: the URL host pattern (any https host is accepted; private, loopback and link-local addresses are refused, and checked again at send time after DNS resolution) and the success status (any 2xx counts as accepted).

Generic webhooks (Phase 5 minimal; Phase 7 formalizes)

Not Microsoft; listed so every outbound destination is in one place. WebhookDestination: an https URL (encrypted, write-only; the same SSRF checks as Teams) and a signing secret (encrypted, write-only, 16 characters or more). Each POST carries X-Softwarden-Delivery (the delivery id), X-Softwarden-Event and X-Softwarden-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256 of "<t>." + body under the signing secret>; a receiver should compare in constant time and refuse old timestamps. Body: {"id", "event", "created_at", "sent_at", "data"}.

SCIM and SAML (enterprise)

• SCIM: Entra’s provisioning service calls Softwarden’s SCIM endpoint (ee/scim) with a bearer token Softwarden issues. No Graph permission is requested by Softwarden. Roles map from groups only when the organization opts in. Details: “Provisioning: SCIM (enterprise), what Entra calls on us” below.
• SAML: an Entra enterprise application configured for SAML sign-in (ee/saml, python3-saml). No Graph permission.

Provisioning: SCIM (enterprise), what Entra calls on us

Status: built (Phase 8, ee/scim, capability scim), tested by a pytest replay of the Microsoft SCIM Validator’s sequences and Learn’s documented Entra requests (tests/test_scim.py); not yet run against a real Entra tenant or the hosted validator. Here the direction is reversed: Softwarden requests no permission from Microsoft and calls no Microsoft endpoint. Entra’s provisioning service (an enterprise application with Provisioning Mode Automatic, “non-gallery” or custom app) calls Softwarden.

Sources (Microsoft Learn: the 2026-11-07 research digest, then the researcher’s Learn check of these assumptions the same day, DECISIONS_NEEDED Phase 8 SCIM (g)): Tutorial: develop and plan provisioning for a SCIM endpoint (entra/identity/app-provisioning/use-scim-to-provision-users-and-groups), Known issues and resolutions with SCIM 2.0 protocol compliance (application-provisioning-config-problem-scim-compatibility, the aadOptscim062020 flag) and Tutorial: validate a SCIM endpoint (scim-validator-tutorial).

What the Entra admin enters (Admin > Provisioning in Softwarden gives both, from POST /api/v1/scim/tokens):

• Tenant URL: {SOFTWARDEN_BASE_URL}/scim/v2/<organization slug>.
• Secret Token: the scim_... value shown once when the token is created. Long-lived (up to two years), hashed at rest, revocable; create a second token and revoke the first to rotate.

Auth. Authorization: Bearer scim_... on every request, the discovery documents included. A missing, unknown, revoked or expired token, or a token of another organization than the path’s slug, all get the same 401 (WWW-Authenticate: Bearer). The token is compared in constant time, throttled per token (SOFTWARDEN_SCIM_RATE, default 600 a minute; 429 with Retry-After), and can’t call /api/v1. No cookies or CSRF token are involved. A community organization gets 403.

What Entra calls (all application/scim+json; errors are SCIM errors with status and scimType):

Request bodies over SOFTWARDEN_SCIM_MAX_BODY (1 MiB) get 413. What the provisioned users and groups do to accounts, memberships and roles: API.md “SCIM provisioning”.

Confirmed by Learn: responses are application/scim+json; a group PATCH answers 204 No Content. Learn is silent on, so assumed: the Content-Type Entra sends (any JSON body is accepted); whether Entra sends If-Match (supported, harmless); whether the discovery documents are called with the bearer token (Softwarden requires it); Entra’s request rate (hence SOFTWARDEN_SCIM_RATE); and the default attribute set of a custom app’s mapping (anything unknown is ignored rather than refused, so a mapping Softwarden doesn’t keep can’t break a sync, but Entra may re-send it each cycle; remove the mappings you don’t need). aadOptscim062020 is still not the default, so both PATCH shapes stay supported.

Connection test (Phase 6, built)

POST /api/v1/connections/microsoft/{id}/test and POST /api/v1/connections/halo/{id}/test (Admin) ask for a token with the stored values and nothing else. The test needs no permission beyond the token, and proves none: Microsoft issues a client-credentials token even when no API permission has admin consent, so a passing test proves the tenant, the application (client) ID and the client secret only. Each source’s access check (below) proves its permissions.

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
     grant_type=client_credentials, client_id, client_secret, scope=https://graph.microsoft.com/.default
POST {halo base_url}/auth/token
     grant_type=client_credentials, client_id, client_secret, scope (default "read:assets")

The token endpoint and the client-credentials request were checked on Microsoft Learn on 2026-11-05 (core/graph.py, Email via Microsoft Graph). Global Azure only: national clouds and certificate credentials are not offered (IT1 has neither).

A refused Microsoft token request is classified by the AADSTS code at the start of error_description (core/connections.MICROSOFT_CODES, after IT1 discovery/access.py). The stored result is Softwarden’s own wording plus the code; Microsoft’s message is never kept, shown or logged.

The error-code list is at https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes; confirming the rows above there (and live on the approved dev tenant) is still open. Halo errors are classified by HTTP status and the OAuth error (invalid_client, invalid_scope).

A connection whose sign-in values or secret change gets a new revision; no connector runs on it until it passes the test again (tested_revision == revision, enforced in discovery/engine.run).

Access checks and guided setup

Access checks use the permissions above and nothing more. Built for entra and entra_licenses (Phase 6 Sources A, discovery/access.py), okta and google_workspace (Phase 11, discovery/rest_source.py) and azure, powerplatform and halo (Phase 6 Sources B, one sign-in step per audience, then the reads below; at most 10 subscriptions or environments are probed, the rest are not_checked and a run reports each): POST /api/v1/connectors/{id}/access-check (Admin, audited as connector.access_checked with the permissions missing) signs in with the connector’s connection (no successful connection test needed), then makes one one-item read per permission, outside any transaction, and stores the result on the connector (access_check). A sign-in failure is classified by AADSTS code as in the connection test and skips the reads. A refused read (403, Graph’s Authorization_RequestDenied, “Insufficient privileges to complete the operation.”) is “missing permission” naming the permission; 401 is an authentication problem (after one fresh sign-in). An optional permission not granted is optional_missing; any other failure of an optional read (404, 429, 5xx) is warning; neither fails the check. The agent-identity read is not_used (not called) while the connector’s scope leaves include_agent_identities off. A sign-in failure carries the connection test’s classification (AADSTS code). The source’s capability is checked first (403). The Connection step names the connection only (the result is readable by every role). Throttling waits at most a minute, and a check takes three minutes at most.

The guided setup script (IT1 walkthrough.py) is displayed, never run by Softwarden: an administrator runs it in Azure Cloud Shell. It registers a single-tenant app, adds only the Graph application permissions of the chosen sources, grants admin consent, assigns Reader on listed subscriptions (Azure only) and creates a one-year secret. Power Platform application users are added by hand.

AI assistant: Anthropic (enterprise, off by default)

Status: built (Phase 6, capability assistant), tested against a mocked SDK only. Not a Microsoft permission, but data leaving Softwarden for Anthropic. An Admin turns it on with an Anthropic API key (Fernet-encrypted, write-only; without one, the installation’s ANTHROPIC_API_KEY, offered only when SOFTWARDEN_ASSISTANT_INSTALLATION_CAP_USD caps each organization’s spend on it). Calls go through the official anthropic Python SDK to the Messages API at api.anthropic.com: POST /v1/messages/count_tokens (to reserve the worst-case cost against the monthly cap before each call) and POST /v1/messages (structured JSON output, effort low, model SOFTWARDEN_ASSISTANT_MODEL, default claude-sonnet-5-5). The base URL is fixed (https://api.anthropic.com), so ANTHROPIC_BASE_URL and SDK profiles are ignored. The key travels in the SDK’s x-api-key header only. The SDK’s and its HTTP clients’ loggers (anthropic, httpx2, httpcore2, httpx, httpcore) are pinned to WARNING, because at DEBUG they log the whole request.

The key in use and the installation’s configured secrets are redacted from the text sent, as a second line of defense. Stored: per call the model, the four token counts, the cost, the outcome and the candidate count (AssistantUsage); per candidate the suggestion. Never the prompt, the response text, an API error message or the key. The system prompt is the same for every call and comes first, the candidate data last. It is shorter than the model’s cacheable minimum (1,024 tokens), so it carries no cache_control marker and nothing is cached today; the marker is added automatically if the prompt grows past it.

Phase 11 roadmap: built and candidates

Listed so the roadmap’s permission cost is visible early. Each needs research on Microsoft Learn before it is designed. Items 1, 3 and 10 are built. Their endpoints, permissions, license, retention and throttling are in “Discovery source: entra_shadow_it”, “Discovery source: entra_coverage” and “Discovery source: entra_licence_usage” above.

Change history

• 2026-11-03, Phase 0: created from IT1’s PERMISSIONS.md and IT2’s code. No Microsoft Learn checks performed in this repository; IT1 citations carried over with their dates.
• 2026-11-05, Phase 5 channels: Email via Graph, SMTP fallback, Teams Workflows webhooks and generic webhooks built against Microsoft Learn (checked 2026-11-05); the Graph client is shared with discovery (core/graph.py). Live checks pending on the owner-approved dev tenant.
• 2026-11-06, Phase 6 Connections: MicrosoftConnection and HaloConnection with the connection test (token only; no permission beyond the token). AADSTS65001 and AADSTS7000229 added to IT1’s classification, not yet verified on Learn. Halo base URLs go through core/outbound’s service rule.
• 2026-11-06, Phase 6 Sources B: azure (per-type ARM lists, Reader), powerplatform (Dataverse bots and workflows by environment URL; BAP for All environments, opt-in) and halo (assets) built against the 2026-11-06 research, with access checks. Per-audience tokens with host allow-lists. Not verified on Learn and to confirm: the Web Apps list api-version (2024-04-01), the Automation accounts list api-version (2024-10-23), the workflowapp kind of Standard Logic Apps and Flex Consumption kinds, the Dataverse privileges and their error wording, workflow statecode values, AADSTS500011, and the Power Platform API’s service-principal roles (BAP used instead).
• 2026-11-06, Phase 6 Sources A: entra (enterprise apps and app registrations merged by application ID, owners, credentials, agent detection) and entra_licenses built against the 2026-11-06 Learn research; access checks for both; optional User.ReadBasic.All (not yet verified) and AgentIdentity.Read.All. Role IDs other than Application.Read.All stay out of this file and the app until confirmed on Learn (DECISIONS 2026-11-06 Phase 6 (h)). 429 / Retry-After handling with a per-run budget.
• 2026-11-09, Phase 11 ticket links: Jira Cloud, ServiceNow and HaloITSM ticket connections (not Microsoft; no Microsoft permission). Jira endpoints checked on developer.atlassian.com; ServiceNow and Halo to confirm during live acceptance (see “Ticket connections”). Simulators only.
• 2026-11-06, Phase 6 Assistant: the Anthropic Messages API (not Microsoft) built behind the enterprise assistant capability, off by default; what is sent and never sent is listed above. Tested only against a mocked SDK; no real API call was made.
• 2026-11-06, Phase 6 SPA-A: the guided walkthrough links to this file, shown in the app at /discovery/permissions (section anchors such as #discovery-source-entra). The Halo connection’s default scope is now read:assets, all the source reads (it was read:assets read:tickets). A connector’s last access check is cleared when its connection or scope changes.
• 2026-11-07, Phase 8 SSO settings and generic OIDC: sign-in per organization from each provider’s discovery document (Entra, Okta, Google Workspace presets and generic OIDC), draft / test / activate, identities pinned on (issuer, subject). Entra discovery URL, issuer and the tid + oid pin recorded from the researcher’s 2026-11-07 Learn check; scopes still not verified. Tested only against the in-process simulators.
• 2026-11-07, Phase 8 SCIM: ee/scim built. No permission requested from Microsoft; “Provisioning: SCIM (enterprise), what Entra calls on us” lists the requests Entra’s provisioning service makes and Softwarden’s answers, from the research digest of Learn’s SCIM pages. Not yet run against a tenant or the hosted validator (owner step, docs/04-development/scim-runbook.md).
• 2026-11-07, Phase 9 install docs: app role IDs added for User.ReadBasic.All (97235f07-e226-4f63-ace3-39588e11d3a1), AgentIdentity.Read.All (b2b8f011-2898-4234-9092-5059f6c1ebfa) and LicenseAssignment.Read.All (e2f98668-2877-4f38-a2f4-8202e0717aa1), as read from the development tenant’s Graph service principal in Phase 6. docs/FIRST_RUN.md walks through the entra registration, permission and admin consent (Privileged Role Administrator, per Learn’s grant-admin-consent prerequisites). No new permission.
• 2026-11-09, Phase 11 shadow IT: the entra_shadow_it source built against the Phase 11 research (Learn citations): GET /auditLogs/signIns (AuditLog.Read.All, Entra ID P1 or P2, 30-day retention, 5 requests per 10 s, $top at most 1000, always a createdDateTime window), GET /oauth2PermissionGrants (Directory.Read.All, least privileged), and, under Directory.Read.All, GET /servicePrincipals and GET /organization (coverage of those two by Directory.Read.All to confirm on Learn). The license refusal (Authentication_RequestFromNonPremiumTenantOrB2CTenant) is reported as a missing license. The “Candidates for Phase 11” table now lists item 1 with its real endpoints. Simulated tenant only.
• 2026-11-09, Phase 11 offboarding and access review: no new permission and no new Graph call. The footprint and the report read the Entra owners the entra source already stores (Application.Read.All, optional User.ReadBasic.All for names and emails). Per-user license assignment is not read: on Learn (researcher, 2026-11-09) users/{id}/licenseDetails and ownedObjects are not supported with application permissions, and users.assignedLicenses needs User.Read.All, which stays unrequested; the footprint shows “Licenses: not read; needs User.Read.All”.
• 2026-11-09, Phase 11 SSO and MFA coverage: the entra_coverage source built against the Phase 11 research (Learn citations): preferredSingleSignOnMode on GET /servicePrincipals (Application.Read.All; null is unknown), GET /servicePrincipals/{id}/synchronization/jobs (Synchronization.Read.All, never Application.ReadWrite.OwnedBy; capped per run), GET /identity/conditionalAccess/policies (Policy.Read.All, Entra ID P1, 1 request/s without Retry-After). The P1 refusal code for conditional access is assumed (not on Learn); any 403 degrades the same way. Simulated tenant only.
• 2026-11-09, Phase 11 role IDs: app role IDs confirmed on Learn’s permissions reference and filled in (discovery/graph_source.py): Policy.Read.All 246dd0d5-5bd0-4def-940b-0421030a5b68, Synchronization.Read.All 5ba43d2f-fa88-4db2-bd1c-a67c5f0fb1ce, AuditLog.Read.All b0afded3-3588-46d8-8b3d-9842eff778da, LicenseAssignment.Read.All e2f98668-2877-4f38-a2f4-8202e0717aa1 (now on Learn). Directory.Read.All still unconfirmed, left empty.
• 2026-11-10, Phase 11 Okta and Google Workspace sources (API): okta (Okta Management API through an OAuth service app with a private-key client assertion, okta.apps.read, Read-only Administrator; X-Rate-Limit headers honored) and google_workspace (Reports API token audit log through a service account with domain-wide delegation, admin.reports.audit.readonly; app-level aggregates only) built against the vendors’ documentation checked on 2026-11-10 (links in their sections). Review cycle 1: Okta paces below 10 % of the org’s rate limit, assigned-user counting stops 5 minutes before the run’s deadline and keeps the listing, and an empty Google window is a note rather than a failed run. Tested only against the in-process simulators; the Okta admin role and the Google Reports privilege are to confirm during live acceptance.
• 2026-11-10, Phase 11 license waste: the entra_licence_usage source, built against the Phase 11 research (Learn citations).
  • It reads GET /users with a $select that includes assignedLicenses. This needs User.Read.All, which is new (app role ID df021288-bdef-4463-88db-98f22de89214).
  • Optionally it also selects signInActivity. That needs AuditLog.Read.All (b0afded3-3588-46d8-8b3d-9842eff778da) and Entra ID P1. Pages hold at most 500 users, and at most 10 are read a minute.
  • Both are tenant-wide admin consents. The owner grants them before live use.
  • Without P1 or the AuditLog consent, the run reads users without signInActivity and reports the last sign-in as unknown.
  • For each licensed user it stores only a keyed hash of the object ID, the SKU IDs, flags and dates.
  • Tested on the simulated tenant only.