Skip to main content

Auditor Session Enforcement Runtime

Status​

Implemented in OP-057. Auditor-role API requests now require an active tenant-scoped auditor access session before the request reaches auditor read or export handlers.

What Was Implemented​

  • auditor_access_config and auditor_access_sessions storage with Postgres RLS and SQLite local support.
  • 90-day default auditor access windows with 30-365 day tenant bounds.
  • Admin-only session list/create/revoke APIs.
  • Fail-closed auditor request enforcement in the auth layer.
  • Redaction-safe active_auditor_session metadata on /api/v1/session for OP-066n countdown/expiry UX after the OP-057 gate succeeds.
  • auditor.session.denied, auditor.session.created, and auditor.session.revoked audit records.
  • auditor.session_status.read audit records when auditors read their active session status.
  • Compatibility with existing every-read audit and redaction behavior.

Security / Tenant Isolation​

Auditor sessions are scoped by tenant and actor. Expired, revoked, missing, or not-yet-valid sessions return 403 and write a denial audit record. Tenant admins and system admins can administer sessions; auditor actors remain read-only and cannot create or revoke their own access windows.

Validation​

make validate-contracts
make typecheck-python
make lint
make test-sqlite
make docs-build

Known Limitations​

  • Session bounds are persisted but do not yet have a tenant settings UI.
  • Auditor countdown/expiry UX is implemented in OP-066n; tenant settings and full session administration UI remain separate scopes.
  • This is the central auditor gate, not a full OPA/ABAC policy decision point.
  • Existing auditor views are still intentionally lightweight for Phase 1.