Security & Privacy
Access control inside GovIntel
Three internal roles with different powers, where the fields that authorize an assessment are restricted to one of them by design.
Three roles
| Role | Can |
|---|---|
| Viewer | Read engagement and enquiry records |
| Operator | The above, plus editing working state on an engagement |
| Admin | The above, plus credentials, access and payment status, dispatching an assessment, and issuing delivery links |
Every authenticated request is checked against these.
What is restricted to admin, and why
The fields that unlock an assessment — the role identifier, the cloud identifiers, the access status and the payment status — are admin-only wherever they appear, and the restriction is enforced on the request body rather than by route.
An operator therefore cannot mark an engagement authorized and paid and then run it. Approval and execution both sit with admin.
Why this exists
Before roles existed, any account in the system could read every customer's role identifier, edit any engagement, and dispatch an assessment against any customer's AWS account.
Accounts predating roles cannot sign in
An account with no role is refused. It is not defaulted to the lowest role, because a silent default is how a dormant account becomes an active one nobody reviewed.
Customers are a separate audience entirely
Customers have no GovIntel login and never will. The customer surface is a separate router with its own guard, and nothing there shares middleware with the internal API.
A customer session cannot name an engagement, see anything commercial, write any field, reach a connected state, or dispatch an assessment.
Known limitation
The internal console's route guard is enforced by the backend on every request. GovIntel's own security documentation records that the client-side guard alone would not be sufficient, and that the backend authorization is what makes it safe.