Skip to main content

Multi-tenant isolation: why your data is safe

AtherOps is a true multi-tenant SaaS. The hard invariant is: one tenant's data can never leak into or out of another tenant's. This is enforced on the server, not trusted from the agent.

org_id is always derived server-side​

Every stored signal (metric, log, span) carries an org_id that scopes it to your organization. That org_id is derived from your API key when the backend looks the key up. It is never read from anything the agent sends.

request → look up API key → KeyInfo{ OrgID, HostID, Hostname } → these win

The same applies to host_id and the host's node name: the server sets them from the authenticated key.

You cannot spoof another tenant​

Because identity comes from the key lookup, a malicious or buggy agent cannot write into another org by putting a different org_id in its payload:

  • Metrics: the server writes the trusted org_id, host_id, and instance labels last, so they always override any agent-supplied label of the same name.
  • Traces: spans have no org field at all; the server assigns org_id from the key.
  • Logs (OTLP): any attribute named org_id, host_id, instance, or node in the payload is dropped before the record is stored, and the stored columns are set from the key lookup.

This behavior is covered by cross-tenant security tests, including a test that sends a spoofed org_id and asserts the stored row carries the real, key-derived org, and that the spoofed value appears nowhere.

The spoof-resistance is proven by automated tests at the code level. A separate end-to-end verification confirms that a second org querying the first org's data receives nothing.

The key never crosses the wire​

Authentication uses HMAC: the agent sends a hash of the key plus a signature, never the raw key (see the Ingest API reference). Credentials on the host live in /etc/atherops/credentials.json at mode 0600, owned by root.

See also​