Tenant-side telemetry is the activity and message data available inside the cloud email environment rather than only at the perimeter. It is essential for spotting internal-looking abuse because it shows sender patterns, recipient relationships, and abnormal behaviour that external gateways may never observe.
Expanded Definition
Tenant-side telemetry is the activity, message, and identity data available inside a cloud email tenant rather than only at the perimeter. It gives security teams visibility into sender behaviour, recipient graphs, authentication context, mailbox rules, forwarding changes, and sequence patterns that external gateways may never see.
In NHI security, this matters because abuse often looks ordinary from outside but becomes suspicious once the tenant’s own logs are correlated. A service account sending to a small set of internal recipients at a steady cadence, then suddenly expanding to external addresses, is a different signal from a single blocked message. The term is still used somewhat broadly across vendors, so definitions vary across vendors and no single standard governs this yet. Practitioners usually treat tenant-side telemetry as a visibility layer that supports detection, investigation, and containment, not as a standalone control.
For a broader governance lens, NHI Management Group frames visibility as foundational to NHI risk reduction in the Ultimate Guide to NHIs, while the NIST Cybersecurity Framework 2.0 places similar emphasis on detecting and responding using asset- and event-level evidence. The most common misapplication is treating perimeter mail security as sufficient, which occurs when teams ignore tenant logs and internal message metadata.
Examples and Use Cases
Implementing tenant-side telemetry rigorously often introduces log volume, retention, and correlation overhead, requiring organisations to weigh earlier detection against operational complexity.
- A service account sends routine internal notifications, then begins forwarding messages externally; tenant telemetry reveals the forwarding rule change and recipient drift.
- An AI agent with mailbox access starts generating unusually dense reply chains at off-hours; internal message timing and sender relationships show an abuse pattern that gateway filtering missed.
- A compromised API key is used to authenticate from a trusted tenant and distribute phishing content; tenant logs expose the authenticated session, not just the outbound message.
- Mailbox telemetry shows a burst of access to sensitive folders after privilege changes, helping investigators tie the event to an NHI rather than a human user.
- Post-incident review of a JetBrains GitHub plugin token exposure-style event benefits from tenant evidence that connects secret misuse to downstream email abuse, while NIST Cybersecurity Framework 2.0 supports using telemetry to identify and contain abnormal activity.
Why It Matters in NHI Security
Tenant-side telemetry is central because NHI misuse is often quiet, authenticated, and internal-looking. Gateway filters are good at stopping obvious inbound threats, but they are weaker at seeing a legitimate token, service account, or AI agent acting in an abnormal way after access has already been granted. That gap is why tenant evidence is essential for spotting recipient anomalies, unusual mail flow rules, privilege escalation, and persistence mechanisms inside the environment.
NHI Management Group reports that only 5.7% of organisations have full visibility into their service accounts, which helps explain why so many investigations stall when the activity originates from inside the tenant rather than outside it. That visibility gap also aligns with broader NHI exposure patterns described in the Ultimate Guide to NHIs, where excessive privilege and poor secret handling amplify the blast radius of unnoticed abuse. Tenant-side telemetry supports the “detect” and “respond” functions in the NIST Cybersecurity Framework 2.0 by making internal behaviour observable.
Organisations typically encounter the need for tenant-side telemetry only after a mailbox compromise, secret leak, or internal spam outbreak, at which point the concept becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Visibility and monitoring are core to detecting abnormal NHI behaviour inside tenants. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring relies on event data from the tenant, not just the perimeter. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires inspecting activity after authentication, including tenant-side behavior. |
Instrument tenant logs so service account and agent activity can be reviewed for anomalies.
Related resources from NHI Mgmt Group
- Why does tenant ownership matter for NHI governance?
- When should organisations treat runtime telemetry as a primary control?
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
- What is the difference between tenant ownership and data residency in identity governance?
