Roles and permissions

Cryptographic inventory is sensitive. It is a map of where an organisation is weakest, organised for convenience. Access to it should be narrower than access to most security tooling, not wider. AutoPQC uses a small fixed role set rather than a permission builder, on the view that five roles people understand beat forty toggles nobody audits.

#The role set

Roles are granted per workspace. The same person can hold different roles in different workspaces, which is the normal case for a group security function that reads everything and operates nothing.

• Owner — one per organisation. Holds the commercial relationship, can transfer ownership, and can delete a workspace. The owner is the only role that can remove the last administrator, which is why there is always exactly one.
• Administrator — configures the platform. Manages membership and role grants, workspace scope, detector selection, identity configuration and automation credentials. An administrator can do almost everything an owner can, except end the relationship.
• Security lead — owns risk decisions. Reads everything in the workspace and is the only role below administrator that can accept, contest or defer a finding. This is the role a CISO's delegate holds. It deliberately cannot change scope or detectors, so that the person judging findings is not also the person deciding what gets looked at.
• Engineer — does the remediation work. Reads the inventory and findings, starts and re-runs discovery, and exports data to work with it elsewhere. Cannot change a finding's disposition, because closing your own ticket is not evidence.
• Auditor — read-only, and read-only in a way that is enforced rather than requested. Sees inventory, findings, scores, method version and the activity log. Cannot start a run, cannot export a configuration change, cannot alter a single byte of state. Give this to internal audit, to external assessors, and to anyone who asks for temporary access.

#The permission matrix

Read across a row to see who can perform an action. Every capability below maps to something the platform actually does today unless the row says otherwise.

Two rows deserve a note. Export is available to every role including the auditor, because withholding export from an auditor produces screenshots, and screenshots are worse evidence than a signed file. And discovery is available to engineers because re-running a sweep after a fix is the single most common action in a migration; gating it behind an administrator turns a five-minute loop into a ticket.

#Irreversible actions

Most of what happens in AutoPQC is additive and recoverable. A short list is not. These actions cannot be undone by us, by support, or by a restore, and each one asks for explicit confirmation before it proceeds.

1. 01Workspace deletion. Removes the inventory, the findings and the evidence trail for that workspace. Archive instead unless you have a deletion obligation.
2. 02Ownership transfer. Takes effect when the incoming owner accepts. The previous owner does not retain a shadow grant.
3. 03Credential revocation. A revoked automation credential is dead immediately and cannot be reinstated. Issue a new one.
4. 04Enforcing single sign-on. Once password sign-in is disabled for an organisation, re-enabling it requires a support-assisted process, by design. See Single sign-on and configure a break-glass account first.

#What the activity log records

Every state change is written to an append-only activity log with an actor, a timestamp, the workspace, and enough context to reconstruct intent. The log is what an auditor reads when they want to know who decided something rather than what was decided.

Always logged

Role grants and revocations, scope changes, detector changes, discovery runs started, finding dispositions (accept, contest, defer) with the actor and any stated reason, credential issue and revoke, identity configuration changes, exports, workspace creation and deletion.

Never logged

The contents of an export, and any secret material. We record that an export happened and who performed it. We do not retain a second copy of the file to make the log more interesting.

Visible to

Owner, administrator, security lead and auditor see the full workspace log. An engineer sees their own actions. There is no role that can edit or delete a log entry, including the owner.

The log is one of the inputs to an evidence pack. What an assessor should be handed, and in what order, is set out in What to hand an auditor.

#Where the model stops

Two further honest gaps. Time-bounded grants that expire automatically are not implemented, so an auditor's access ends when someone removes it; put a calendar reminder against every assessment window. And approval workflows — a second person signing off on a risk acceptance — are not implemented either. The log records who accepted a finding, which is accountability after the fact rather than control before it.