Privacy Policy
This is a working draft written to be directionally accurate about how the architecture handles data, not a signed legal document. Have counsel review it before it's published as binding.
TenantSage is designed to process less than most systems, on purpose.
Because enforcement can sit close to a customer's own systems, TenantSage's design goal is to need as little of the underlying content as possible — governance decisions run on metadata, authority state, and policy, not on a copy of everything being governed.
Categories of data involved in a governed request.
| Category | Examples | Purpose |
|---|---|---|
| Identity claims | Verified OIDC token contents, principal ID, role | Resolving authority for the request |
| Scope & policy metadata | Tenant, family, classification, retention flags | Computing the eligible evidence boundary |
| Evidence references | Source and chunk identifiers, not necessarily full content | Proving what was retrieved without duplicating it |
| Decision & receipt data | Allow/deny outcome, stage, hashes, timestamps | The audit ledger itself |
Deliberate non-goals.
Where a customer's enforcement point runs close to their own systems, TenantSage's ledger can hold references and hashes rather than full content — enough to prove a decision was made correctly, without becoming a second copy of everything it governs.
The ledger respects the same holds it enforces.
Evidence and decision records tied to a legal hold are retained under that hold's terms, not TenantSage's default retention schedule — the system that enforces holds against retrieval is bound by them for its own audit trail too.
Access, correction, and deletion requests.
During the pilot phase, requests about personal data processed by TenantSage should go through your organization's designated pilot contact, who will route them appropriately. A dedicated privacy contact address will be published here once the pilot program concludes.