Appearance
Security Boundaries
Four boundaries a tenant administrator should understand.
1. Tenant isolation
Every query in OrviQ is automatically tenant-scoped. Module code does not filter by tenant; the data layer enforces it.
The practical consequence: a defect in module code cannot leak another tenant's data, because the isolation does not depend on module code remembering to apply it.
| Scoped by tenant | Includes |
|---|---|
| All governed records | Requirements, controls, evidence, risks, findings, actions, policies, incidents, everything |
| Business reference sequences | Tenant, entity type and year scoped |
| AI interactions | Prompts, responses and provenance |
| Audit trail | Tenant activity |
| Settings and configuration | All of it |
See Tenant Isolation.
2. The platform console boundary
Platform permissions can never be represented in a tenant role
Platform-console permissions are deliberately outside the tenant permission catalogue. There is no tenant role that can be constructed to include them, and no configuration that grants a tenant administrator platform access.
The boundary is not a permission check — the permissions do not exist in the tenant namespace at all.
| Tenant administration | Platform administration | |
|---|---|---|
| Scope | Your tenant | The service |
| Who | Your administrators | The service operator |
| Covers | Users, roles, workflow, settings, integrations | Tenants, provisioning, deployments, platform security |
| Documented in customer docs | Yes | No |
3. Administration is not governance authority
Four permissions are never auto-granted, including to Tenant Administrators:
| Permission | What it governs |
|---|---|
tprm.assess | Third-party risk assessment |
tprm.classify | Regulatory classification |
tprm.decide | Engagement approval |
assessment.review_self_override | The segregation-of-duties break-glass |
A related pattern applies to control_source.override_trust, which is deliberately narrower than control_source.publish and cannot be consumed by the person who granted it.
The principle: whoever maintains the platform is not thereby qualified to make professional governance decisions inside it. See Segregation of Duties.
4. What secrets are never exposed
| Secret | Handling |
|---|---|
| API tokens | Shown once at creation, never again |
| AI provider keys | Only the last few characters displayed |
| Connection credentials | Never displayed after entry |
| Provider endpoint internals | Never exposed to tenants |
Rotation is supported everywhere credentials are held, and preserves the identity and history of the thing being rotated.
See Secret Handling Principles.
The audit trail
Every governed mutation produces an audit record: the actor, the action, the object, and the before and after state.
Notable properties:
- No parallel audit systems. Modules use the same audit path rather than maintaining their own.
- Dedicated events for sensitive actions. The segregation break-glass raises its own distinct event rather than a generic one, so it can be found without knowing to look for it.
- Workflow transitions are captured alongside domain state changes.
Reading the audit trail requires audit.read.
What a tenant administrator should review periodically
Role assignments against workflow chains. One person holding two consecutive stage roles collapses a chain's depth. This is the most common way a well-designed approval chain silently weakens. See Workflow Configuration.
Holders of never-auto-granted permissions. tprm.decide in a role held by two people is meaningful; in a role held by twenty it is not.
Break-glass usage. assessment.review_self_override raises a dedicated audit event. Any use should be explicable.
API key inventory and scopes. Unscoped or shared keys, and keys belonging to decommissioned integrations.
Organisational unit coverage. Users without a unit break the owner_department_head resolver and are absent from department reporting — silently, in both cases.
Movers. Someone who moves from operations to compliance and retains both role sets can approve their own prior work. Movers are a bigger segregation risk than joiners or leavers.
Permissions
| Action | Permission |
|---|---|
| Read the audit trail | audit.read |
| Manage users and roles | users.*, roles.* |
| Manage API keys and webhooks | api.manage, webhook.manage |
| Edit tenant settings | settings.manage |
| Configure workflows | workflow.configure |
Example
A tenant administrator's quarterly review.
| Check | Finding | Action |
|---|---|---|
| Role assignments against chains | The Compliance Officer and Compliance Manager roles were both held by one individual, collapsing the six-eye policy chain | Reassigned; a second Compliance Officer appointed |
| Never-auto-granted permissions | tprm.decide held by one person, with no deputy | Deputy added, to avoid a single point of dependency |
| Break-glass usage | No uses in the period | No action |
| API keys | Two keys belonging to a decommissioned integration | Revoked |
| Organisational unit coverage | 11 users without a unit, all recent joiners | Units assigned; onboarding step added |
| Movers | Three movers in the period; one retained a prior operations role alongside a new compliance role | Prior role removed |
The mover finding was the most consequential. The individual could, in principle, have approved control assessments they authored in their previous role. Nothing had happened — but the configuration permitted it, and only a review would have found it.