Security and Data

This page is written for the people who have to sign off on Bitment before it touches client data: an IT director, a firm owner, or whoever owns the vendor-risk conversation. It describes the infrastructure your firm runs on, how access is controlled inside the product, and where your data and your AI usage actually go.

Where to find it

There's nothing to click here; this describes the platform underneath the product. Ask your Bitment contact for specifics on your firm's own stack (region, instance sizing, and so on) if you need them for a security review.

Key concepts

Stack: the complete, dedicated set of cloud infrastructure that runs your firm's copy of Bitment.
Role: the baseline permission level assigned to a team member (owner, admin, partner, manager, staff, limited, or a custom set).
Resource grant: a narrower permission that scopes a team member's access to specific clients, books, or projects instead of everything of that kind.
Proposal: the pattern every AI action follows: the AI stages a change, a person reviews and approves it, and only then does it take effect.
BYO credential: an AI provider credential (an API key, or a set of cloud credentials) that your firm supplies and owns, rather than one Bitment supplies on your behalf.

One dedicated stack per firm

Every paying firm gets its own, dedicated, network-isolated set of infrastructure on AWS, not a shared multi-tenant database with row-level separation. Concretely, each firm's stack includes:

Its own virtual private cloud (VPC), with public and private subnets.
A private application server with no public IP address. The app itself is not reachable from the internet directly.
An internet-facing load balancer that is locked down to accept traffic only from CloudFront, the content-delivery layer in front of it, so the load balancer can't be reached by going around the CDN.
A web application firewall (WAF) at the CloudFront edge, running a common attack rule set, an IP-reputation list, and per-IP rate limiting.
A NAT gateway for the app's own outbound traffic, giving it a stable, allowlist-able egress IP address.
A private PostgreSQL database (RDS), not reachable from the public internet, reachable only from the app server itself.
Application secrets stored in AWS Secrets Manager, scoped so the app server can read only its own firm's secrets, never another firm's.

There is no public-subnet fallback and nothing shared between firms at the infrastructure layer. The only stack not tied to a single firm is one Bitment uses for its own internal testing; it holds no customer data.

No shell access except through AWS Systems Manager

The application server accepts no inbound SSH. There is no open port 22, and no IP allowlist for SSH, because there's no SSH listener to allowlist in the first place. Any shell access or deployment runs through AWS Systems Manager (SSM) Session Manager, a tunnel that goes through AWS's own control plane rather than opening a port on the host. This is the only way in, for engineers and automated deployment alike.

Encryption in transit and at rest

TLS is terminated at CloudFront for every request reaching your firm's stack, and the in-VPC hop from the load balancer to the app server stays encrypted as well.
Both the database and the data volume the application uses are encrypted at rest.
Session cookies are host-scoped to your firm's own domain, not shared across firms.

Every request is authenticated and re-checked

Every request against the backend runs through an authentication check before any handler executes: the session cookie is validated, and the request is rejected before any application logic runs if it doesn't check out. There is no request that skips this gate to reach your data.

Permissions: roles, resource grants, and AI approvals

Access inside a firm is controlled at three levels:

Roles. Each team member holds one of seven baseline roles: owner, admin, partner, manager, staff, limited, or a custom set of permissions. The role sets the default answer to "can this person do X."
Per-member overrides and resource grants. A role's defaults can be overridden per person, and access can be further narrowed to a specific set of clients, books, or projects rather than everything of that kind, for a team member who should only see part of the firm's client list.
Per-entity sharing. Individual items (a document, a project, and so on) can be shared at owner, edit, or view level, layered on top of the role and resource-grant model.

AI actions never bypass this model, and never write directly. Every action the AI can take that changes something is staged as a proposal: a concrete, reviewable, specific change that a person approves before it takes effect. There is deliberately no "approve" tool available to the AI itself; approval is a human action, always. Read-only questions the AI answers directly still respect the same access rules a person would hit using the product themselves.

Audit and logging

SOC 2 audit in progress. Bitment is being audited against the AICPA Trust Services Criteria, and the report will be available to your firm on request once issued. Day to day, the platform records:

Every request that produces a server error is enriched with a trace so an incident can be correlated across the request that triggered it.
Network flow logs for the whole environment are retained for 30 days.
Direct database questions the AI answers (for reporting or analysis) run through a read-only, privilege-limited database role inside a read-only transaction, with every such query recorded in its own audit trail. That path can never write.

Bring your own AI provider

Your firm chooses and supplies its own AI provider credentials: an API key for Anthropic, a set of cloud credentials for AWS Bedrock, an API key for OpenRouter, or a base URL and token for a self-hosted Ollama instance your firm runs itself. Bitment does not supply a shared, Bitment-owned AI credential that every firm's usage flows through. Practically, this means:

Client data sent to an AI model goes to the provider your firm selected, under that provider's own data-handling terms, not a Bitment-operated one.
Choosing self-hosted Ollama keeps AI inference on infrastructure you control, if that's what your data-residency posture requires.
Every AI call is priced and recorded against your firm's own usage ledger, regardless of which provider you've connected.

Backups

The database runs with point-in-time recovery, covering the last 7 days.
The application's data volume is snapshotted daily, with 14 days of retention.
Tearing down a stack keeps a final snapshot of both as the recovery path.

Desktop app signing

The Mac and Windows desktop apps are code-signed and notarized before release, so they install without a Gatekeeper warning. Each firm's white-labeled desktop app is signed the same way; the signing identity belongs to Bitment as the developer, not to any individual firm.