Access Control and Authentication

Access control in Parascope has two halves: what a person or a key is allowed to do, and which of your infrastructure data it is allowed to see. Your own superadmins configure both, inside your tenant, and both start empty. This page describes the permission model, the four API key tiers, where multi-factor authentication is enforced and how far it reaches, the lockout behaviour on repeated login failures, and the audit log that records all of it. RBAC Administration is the how-to guide for the same surface; this page is the reviewer's version.

Teams, permissions, and data scopes

User accounts are provisioned on first login through your tenant's own identity realm. Access is granted through teams, and a user inherits the permissions and data scopes of each team they belong to. Grants can also be attached to an individual user for cases teams do not fit.

A permission is a resource paired with a set of actions. The resources are configuration items, collectors, sources, correlation rules, cost, teams, users, the audit log, credentials, the stored credentials collectors use to reach their targets, and raw_data, the verbatim source payload behind each configuration item, which can carry secrets such as container environment values. The actions are read, write, and delete, with a wildcard covering all three. The wildcard resource covers every resource, with two exceptions: it confers raw_data and credentials only when its action is also the wildcard, so a wildcard grant of read, write, and delete reaches neither source payloads nor stored credentials. The seeded Admins team holds the wildcard resource with the wildcard action; superadmins have full access regardless of grants.

Cost carries actions of its own beyond read, write, and delete. cost:read shows cost figures, cost:write schedules a cost recalculation, cost:export downloads the cost CSV, and cost:admin creates, edits, and deletes rate cards and class splits. Holding cost:admin or cost:export also confers cost:read. For a signed-in user, read access to configuration items confers cost:read as well, and so it does for a user token, which inherits its owner's live access. A service or readonly key does not gain it that way: it reads cost only through a cost grant of its own or a wildcard grant that covers it, and an admin-tier key holds every permission. Without cost:read, a configuration item's cost fields come back empty, and a filter, query, or tagging rule condition that names a cost column is refused. A tagging rule that tests a cost column runs only while the person or key that last saved its condition with cost:read still holds it. Saving a correlation rule whose match or booster path names a cost column also needs cost:read, such a rule runs only while the person or key that last saved its match criteria or boosters with cost:read still holds it, and the matched cost values a rule records as evidence are hidden from anyone reading its candidates without it.

A data scope decides which configuration items a user can see. Each scope names a source and, optionally, a specific instance within it, so scopes range from a single named Kubernetes cluster up to the whole estate. Scoping is deny by default: a user with no scope through any team and none of their own sees no configuration items at all. Permissions and scopes are evaluated on each request, so a revoked grant takes effect on the next call.

Who may change what is fixed in the API:

Deactivating a user is a soft delete that preserves their history. It clears the active flag, revokes their sessions, and revokes every API token they own, in one operation. The account and its audit trail stay readable. A superadmin cannot deactivate their own account, which keeps a tenant from clearing its last administrator by accident.

API keys and tokens

Programmatic callers authenticate with the X-API-Key header. Keys are never accepted in a query string, so they stay out of proxy logs and browser history. The platform stores a SHA-256 hash of each key and holds no copy of the key itself; the plaintext is displayed once, at creation.

Two properties in that table deserve emphasis. Service and admin tier keys are tenant-wide readers, since data scopes do not confine them, which is why they belong to the platform's own components and to automation you control, and not to individual people. A readonly key holds no scope until one is granted, and a key with an empty scope set reads nothing.

A user token stays in lock-step with its owner's live grants. Change the owner's team membership and the token's reach changes with it on the next request. Each user may hold up to 10 tokens, each with an expiry the user chooses, capped at 365 days. A token can be marked read-only at creation regardless of what its owner may write.

One grant sits outside the tier model. Reading a stored source credential back out of the platform requires an explicit sources:reveal_credentials grant on the calling key, which admin or service tier alone does not confer, and each call writes an entry to the audit log. Data Handling and Retention covers that path in full. Per-key rate limits are described in Tenant Isolation Architecture.

Reading raw_data has its own rule as well. A personal token reads raw_data exactly when its owner can. Admin-tier API keys can read raw_data; other API keys need an explicit raw_data:read grant (or raw_data with the wildcard action), and a key-wide wildcard grant does not count. Delegating (MCP) keys never can, whatever their tier. A filter, sort, attribute-value lookup or rule condition that needs raw_data is refused with 403 and a permission_denied audit entry. Where raw_data would only be displayed, such as on a CI's detail or in a list, it is returned empty and no audit entry is written.

Multi-factor authentication

A superadmin turns on Require two-factor authentication under Settings → Account → Security Policies. The setting is per tenant, and turning it on does two things: it arms your tenant's identity realm so that enrolment in a TOTP authenticator becomes a required action for users who are not yet enrolled, and it stamps the moment the policy took effect. That stamp is what dates existing sessions and keys.

The second factor is TOTP: a 6-digit code on a 30-second period, HMAC-SHA-256, with code reuse refused. TOTP is the only second factor the product supports, and there is no WebAuthn or passkey option today. If a hardware security key is a requirement for you, raise it at [email protected] before you buy.

Enforcement of the tenant policy happens at four layers, all reading the same policy record so that the setting shown in the UI and the setting that gates traffic cannot drift apart:

