Skip to content

Tenant Consent Required

URI: https://docs.ankatech.co/errors/audit-tenant-consent-required
HTTP Status: 403 Forbidden

When you see this

A platform administrator asked the Audit API for a customer tenant's audit trail directly, from the platform plane, on a deployment ANKATech operates. On such a deployment a platform administrator reads a customer tenant's audit trail only inside a support-access session that tenant granted: the tenant declares a time-boxed, revocable grant, the administrator enters with a fresh strong proof, and every read made inside the session is recorded and shown to the tenant.

The rule is deployment-scoped. It applies on SAAS and DEDICATED_SAAS deployments, and on a deployment whose recorded type is absent or unrecognised, which is treated as SaaS. On PRIVATE_CLOUD and ON_PREMISE the platform administrator is the deployment's own owner, the rule does not apply, and these requests are answered with the tenant's records.

This is not a missing scope: the caller holds the platform audit scope the operation names. The refusal is raised before any record is read, and the platform tenant's own trail is never refused.

Common Causes

  • A tenant-path read for a customer tenant with a platform token: any GET /api/v3/audit/tenants/{tenantId}/... operation (crypto, admin, authentication, unified feed and export, statistics, governance, platform actions, support-access sessions, the Cryptographic Control Plane reads and the tenant operation result).
  • A tenant meta-audit read for a customer tenant with a platform token: GET /api/v3/audit/meta/tenants/{tenantId}/access-logs, /platform-reads and /stats. A tenant's own auditor reading its own tenant is unaffected.
  • A tenantIds filter naming any customer tenant on the platform time series (getPlatformCryptoTimeSeries, getPlatformAdminTimeSeries) or on the platform statistics (getPlatformCryptoStats, getPlatformAdminStats, getUnifiedPlatformStats, getPlatformAuthStats). The whole request is refused; the list is never filtered silently. A list naming only the platform tenant is admitted, and no filter returns the deployment-wide totals.
  • A readerTenantId naming any customer tenant on the platform meta-audit explorer (getAllAccessLogs, page and CSV export). Without it, the explorer lists the platform tenant's read records.
  • GET /api/v3/audit/platform/rejected-events/{id}/payload for a rejected record whose claimed tenant is not the platform tenant, or for an id no listed record carries. The answer is the same in both cases and does not echo the id.

The audit-integrity endpoints are not refused: verification runs and verdicts carry counts and status, not audit content, and stay available to the platform on every deployment type.

Response Example

{
  "type": "https://docs.ankatech.co/errors/audit-tenant-consent-required",
  "title": "Tenant consent required",
  "status": 403,
  "detail": "On this deployment a platform administrator reads a tenant's audit trail only through that tenant's support access.",
  "instance": "/api/v3/audit/tenants/{id}/crypto/events",
  "timestamp": 1785578400,
  "extensions": {
    "requestId": "1f0c2a7e-9b41-4d3a-8e52-6c7d8e9f0a1b"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

Branch on type, not on the status: the generic forbidden type reads as a missing scope and would send an operator to widen a role, which cannot help here. The title and detail are fixed. The body is the same whether the tenant has a live support-access grant, has none, or does not exist: instance names the operation with the tenant id replaced by {id}, and only timestamp and extensions.requestId vary between requests, so the answer discloses nothing about the tenant.

The refusal is recorded. For a tenant that exists, the refused read is listed, with outcome FAILURE, in that tenant's view of the platform's reads of its trail, naming the operator by a pseudonymous reference.

How to Resolve

  1. Ask the tenant's administrator to grant support access for the window the work needs (at most 24 hours).
  2. Enter the tenant through the support-access session, with a platform auditor or super administrator account, and read the trail there. The session acts with the tenant's auditor or administrator role, and every read made inside it appears in the tenant's view of the platform's reads.
  3. For a deployment-wide question, use the platform reads without a customer tenant filter: they answer with the platform's own records and deployment totals.
  4. To investigate a rejected record that claims a customer tenant, ask that tenant to read it through support access, or rely on the deployment-wide counts by rejection reason and source.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.