Cross-tenant log exfiltration is the leakage of logs from one account or tenant to another tenant’s storage. It usually happens when a log destination is misconfigured, an attacker controls the target bucket name, or the service lacks ownership checks before writing the records.
How cross-tenant log exfiltration happens
Cross-tenant log exfiltration is not a logging failure in the narrow sense, it is a tenancy boundary failure. The same pattern that causes data to be written into the wrong storage account can also leak audit trails, application telemetry, and security events across customer boundaries when the destination is ambiguous, attacker-controlled, or not ownership-checked.
The key failure is that the logging pipeline trusts a target location or identifier without proving that the destination belongs to the intended tenant. In practice, that can turn a routine write path into an unintended data-disclosure path.
Why logs are sensitive when tenancy boundaries fail
Logs often contain usernames, IP addresses, session identifiers, tokens, request paths, configuration values, and error traces. That means a cross-tenant leak can expose both operational detail and security-relevant material, including clues that help an attacker understand environment structure, authentication flows, and incident response activity.
The danger is greater than simple confidentiality loss because logs can reveal patterns that are hard to reconstruct elsewhere. Even when the records do not include plaintext secrets, they may still expose enough context to support account abuse, phishing, lateral movement, or follow-on cloud abuse.
For cloud and SaaS services, this is closely related to how storage targets are validated before data is handed off. Our T1537 Transfer Data to Cloud Account Defensive Guide covers the same exfiltration pattern from the defender side, including storage-policy mistakes and cross-account transfer paths.
Common causes and exposure checks
This issue usually appears when an organisation allows tenant-specific log destinations to be configured by name, URL, bucket, workspace, or project reference, but does not bind that reference to an ownership check. A malicious tenant may try to register a confusingly similar destination, or a misconfiguration may simply route logs to the wrong place.
Exposure checks should start with inventory and routing review: which services emit logs, where each stream is supposed to land, and whether the destination is resolved from a tenant-scoped control plane or only from a user-supplied value. Vendor documentation and storage policies matter here because the authoritative answer is often in how the service enforces destination ownership, not in how the UI labels the field.
Cross-checking log sinks, bucket policies, workspace assignments, and tenant metadata is especially important when logs traverse managed cloud storage or third-party observability platforms. A logging path that looks harmless in one account can become a tenant breakout if the sink is shared or weakly isolated.
Containment, detection, and recovery
When the defect cannot be fixed immediately, the practical response is to restrict which destinations are permitted, force explicit tenant-to-sink bindings, and isolate or suspend any route that can be influenced by an external party. If the logging system supports it, prefer allow-listed destinations over free-form names and require server-side ownership verification before any write occurs.
Detection should focus on unusual sink creation, unexpected destination changes, cross-tenant bucket access, and log delivery to resources that the owning tenant does not control. After a suspected exfiltration event, review whether the leaked records contained session material, API keys, account identifiers, or incident data that should trigger credential rotation or session invalidation.
If the logging platform can retain tamper-evident delivery records, those records should be used to confirm what was written, where it was delivered, and whether any other tenants received the same stream.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Cross-tenant log leakage concerns audit/log integrity and unauthorized disclosure. |
| AC-3 — Access Enforcement | Tenant-bound log destinations require enforced authorization before writes to storage targets. | |
| CM-6 — Configuration Settings | Misconfigured log destinations are a configuration-control failure with direct exposure impact. | |
| Recommendation — Protect audit records from unauthorized access and ensure logs stay bound to the correct tenant. Enforce access decisions so only the intended tenant can write to its log destination. Harden and validate logging configuration so destination settings cannot drift across tenants. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared or mis-bound log sinks often follow from weak account and ownership management. |
| Recommendation — Restrict and review who can create or change tenant-scoped logging destinations. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | The term concerns the protection and correct routing of log data within an ISMS. |
| Recommendation — Define and control logging so records are routed, retained, and protected per tenant. | ||
Practitioner Guidance
Why practitioners should care: Cross-tenant log leakage is both a data exposure problem and a control-plane trust problem. The operational mistake is often to treat logging as passive infrastructure, when in reality the sink-selection logic is part of the security boundary.
Common misunderstanding: teams often assume that a log path is safe because the payload is only “telemetry.” In practice, telemetry frequently includes identifiers, troubleshooting detail, and incident-sensitive context that should be treated as tenant-bound data.
Practitioner takeaway: validate log destinations the same way you validate write access to any other tenant-scoped resource, because the security outcome depends on ownership enforcement, not on the label of the data stream.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org