Access Control
Two independent server-side permission layers, the authentication methods available, and the safety controls around high-consequence actions.
Access control is enforced in two independent layers, both server-side. Hiding a control in the interface is never the security mechanism.
The two layers
Page permissions — 27
Each governs access to one module or a small family of related modules. They control both navigation and the API routes behind it.
Action permissions — 69
Each governs an individual operation rather than a page. Seeing a module and being allowed to change something in it are separate grants.
A user without the vendors page permission does not see Vendor Hub in the sidebar — and
equally cannot reach its endpoints directly.
Action permissions follow a domain.verb naming scheme: policies.create,
approvals.decide, intelligence.waste_scan, autopilot.rules.manage,
integrations.execute_remediation, and so on.
The design principle
Page permissions answer "can this person look at this?" Action permissions answer "can this person change this?"
Every write route asserts an action permission independently of the page permission that got the user there. Apex enforces exactly the same two layers, so the natural-language interface can never become a permission-escalation path.
The complete catalogue is in Reference → Permissions.
Why this matters commercially
Two-layer permissions mean access can be granted precisely. A finance analyst can be given every read surface in the product without any ability to change cloud infrastructure.
That precision is what allows a cost platform to be opened up to finance and leadership rather than restricted to a small platform team — which is usually the difference between a FinOps programme that spreads and one that stalls.
Authentication methods
| Method | How it works | Availability |
|---|---|---|
| Email and password | Bcrypt-hashed credentials, email verification at signup, challenge-based password reset | All plans |
| OAuth | Google, GitHub, and Azure AD social sign-in with nonce-protected state exchange | All plans |
| Enterprise SSO | OIDC and SAML 2.0, signed assertion validation, IdP discovery by email domain | Enterprise |
| SCIM 2.0 | Automated user and group provisioning and de-provisioning, rotatable bearer token, group-to-role mapping | Enterprise |
| API tokens | SHA-256 hashed, shown once at creation, configurable expiry, instant revocation | Pro and above |
Configured in Identity & SSO and Settings.
Why SCIM matters more here than elsewhere
Automated de-provisioning closes the most common real access-control failure — accounts that remain active after someone leaves. That matters more in this product than in most, because platform access can reach cloud infrastructure.
Additional safety controls
Beyond the permission layers, high-consequence operations carry extra protection:
Recommended grant practice
Review the permissions catalogue before adding users
So the grant model is understood in product terms rather than guessed at.
Grant the minimum set the role requires
Permissions are easier to add than to justify removing.
Reserve the dangerous write permissions
Particularly approvals.decide, integrations.execute_remediation, and the autopilot.*
family — for the small number of people accountable for changes to the estate.
Review elevated access periodically
Use the team snapshot in Organization rather than waiting for an audit to ask.
Move provisioning to SCIM at enterprise scale
Managing users by hand does not survive organisational change.
Cloud Coverage
Five infrastructure surfaces treated as first-class citizens — each with its own credential model, ingestion path, detector family, and remediation actions.
Plans & Limits
Four subscription tiers, what each includes, the hard limits enforced, and the two capability flags that matter most.