Tier & Scope Matrix¶
Two independent questions come up on almost every feature page: which plan is it on, and who in your organization can turn it on. This page answers both in one place instead of scattering the answer across pricing copy. Individual feature pages carry a short Availability callout that links back here.
The tier boundaries below are the current placeholder catalog, not commercial terms
The Community / Pro / Enterprise split on this page reflects what is actually wired into the hosted SKU catalog today - charts/helm/framework/skus/saas-catalog.yaml and api_service/sku_catalog.py. Every limit in that catalog is a marked placeholder pending a commercial decision, and the file itself says Pro and Enterprise deliberately carry the same capability shape today - nothing has been decided yet about what separates them. Nothing on this page states a specific number (a scan count, a retention window, a seat count) because none of those numbers exist yet. What is real: which scanners and frameworks a tier's enabledScanners / enabledFrameworks list includes, because that's a structural gate the API enforces today, not a number.
Scanners and frameworks (enforced by the SKU catalog)¶
This table reflects the enabledScanners / enabledFrameworks lists in the hosted catalog. Self-hosted installs are not subject to any of this - every scanner your Helm values enable is available regardless of tier, because there is no tenant/catalog concept outside the hosted SaaS deployment.
| Scanner | Community | Pro | Enterprise | Scope |
|---|---|---|---|---|
| Codebase Analyzer (secrets, IaC, SAST, deps) | ✅ | ✅ | ✅ | Tenant |
| SBOM + License Scanner (codebase sub-scanner) | ✅ | ✅ | ✅ | Tenant |
| Cloud Inspector (AWS / Azure / GCP) | - | ✅ | ✅ | Tenant |
| WAF Assessment (rides on a cloud scan) | - | ✅ | ✅ | Tenant |
| Container Image Security | - | ✅ | ✅ | Tenant |
| Kubernetes In-Cluster Scanner | - | ✅ | ✅ | Tenant |
Penetration Testing (pentest-agent) | - | ✅ | ✅ | Tenant |
| Framework access | Community | Pro | Enterprise |
|---|---|---|---|
| Built-in frameworks | Restricted to a subset (currently SOC 2 only, placeholder) | All 22 | All 22 |
Custom Frameworks / Checks / Rego Policies are a separate mechanism from enabledFrameworks - they aren't gated by the SKU catalog at all today. See the "marketed tier, not yet catalog-enforced" table below rather than reading them as part of the enforced list above.
Two scanners aren't in the entitlement map yet
DAST (web_applications) and PII Discovery (pii_scan) are real, working scanners, but the code that restricts scanners by tier (run_trigger.py's scope-to-scanner map) doesn't include either one yet. Today they run regardless of tier on a hosted deployment. Treat their eventual tier as unassigned rather than "Community", even though nothing stops a Community tenant from using them right now.
Platform capabilities (marketed tier, not yet catalog-enforced)¶
These features exist and work in the product, and the marketing tier list places them on Pro or Enterprise - but unlike the scanner list above, there is currently no code path that checks a tenant's sku before allowing them. Any tenant with the right scope can use them today, regardless of plan. Listed here as "marketed" so this page stays honest about the gap rather than implying enforcement that doesn't exist.
| Capability | Marketed tier | Scope | Enforced by catalog today? |
|---|---|---|---|
| SSO Configuration (OIDC + SAML) | Pro and Enterprise | Admin | No |
| Custom Policies (Rego) / Custom Checks / Custom Frameworks | Pro and Enterprise | Admin (write) | No |
| Exports (SARIF / OCSF / ASFF), Security Hub push | Pro and Enterprise | Tenant | No |
| GitHub PR blocking (check runs) | Pro and Enterprise | Tenant | No |
| Ticket Sync (Jira / GitHub Issues) | Pro and Enterprise | Tenant | No |
| Slack / email / webhook alerts | All tiers marketed | Tenant (per-user preferences) | No |
| LLM Configuration (BYOM) | Enterprise | Tenant admin | No |
Admin-scoped vs. tenant-scoped, at a glance¶
"Admin" below means require_admin_actor(): the tenant admin role, resolved from the signed-in user's own record through the console's verified actor assertion and bounded by the scopes of the credential that presents the request. AUTH_ADMIN_EMAILS is not consulted on that path - it assigns the console session role at sign-in, and survives at the API only as a legacy fallback for a console-style caller that sends no assertion at all. "Tenant" means any authenticated member with the listed scope - no organization-admin role required.
| Area | Scope | Notes |
|---|---|---|
| Admin Console (Users, Organizations, API Keys, Service Accounts) | Admin | require_admin_actor() |
| SSO Configuration | Admin | require_admin_actor() |
| Teams | Admin | Membership and scope mapping are admin-managed; a team itself only restricts visibility, it grants no extra permission |
| Custom Frameworks / Checks / Rego Policies - writes | Admin | Reads only need an API key |
| Compliance parameter overrides - create / delete / bulk | Admin | require_admin_actor(); the list route still needs only read. An override changes what a check is measured against for the whole organization on every future run |
| Other organizations of your tenant (list, create, manage) and tenant admins | Tenant admin | An organization admin who also holds the tenant-admin role. An organization admin without it manages their own organization only |
| Billing (checkout, provider portal) | Tenant admin | A tenant admin or platform:admin; see the note below the table |
| LLM Configuration (BYOM) | Tenant admin | A tenant admin on all four routes, the read included |
| Connections (cloud, repo, registry, cluster, web app, pentest target) | Tenant | write scope |
| Notifications (personal preferences) | Individual user | Keyed to the signed-in user's verified identity, not the organization |
| Running an Inspection / Schedules | Tenant | write scope; schedule mutation needs schedule:write |
| Remediation approvals | Tenant | remediation:approve scope |
| Findings mutation (mute rules, issue links) | Tenant | findings:write scope |
The platform:admin half of the Billing gate has a deployment prerequisite
A console platform admin resolves to platform:admin alone, intersected with the presenting credential's scopes - so the console's key must be named in PLATFORM_ADMIN_API_KEYS (api.auth.platformAdminApiKeys), which is empty by default. A tenant admin reaches Billing either way.
Self-hosted installs¶
Everything above describes the hosted (SaaS) deployment profile, where a tenant's sku gates scanners and frameworks. A self-hosted install has no tenant/SKU concept at all - every agent your charts/helm/framework/skus/*.yaml preset or your own values.yaml enables is available to everyone with the right scope on that deployment, with no plan boundary. Don't read "Community" above as "the self-hosted default" - they're unrelated axes.