Trace access
Trace access in the platform is gated by two independently grantable permissions. Production traces — those captured in environments flaggedis_production = true — are held behind a permission distinct from the one that grants access to non-production traces. The split is enforced at the database layer through ClickHouse row policies, not at the application layer.
The two permissions
| Permission | Scope | Grants |
|---|---|---|
traces:read | Project | Read traces from environments where is_production = false. |
traces:read:prod | Project | Read traces from environments where is_production = true. |
traces:read:prod does not imply traces:read. They are independently grantable. Most users who hold prod-trace access hold both, but the split is meaningful for API keys scoped to prod-only ingestion paths.
Which roles hold which permission
The cascade is applied to existing tier roles. No dedicated prod-trace-reader role exists.| Tier | Role | traces:read | traces:read:prod |
|---|---|---|---|
| Organisation | org_owner | Y | Y |
| Organisation | org_admin | Y | Y |
| Organisation | org_developer | Y | |
| Organisation | org_member | ||
| Workspace | workspace_owner | Y | Y |
| Workspace | workspace_admin | Y | Y |
| Workspace | workspace_developer | Y | |
| Workspace | workspace_viewer | ||
| Project | project_owner | Y | Y |
| Project | project_admin | Y | Y |
| Project | project_developer | Y | |
| Project | project_viewer |
org_member hold neither trace permission. Developer-tier roles hold only non-production trace access. Admin and owner roles at every tier hold both.
No dedicated prod-trace-reader role
Some early documentation refers to a
project_prod_trace_reader role. The role was prototyped during platform development and retired before public launch when its mutually-exclusive interaction with the project-membership primary key would have stripped recipients of every other capability. Prod-trace access is now granted by assigning one of the *_admin or *_owner tier roles. To confirm the current set of roles on your organisation, visit the isolation-conformance view at /org/[orgSlug]/settings/isolation-conformance — it lists the active roles and the policies in force.Capture-time classification
A trace’s production / non-production classification is captured at the moment the trace is written, sourced from the originating environment’sis_production flag at that moment. Subsequent changes to the environment’s flag do not retroactively re-classify historical traces. A trace captured in a non-production environment remains non-production-classified even if the environment is later flipped to production, and vice versa. This behaviour is intentional and preserves audit determinism — see the prompt-management environment-policy documentation for how to manage the underlying flag.
The boundary state
A user who opens a shared link to a production trace without holdingtraces:read:prod sees an explicit state explaining that the trace is in a production environment and that their current role does not include production trace access. The platform does not return a generic 404 for this case — the boundary state names the missing permission so the recipient can request access from a project administrator if appropriate.
Audit trail
Every grant, revocation, and role change touchingtraces:read or traces:read:prod is recorded in the platform’s RBAC audit log with five-year retention. Each row records the actor, the affected principal, the prior and new effective permission set, the scope, and the timestamp. Customers surface the log through the project audit feed at /org/[orgSlug]/ws/[workspaceSlug]/prj/[projectSlug]/audit.
Verifying the substrate yourself
Organisation administrators can confirm that the canonical policies are in force on every project-scoped table — on both Postgres and ClickHouse — through the isolation-conformance view at/org/[orgSlug]/settings/isolation-conformance. The view lists every project-scoped table on both stores, the policy state, the canonical predicate text, and the most recent CI conformance-test result. CSV export is available for inclusion in compliance evidence packets.
Phase 2 — legacy-trace backfill
Traces captured before the platform’s capture-timeis_production_env enrichment shipped are treated as non-production for access purposes. A backfill capability for organisations that need historical production traces re-classified is on the Phase 2 roadmap (see docs/prds/2026-05-19-data-isolation-prd.md §Phase 2 item 10). Contact platform support if this gap blocks an active compliance review.
Grant production trace access
Step-by-step guide to granting and revoking
traces:read:prod for users and API keys, with audit-log verification.Isolation conformance view
Live cross-store policy state for every project-scoped table in your organisation. Read-only, accessible to organisation administrators.