Skip to main content
Wildo.ai Coming soon

Privacy and subject rights

Review retained information with a reason and a record

Provide a privileged, scoped read of retained records whose disclosure must itself be recorded.

An authorized reviewer supplies a reason and leaves an audit receipt before reading retained records through a dedicated read-only view.

Review retained information with a reason and a record

Retained information can need review without returning it to ordinary use. Wildo provides a distinct read that requires a privileged person and a reason, while preserving the record’s scope.

The review leaves an attributable audit event. If that disclosure cannot be recorded, the result is withheld.

Example — Investigate a retained record

An authorized reviewer supplies their identity and investigation reason. They can inspect the retained row through the dedicated path without reopening it to normal editing or search.

For engineers

The application must authenticate the reviewer and derive their roles from trusted authorization state. Never accept the following attribution fields as unchecked browser claims. This actual method connects the entry gates, scoped read and audit-before-return sequence:

Source: system-access.backend.service.ts (selected excerpt).

  public async readRetainedAsSystem<T = any>(
    resourceType: ResourceType,
    id_or_ids_or_filter: IdOrIdsOrFilterType,
    auth: { accessingUserId: string; accessingUserRoles: string[]; reason: string },
    options?: ServiceOptions & {
      scopeContext?: { organizationId?: string; applicationId?: string; userId?: string };
    },
  ): Promise<T | null> {
    this.assertSeeRetainedAllowed(resourceType);
    this.assertSeeThroughRole(auth.accessingUserRoles);
    this.assertSeeThroughAttribution(auth.accessingUserId, auth.reason);

    const operationPath: ResourceConfiguration_OperationPath<any, any> = options?.variantKey
      ? this.resourcesRegistry.getServiceOperationPath(resourceType, CoreResourceOperation.READ, options.variantKey)
      : this.resourcesRegistry.getServiceOperationPathDefault(resourceType, CoreResourceOperation.READ);

    const systemContext = await this.executionContextCreator.createForInternalOperation({
      operation: operationPath,
      contextResourcesFieldIdentifier: this.buildSystemScopeContextMap(options?.scopeContext),
      initiatorIds: this.buildSystemInitiatorIds(options?.scopeContext),
      initiatorRoles: [
        {
          roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
          relatedPrimaryScope: ResourcePrimaryScope.APPLICATION,
        },
      ],
    });
    // M5b: reveal retained rows for THIS read only (suppresses ONLY the retention predicate, not scope).
    systemContext.setSeeRetainedData(true);

    const result = await this.getServicesRegistryHandler().read<T>(resourceType, systemContext, id_or_ids_or_filter, options);

    // M6: HUMAN-attributed, reason-bearing, and ACCOUNTABLE — an unrecordable reveal is refused.
    await this.emitRetainedDataRevealAudit({
      accessingUserId: auth.accessingUserId,
      roles: auth.accessingUserRoles,
      reason: auth.reason,
      resourceType: resourceType as string,
      operationIdentifier: 'readRetainedAsSystem',
      retainedRecordCount: result == null ? 0 : 1,
      organizationId: options?.scopeContext?.organizationId,
    });

    return result;
  }

The resource must allow retained-data access. readRetainedAsSystem accepts an ID, IDs or a filter; listRetainedAsSystem handles collection review. Supply scopeContext where required. The implementation suppresses only the retention filter for the read, not tenant isolation.

After reading, it emits RETAINED_DATA_ACCESS with the human ID, roles, reason and result count before returning the result. Audit failure refuses the reveal. This is stronger than logging a warning after handing over the data.

The exception does not provide an update door and does not make retained records visible to subject exports. Design the application’s review screen and request approval around this backend primitive, and keep investigation reasons useful without copying the sensitive record into the reason.

Authorize the caller before creating the internal context

For a HUMAN caller, this service checks auth.accessingUserRoles for CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN. A custom auditor role alone does not satisfy that guard. The role in the internal execution-context example is the authority used after admission; supplying such an internal context is not a substitute for authorizing the human request.

The resource must separately allow retained review. Preserve subject attribution and scope, and await the access audit before returning retained values. These controls make the exceptional read accountable without reopening ordinary list or read paths.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.