Security at SystemDox

SystemDox runs on managed AWS services in eu-west-2 (London). Your documents, specs, decision records, and checks are stored in DynamoDB tables encrypted with customer-managed KMS keys that have automatic key rotation enabled, with point-in-time recovery on.

Object storage is private: every bucket blocks public access, uploaded media is encrypted with the same customer-managed key, and the media bucket rejects any request that is not over TLS. Published documentation sites are served only through CloudFront, using AWS-managed S3 encryption rather than a customer-managed key.

Traffic is HTTPS-only with a TLS 1.2 minimum. API responses carry HSTS, nosniff, and frame-deny headers; the web applications add a content security policy at the edge.

Two honest exceptions to "everything is in London". TLS certificates for our CDN are issued in us-east-1 because CloudFront requires it — no customer data is involved. And access control for private documentation portals runs as an edge function in CloudFront's global network: it reads a marker file to decide whether a portal requires login and compares your session's workspace to the subdomain. It sees request and session metadata at the edge; document content is not processed there.

This is the disclosure most vendors bury, so we are putting it first among equals: when you use a SystemDox feature that generates or analyses content with AI, that content is sent to Anthropic's API, which is outside our eu-west-2 boundary.

Concretely, that includes the text of documents and specs you ask AI to draft, review, or analyse — and, in agent workflows that operate on a connected repository, source code read from that repository. Storage stays in London; AI inference does not. If your policy forbids sending source or documentation to a US-based model provider, this is the constraint to raise with us before you connect a repository.

Search embeddings are the exception that stays home: when document search indexing is enabled, embeddings are generated through AWS Bedrock in eu-west-2, inside our own account. Voice capture is transcribed by AWS Transcribe in eu-west-2, streamed from your browser directly to AWS.

The complete list of third parties that process data on our behalf. "Customer content" means your documents, specs, or source code — as opposed to identity and diagnostic metadata.

We do not process payments, and we run no analytics, advertising, or session-replay trackers on this site or in the application.

Every record is partitioned by workspace, and the workspace identity used to build that partition key comes only from the verified authorizer that runs before any handler — never from a value the caller can supply. A request cannot ask for another workspace's data by changing a parameter.

Authorization fails closed by design: an unrecognised role is treated as the least privileged, an unknown or archived space grants nothing, and a database error while checking permissions raises rather than falling through to allow. Requests for records belonging to another workspace return "not found" rather than "forbidden", so existence itself is not disclosed.

Denied access attempts are recorded as audit events and metrics.

The API keys your agents use are hashed with Argon2id before storage. We keep the hash and the last four characters; the key itself is never persisted, so it cannot be recovered from our database — or shown to you again after creation.

Each key is bound to one workspace, carries an explicit read or read-write mode, and can be limited to specific spaces — and a key can never be granted more access than the person who created it holds. Keys never carry administrative privileges: no key can change billing, membership, or workspace settings. Newly issued keys carry an expiry, and any key can be revoked immediately.

Sign-in supports multi-factor authentication, and the key prefix (pweb_) is deliberately recognisable so secret scanners catch a key committed by mistake.

SystemDox connects as a GitHub App you install and can uninstall at any time. We hold no long-lived password: access uses short-lived installation tokens, minted from a signing key held in AWS Secrets Manager and cached for under an hour.

SystemDox writes to your repositories, not just reads them — that is the product working as designed, since git is the source of truth for your documentation. With your action it commits documentation and decision records, opens branches and pull requests, and creates issues from planning items. It does not push to your default branch without an explicit publish action, and publishing is never automatic.

The exact permission set is shown by GitHub on the installation screen before you approve it — read it there rather than taking our summary for it.

Documentation often contains what it should not: a key pasted into a runbook, a customer name in an example, an internal hostname. Every publish is scanned for credentials, personal data, and internal infrastructure references, with sensitive values replaced by redaction chips backed by an encrypted vault — and the findings tell you what to rotate. See the sanitized publishing guide.

Published portals are private to your workspace by default. Making one public is an explicit administrative action.

Unpublishing a documentation site removes the published files, purges its search embeddings, and invalidates the CDN cache. Archiving a document deletes the images it holds in our storage. Audio staged for transcription expires automatically after 30 days.

One consequence worth understanding: because publishing writes into your own git repository, anything already committed there lives in your repository's history and is yours to remove. Deleting it on our side does not rewrite your git history.

Account closure and full erasure requests are handled by our team on request — email privacy@systemdox.com and we will confirm what was removed. There is no self-service "delete my workspace" button today; we would rather say so than imply one exists. Full detail is in the retention policy and privacy policy.

If you believe you have found a security issue, email security@systemdox.com with enough detail to reproduce it. We will acknowledge within two working days, keep you updated while we investigate, and credit you if you would like us to. Please give us a reasonable window to fix the issue before disclosing it publicly, and do not run tests that degrade the service or touch other customers' data.