Access, MFA and an audit trail you can review

When you are signed in, every request uses the workspace in your signed session. A different workspace in the web address or a request header does not change it, and database reads are scoped to your workspace.

Inside a workspace, four roles set what people can do: owner, admin, member and viewer. Deleting the workspace, changing roles, creating API tokens and exporting the workspace’s records are owner-only.

GetFinOps staff have no standing access to customer workspaces. A named operator must create a grant for one workspace, lasting 30 minutes by default and two hours at most, and creating or revoking it is recorded in the audit trail.

Passwords are hashed with Argon2id. Session cookies are HttpOnly, Secure and SameSite=Lax, and sign-in attempts are rate-limited per IP address. A token issued partway through sign-in, before the second factor, cannot be used as a session.

Whether MFA is required is set for the installation. It can be phased in by workspace, role and start date, and new users can be required to enrol before their first session. It comes in two forms:

• An authenticator app (TOTP). The secret is stored encrypted, a code cannot be used twice, and each challenge allows five attempts. Ten recovery codes are shown once and stored only as salted hashes.
• Auth0, which a workspace admin can choose for new enrolments where the installation offers it; it can require a paid plan and a separate add-on. People already enrolled keep the factor they have.

For AWS, you create an IAM role that trusts GetFinOps and requires your workspace’s External ID, and GetFinOps assumes it for temporary credentials. No AWS access keys are stored. The role is read-only unless you turn on EnableRemediation, which adds a short list of write permissions.

GetFinOps encrypts these stored credentials with AES-256-GCM before they reach the database: Google Cloud service-account keys, the Slack bot token and authenticator-app secrets. API tokens are stored only as SHA-256 hashes, carry a read or write scope, and can expire. On the hosted service, the database is encrypted at rest and is not reachable from the internet.

GetFinOps records sign-ins and failed sign-ins, MFA enrolment and verification, approvals and denials, executions and rollbacks, configuration changes, data exports, Slack connections and support-access grants. In the app you can filter recent entries by event type and person, and open the full trail for a single execution. The API also filters by action, resource and date.

Each entry stores a SHA-256-based checksum over its entry ID, event type, workspace, run ID, actor, time and details when it is written, so an edit to those fields no longer matches. When personal details are removed, the checksum is recomputed and the original kept, so a lawful redaction can be told apart from tampering.

Narratives, the daily brief, board chat and the in-app assistant use Anthropic’s models. Before a prompt is sent, identifiers in known formats are replaced with placeholders: AWS ARNs and account IDs; EC2 instance, volume, snapshot and security-group IDs; and Google Cloud resource paths, service-account addresses and project numbers.

This is pattern-based, plus an exact match on your workspace ID and each connected account’s number or project ID. It covers the report and audience narratives, including budget names, daily briefs on every plan, board chat, the in-app assistant, the brief on your first scan, and report narratives sent back as context. The onboarding assistant sends your company name and account label as stored, and the cross-account analysis checks an account’s label only against that account’s own identifiers. Resource names, tags, labels and anything you type are sent unchanged. Privacy Policy §7 lists what is sent.

Any signed-in user can download their own data. The workspace owner can download the workspace’s records, including members, the audit trail and cloud-account settings. Both come as JSON, or as CSV one table at a time, and every export is recorded.

The owner can delete the workspace. It is suspended first and can be restored during the recovery window, 14 days by default. After that, a purge job cancels the subscription, removes the workspace’s people from any external MFA provider, and erases the workspace’s data. The audit trail is kept with personal details removed, along with a record that the erasure happened.

• The audit checksum is not a signature: someone with database access could recompute it.
• MFA is not required for every user by default.
• Identifier replacement is not anonymisation.
• There is no SAML single sign-on; sign-in is email and password.
• Deleting a workspace does not remove copies in encrypted backups until those backups expire.