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 anything further you need for a security review.

Key concepts

Platform: the single production environment on AWS that runs Bitment for every firm.
Firm: your tenant on the platform. Every record belongs to a firm, and access to it is decided by membership in that firm.
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 platform, with each firm's data kept separate

Bitment runs on one production platform on AWS, in the us-east-1 region. Firms share its infrastructure. They do not share data: every record belongs to a firm, and the application checks every request against the person's membership and permissions in that firm before it reads or changes anything (see "Permissions" below). Until September 2026 each firm ran on its own separate copy of this design; every firm has since been moved onto the platform.

The platform includes:

A 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, and running across two availability zones with automatic failover.
Application secrets stored in AWS Secrets Manager, not in configuration files. Sensitive credentials a firm connects are encrypted with keys scoped to that firm or to the individual who connected them.

There is no public-subnet fallback: the app server and the database are never placed where the internet can reach them.

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 the platform, 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 the application's own domain.

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 14 days.
The application's data volume is snapshotted daily, with 14 days of retention.

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.