At the callback the check reaches past enrolment. Proving the second factor ran during this particular sign-in means asserting the OIDC amr claim, which lists the methods that completed, and that assertion runs in strict mode: a login whose token carries amr without an OTP method is refused. Tenant realms are provisioned from a template that emits the claim, so the assertion applies from a tenant's first sign-in.

The posture is fail closed. Sign-in and session refresh ask for the current enrolment status on each attempt, except that after a failed lookup they skip the live check for one minute. If that answer is unavailable, the last good answer is used for up to 15 minutes: a sign-in is admitted only when it shows the user enrolled and the sign-in's own token proves a one-time code was entered (an OTP method in amr), whatever the strict-mode setting; a refresh is admitted when it shows the user enrolled. With no recent answer, the request is denied. A session that could not be verified is left intact so that it recovers when verification does. A refresh revokes a session only when a live answer confirms the user is un-enrolled; the per-request check on sessions that predate the policy works from the cached answer, so it can revoke on that answer too. An empty enrolment answer counts as unverifiable, never as "nobody is enrolled".

The bounds on what enabling MFA reaches

Four limits are worth stating plainly, because a questionnaire answer of "MFA enforced" would paper over them.

A session that predates the policy survives briefly. Each API pod caches the policy snapshot for 30 seconds, so a pre-MFA session can serve requests for up to about 30 seconds after the toggle before the per-request gate stops it. Enrolment status can be up to 60 seconds stale in normal operation, and if the control plane is unreachable that widens to at most 15 minutes, counted from the last good answer, before the fail-closed denial takes over. The same 15-minute window applies to sign-in and refresh while enrolment status is unavailable, so an account whose authenticator was reset inside that window can keep refreshing an existing session for at most 15 minutes. A new sign-in in that window still has to prove a one-time code.

Enabling MFA does not revoke API keys. This is deliberate, and it is a founder decision on record: automation should not break as a side effect of a security toggle. Keys are dated against the policy stamp, and any key created before it carries a Pre-MFA badge on Settings → API Tokens, covering service, admin, readonly, and user tokens alike, since each of them authenticates without passing the login gate. Rotating a flagged key is the administrator's explicit action: mint the replacement, cut the consumer over, then revoke the old one. A tenant that enabled the policy before the stamp existed sees a Pre-MFA? badge for unknown vintage, because the available proxy timestamp dates the policy later than reality and would clear keys that deserve the flag.

The per-login check fails open when the claim is missing. Strict mode refuses a login whose token carries amr without an OTP method. A token carrying no amr claim at all is a different case: there is nothing to assert against, so the login proceeds on the enrolment proof, and the property enforced falls back to the one the other layers carry, that the account signing in is enrolled in TOTP. That fallback does not apply while enrolment status is unavailable: a sign-in admitted on the cached answer needs an OTP method in amr.

Long-lived connections are gated per request. A streaming connection opened before the policy took effect is not cut mid-stream. The next request on that session is gated normally.

The policy governs interactive sign-in to your tenant. API keys authenticate without passing that gate, which is the reason the vintage badge on the token list exists.

Passwords, lockout, and session limits

Where users hold passwords in your realm, the policy requires at least 10 characters with an upper-case letter, a lower-case letter, and a digit, forbids the username as the password, and blocks reuse of the last three.

Repeated failures lock the account. The figures are realm settings applied to every tenant at provisioning:

Sessions carry their own ceilings. A session idles out after 30 minutes and ends after 10 hours whatever the activity on it. Access tokens expire after 5 minutes, and refresh tokens are single use, so each refresh rotates the token and a replayed one is rejected.

The audit log

Security events are written to a log in your own tenant database, readable and exportable at Settings → Audit Log. Access is restricted to superadmins, which holds even for a user carrying broad permissions elsewhere, because the log itself carries login patterns, IP addresses, and permission history.

Each record carries the timestamp, the event type, the acting identity as a user email and display name or as an API key with its name and tier, the source IP address, the user agent, the endpoint and HTTP method, the response status code, and a details object holding context specific to the event.

Filters narrow the view by event type, user, date range, and IP address, and Export CSV streams the filtered set as a file for a SIEM or your own archive. Take that copy if you need history beyond the platform's window: audit records are retained for 90 days and then pruned by the daily retention sweep. Data Handling and Retention sets that figure alongside the other retention windows.

Verify it yourself

Each of these runs in the product, on your own tenant.

• Scoping is observable end to end. Create a team scoped to one source, add a test user to it, and sign in as that user. The configuration item list shows that source and nothing else. Remove the scope and the list empties, which is the deny-by-default model doing its job.
• Key tiers are visible on the key. The prefix is part of the value, and Settings → API Tokens shows the prefix, the expiry date, and the last time each token was used. A Pre-MFA badge appears there when a token predates your MFA policy.
• The audit log records your own actions. Make a change (rename a team, create a token), then open Settings → Audit Log and find the event, with your email and your source IP on it. Export CSV downloads the same rows with the full field set.
• Lockout is testable on an account you own. Fail a login five times on a test account and the sixth attempt is refused for the lockout window, whether or not the password is correct by then. Waiting out the window restores access without administrator involvement.
• Session ceilings are testable by waiting. Leave a session idle past 30 minutes and it requires a fresh sign-in.
• Access-control controls with their own verify pointers are listed in the control matrix. Anything this page leaves open goes to [email protected].