Your real tenant data never leaves your environment
365Posture is a security product built for security-conscious M365 admins. Privacy is not a feature bolted on afterward — it is the architecture. Here is exactly how it works.
Tokenisation happens on your machine
Before any collected data is written to disk for upload, the collector script replaces every sensitive value — usernames, admin emails, tenant domain, tenant ID and name, Conditional Access policy names, and group names — with a token, using the pattern table below. This happens locally, before encryption, before upload.
The token map never leaves your device
The mapping between real values and tokens is saved locally as an XLSX (human-readable) and a JSON (machine-readable) file on your own machine. It is never uploaded, never transmitted, and never seen by 365Posture. You need it later to detokenise your report.
Servers only ever process tokenised data
365Posture’s backend, database, and scoring engine only ever see tokenised, anonymised values. Real tenant identifiers are never stored on 365Posture servers at any point in the pipeline.
The AI model never sees real tenant data
On the Advanced tier, an AI model generates the narrative executive summary and remediation roadmap. It is given tokenised findings only — never real usernames, domains, or tenant identifiers.
The uploaded artifact is deleted immediately
Once scoring completes, the encrypted, tokenised artifact is deleted from storage right away. It is not retained as a copy of your tenant configuration.
Read-only permissions, granted on Microsoft’s own screen
The app registration created for the assessment requests read-only Microsoft Graph API permissions only — no write access is ever requested. You approve the exact permission list on the standard Microsoft Entra admin consent screen before anything runs.
The token schema
Every sensitive value is replaced with a predictable, structured token before it ever
leaves your machine. A numeric suffix (_{m})
is added only when needed to handle naming collisions.
| Category | Pattern | Example |
|---|---|---|
| User | user{n}@domain.com | user1@domain.com |
| Admin | admin{n}@domain.com | admin1@domain.com |
| Domain | domain.com | domain.com |
| CA Policy | policy{n} or policy{n}_{m} | policy1, policy1_1 |
| Group | group{n} or group{n}_{m} | group1, group1_1 |
| Tenant ID | tenant-id-{n} | tenant-id-1 |
| Tenant Name | tenant-name-{n} | tenant-name-1 |
The scored report you receive uses these tokens throughout. A local detokenisation script, run on your own machine with your locally-saved token map, swaps them back to your real names and domains — the readable version of your report is never generated on 365Posture’s servers.
What reaches 365Posture, and what doesn’t
Never leaves your tenant
- Real user, admin, and tenant names
- Real domains and tenant ID
- The token map connecting tokens to real values
- Your Microsoft credentials — 365Posture never handles or stores them
Uploaded (tokenised only)
- Encrypted, tokenised findings artifact
- Policy configuration values (states, thresholds, settings)
- Counts and structural metadata used for scoring