7.3 Granular 8-Role RBAC Permissions Matrix

Granular permissions matrix across Organization, Project, and Runner levels.

Separating Who Writes Tests From Who Spends Judge-Model Budget

A single Admin/Member split doesn’t hold up once a QA org grows past a handful of people – a contractor reviewing results shouldn’t be able to touch Vault secrets, and someone authoring test cases shouldn’t need the same trust level as whoever approves a quarantine override or rotates a CMEK key. CertiQA’s eight roles exist to draw those lines explicitly, scoped at the Organization, Project, or System level depending on how broad the capability is.

Role	Scope	Capabilities
ORG_ADMIN	Organization	Full tenant lifecycle management, CMEK key operations, billing, and user provisioning.
PROJECT_ADMIN	Project	Manage project suites, Vault secrets, integrations, and who holds which project-level role.
AUTHOR	Project	Create and edit test suites, cases, and CertiBlocks™.
APPROVER	Project	Review triage proposals and approve quarantine or quality-gate overrides.
AUTOMATER	Project	Execute test suites, trigger fuzzer runs, and call judge APIs – anything that spends model quota.
RUNNER	System	Headless CI daemon execution and telemetry ingestion – the identity a CI pipeline or BYOC runner authenticates as.
REPORT_READER	Project	Read-only access to execution reports and CTRF summaries.
PROJECT_READONLY	Project	Read-only access to test definitions – for reviewing what a suite does without seeing results or run history.

Rank, Not a Full Capability Matrix

Role checks compare a single numeric rank rather than consulting a per-endpoint capability table, and by design AUTHOR, AUTOMATER, and RUNNER share the same rank. Practically, that means an endpoint gated to “AUTHOR” also admits AUTOMATER and RUNNER, and one gated to “AUTOMATER” likewise admits AUTHOR and RUNNER – the three roles are separated for clarity about what each is meant for, not enforced as mutually exclusive at the permission-check level. If your org needs a stricter separation of duties between authoring and executing, enforce it by who you actually grant which role to, rather than assuming the platform will stop an AUTHOR from triggering a run.

Where Each Role Actually Gets Used

• CMEK key rotation and billing changes require ORG_ADMIN specifically – no project-level role can reach either.
• Approving a quarantine override or a quality-gate exception requires APPROVER, kept separate from AUTHOR so the person writing a test isn’t also the one who decides it’s safe to bypass.
• REPORT_READER and PROJECT_READONLY cover two different things a read-only stakeholder might need: results without test definitions, or test definitions without run history – assign whichever matches what the person is actually there to see.