Make access across customer boundaries visible
A support action outside the operator’s organization memberships deserves a recognizable record. Wildo’s authorization layer produces a dedicated observation with the operator, target organization, operation and the grant resolved for that crossing.
The crossing record belongs to the reached customer organization. People authorized to read that organization’s audit history can inspect it through the audit-log access surface. It is not only an operator-side trace.
This helps distinguish approved support work from unexpected reach. It complements the access decision; it does not replace the permission checks or prove that the business action completed.
Example — Explain why support restored an account
An investigator connects an organization-restoration attempt to its operator and temporary access grant. The grant lifecycle provides the justification and approval history, while the business operation’s evidence shows what changed.
For engineers
This selected payload comes from recordCrossTenantAdministrativeAccess in AuthorizationsBackendService. It is framework emission code, not an event an application should re-emit from every handler:
auditLogsService.logCrossTenantAdministrativeAccess({
operatorUserId: executionContext.initiatorIds?.userId,
targetOrganizationId: rowOrganizationId,
resourceType: resourceIdentifier,
operationIdentifier: String(operation.operationIdentifier ?? ''),
variantType: operation.variantType as ResourceOperationVariantType,
variantKey: operation.variantKey,
targetResourceIds: resourceObject?._id ? [String(resourceObject._id)] : undefined,
authorizingGrantId: (executionContext as { authorizingPlatformAccessGrantId?: string }).authorizingPlatformAccessGrantId,
authorizingGrantScope: (executionContext as { authorizingPlatformAccessGrantId?: string }).authorizingPlatformAccessGrantId
? PlatformAccessGrantScope.TENANT
: undefined,
admissionDeclared: operation.admitsCrossTenantPlatformAdministration === true,
initiatorRoles: initiatorRoles.flatMap(roleInfo => roleInfo.roles ?? []),
executionType: executionContext.executionType,
})
authorizingGrantId connects this use of access to the grant’s own lifecycle. For a row crossing, authorizingGrantScope identifies the tenant-grant collection; both are absent when no tenant grant was resolved. An application-wide read grant does not substitute for row admission. admissionDeclared states whether the operation opted into crossing. Neither field alone is a business-success result: a declared operation can still lack a usable grant or fail later.
Read the sequence correctly
The fetched row identifies the organization. Organization-wide role entries determine whether the caller belongs to it. For a crossing, admission resolves the usable grant, the observation is emitted, and the tenant-boundary decision then permits or refuses the request.
This ordering includes permitted crossings and refusals reaching that observation point. It is not a record of every rejected HTTP request: a request rejected before a target row is known follows its own authentication or authorization evidence path.
| Evidence | Question it answers |
|---|---|
| Grant lifecycle | Who requested, approved, revoked or timed out the access? |
| Cross-tenant observation | Which operation reached across the boundary, under which resolved grant? |
| Operation/change evidence | What did the business action actually change? |
| Application-wide read evidence | Which broader read occurred without a single target organization? |
Example: investigate a support crossing
Use the customer’s audit inspection API with an authenticated session authorized for that organization. This illustrative query selects crossing observations; the same route’s access rules still apply:
GET /organizations/{organizationId}/audit-logs?eventType=cross_tenant_administrative_access
Inspect the returned data records for the operator, eventData.targetOrganizationId, operation and target resource IDs. Resolve eventData.authorizingGrantId in the collection named by eventData.authorizingGrantScope to find the justification and approval history. A missing grant is not enough to determine the access decision: application audit reads use administrator permissions by default, while the optional independent-approval policy requires a grant. Other grant-controlled operations still require their grants. Then inspect the business change separately: observing a crossing does not prove that restoration or another action succeeded.
Preserve the scope when a read reaches several customers
Declared cross-tenant reads outside organization-scoped resources use a second observer for READ, LIST and SEARCH. Enrollment follows the executed operation variant. The observer groups the foreign organizations actually returned, with their target record IDs; a single-record read is included, while an empty result or records belonging only to the caller’s organizations produces no crossing.
Organization-scoped resources already observed during authorization are excluded from this second path to avoid double counting. Internally initiated requests and webhook callbacks are also excluded. COUNT returns no attributable records and is not enrolled.
Each resulting crossing is stored under its target organizationId, so it participates in that customer’s authorized audit access. This attribution does not grant audit-reading permission or guarantee delivery.
For application audit reads, auditTrail.applicationReadAccess defaults to role-based; independent-approval adds a time-bound grant approved by another administrator. Both retain the read observations. This policy does not change other application-wide or tenant-support access.
When a grant is recorded, interpret authorizingGrantId together with authorizingGrantScope. Tenant and application-wide grants live in different collections, so the ID alone does not identify where to resolve the authorization. If both grants are present, the observation names the narrower tenant grant.
| Recorded scope | Grant to resolve |
|---|---|
TENANT | The temporary grant for the customer organization |
APPLICATION_WIDE | The grant authorizing the broader application read |
An application-wide directory read has its own observation, including the returned count and application-wide grant. It does not invent a target customer for a read spanning the directory.
Monitor evidence delivery as well as access
emitAuditObservation keeps audit delivery from changing the request’s authorization result. If the service is unavailable or emission fails, the observation seam reports the loss through diagnostics and metrics rather than silently converting the business request into an audit-store failure.
Delivery remains best effort. Do not interpret an absent event as proof that no access occurred, or a crossing event as proof of a successful modification. The application must retain and route evidence according to its operating policy and investigate delivery-loss signals.
Application-wide reads use their own scope classification and access-grant policy. A directory listing with no single target organization cannot be represented faithfully as a row-specific customer crossing.