Security

Every release passes an automated gate (the full test suite on a throwaway database) before an image is built; a failure stops the release.

• Build specification: the gate runs before the image build
• Release gate script: scripts/run_tests.sh

This page is generated from one reviewed file; a test fails the release if any 'In place' line has no evidence or its evidence no longer holds.

• Test: tests/test_security_claims.py::test_every_in_place_claim_resolves

A written risk register, published.

A written access policy. The service has a single operator; production access is limited to the owner.

Operator sessions expire after 12 hours, and administrative actions need a sign-in within the last 15 minutes.

• Test: tests/test_e2e_matrix.py::C_Roles::test_admin_action_needs_fresh_sign_in
• Test: tests/test_security_claims.py::test_operator_session_expires_after_12_hours
• Code: app/auth.py operator session lifetime

Staff security training and background-screening programme (there are no employees besides the operator).

Automated database backups are kept for 14 days.

• Infrastructure template: database cluster BackupRetentionPeriod: 14
• Live check after each deploy: database backup retention is at least 14 days

If the database is ever removed, a final snapshot is taken first.

• Infrastructure template: database cluster DeletionPolicy: Snapshot

Application logs are kept for 90 days.

• Infrastructure template: application log group RetentionInDays: 90

A public status page shows live figures only; no uptime percentage is claimed until uptime is measured.

• Code: app/status.py (status page source)
• Test: tests/test_e2e_matrix.py::A_RouteMatrix::test_matrix

Daily database copies to a separate backup vault: stated here once a completed copy has been verified on the live service.

Operational alarms that notify the operator: stated here once verified on the live service.

Measured uptime history on the status page.

A restore drill from backup, with its date and result published.

A copy of backups in a second region, and a standby database in a second zone.

The managed cloud database is encrypted at rest with a customer-managed key.

• Infrastructure template: database cluster StorageEncrypted: true, with the customer-managed key
• Live check after each deploy: database storage encryption is on

Stored files are encrypted at rest with the same customer-managed key, versioned, and closed to public access.

• Infrastructure template: application file store encrypted with the managed key
• Infrastructure template: application file store versioning enabled
• Infrastructure template: application file store public access blocked

The data encryption key rotates automatically every year.

• Infrastructure template: data key EnableKeyRotation: true

All traffic is served over HTTPS; plain HTTP is redirected.

• Live check after each deploy: the public load balancer has an HTTPS listener with a certificate
• Live check after each deploy: plain HTTP is redirected to HTTPS

Verified against the live service on 24 September 2026.

Minimum TLS version: TLS 1.2.

• Live check after each deploy: minimum TLS version read from the listener security policy

Verified against the live service on 24 September 2026.

Browsers are told to use HTTPS only for this site (HSTS, 180 days).

• Test: tests/test_security_claims.py::test_security_headers_are_sent

Passwords are stored only as salted bcrypt hashes.

• Test: tests/test_security_claims.py::test_passwords_are_stored_as_bcrypt_hashes

API keys are shown once and stored only as hashes; expired and revoked keys are refused.

• Test: tests/test_s9_apikeys.py::S9::test_01_key_shown_once_and_only_hash_stored
• Test: tests/test_e2e_matrix.py::I_ApiKeys::test_no_plaintext_key_is_stored
• Test: tests/test_s9_apikeys.py::S9::test_02_expired_and_revoked_keys_get_401_others_keep_working

Database and session secrets are generated into a managed secrets store and injected at start-up, never kept in code.

• Infrastructure template: database secret generated (32 characters)
• Infrastructure template: session secret generated (48 characters)

Accounts and stored data are held in UK data centres in London. The one exception is Check the news: the claims it checks (never your name or account details) are sent as search queries to a processor that may handle them outside the UK, as the privacy notice explains.

• Deploy script: London region
• Privacy notice: the search-query exception
• Live check after each deploy: the service stack runs in the London region

Workspaces are isolated: one customer cannot read another's saved answers, maps, chats or keys.

• Test: tests/test_e2e_matrix.py::C_Roles::test_tenants_cannot_read_each_other
• Test: tests/test_s9_chats.py::S9Chats::test_04_other_tenant_cannot_read
• Test: tests/test_s9_apikeys.py::S9::test_04_cross_tenant_isolation

Chat history is private to the person who wrote it, even inside a team.

• Test: tests/test_s9_chats.py::S9Chats::test_03_same_tenant_other_person_cannot_read

Erasing an account blanks its chats and revokes every API key.

• Test: tests/test_s9_chats.py::S9Chats::test_09_erasure_blanks_chats
• Test: tests/test_s9_apikeys.py::S9::test_07_erasure_revokes_every_key

You can export your own chats; an export never includes anyone else's.

• Test: tests/test_s10l_docs.py::S10LDocs::test_03_chat_export_only_own_chats

Retention periods set per workspace, with every deletion recorded.

A data processing agreement you can sign online.

One password rule everywhere (NIST SP 800-63B): at least 15 characters, and common, guessable or breached passwords refused - at sign-up, reset, invitation and change.

• Test: tests/test_e2e_matrix.py::D_Abuse::test_one_password_rule_everywhere

Repeated failed sign-ins lock the account for that address (5 in 5 minutes), and 10 across all addresses.

• Test: tests/test_security_claims.py::test_repeated_failed_sign_ins_lock_out

Session cookies are signed, HttpOnly and SameSite=Lax; a tampered cookie is refused.

• Test: tests/test_security_claims.py::test_session_cookie_is_signed_and_tamper_refused
• Test: tests/test_security_claims.py::test_session_cookie_flags

Session cookies are sent over HTTPS only (Secure flag).

• Live check after each deploy: the running service marks session cookies Secure

Verified against the live service on 24 September 2026.

Per-form anti-forgery tokens. Cross-site form posts are currently limited by SameSite=Lax session cookies only.

Every route has an access rule, and the gate tries every route as every kind of user; a team seat can never become a platform administrator.

• Test: tests/test_e2e_matrix.py::A_RouteMatrix::test_every_route_has_an_access_rule
• Test: tests/test_e2e_matrix.py::C_Roles::test_team_seat_can_never_become_a_platform_admin

Rate limits on the support assistant (not bypassable with forged addresses), password resets and chat writes.

• Test: tests/test_e2e_matrix.py::D_Abuse::test_support_bot_rate_limit_cannot_be_dodged_with_forged_ips
• Test: tests/test_reset_r71.py::ResetTests::test_rate_limit
• Test: tests/test_s9_chats.py::S9Chats::test_07_writes_are_rate_limited

Every answer carries a reference that anyone can look up at /audit; a past record that was altered is detected.

• Test before every release: stored answer records are complete and intact
• Test before every release: a reference can be looked up and an altered record is detected
• Test before every release: every answer is stamped with a reference and kept on record
• Test before every release: an altered record can never be passed off as intact

Answer records are kept securely as a permanent record for at least 7 years.

• Infrastructure template: the answer-records store keeps every record for the stated period
• Live check after each deploy: the answer-records store keeps every record for the stated period

Verified against the live service on 24 September 2026.

A workspace's owner and managers can prove that any one of its answers is in the permanent record, without revealing any other customer's records.

• Test before every release: each answer can be proven to be on record, revealing nothing else
• Test before every release: a proof for an altered record always fails

An API key can be exchanged for a 15-minute access token, so the key itself can stay in a vault; a token cannot mint another and stops working when it expires or its key is revoked.

• Test: tests/test_s27_proofs.py::AccessTokens::test_mint_use_expire_revoke

Security headers on every response: no content sniffing, strict referrer policy, framing limited to this site.

• Test: tests/test_security_claims.py::test_security_headers_are_sent

The service refuses brokerage or exchange credentials in any request.

• Test: tests/test_s10m_watchlists.py::S10M::test_12_body_carrying_an_exchange_key_is_refused_400

The application runs as an unprivileged user inside its container.

• Container build file: USER monarch

Every release scans the pinned dependencies for known vulnerabilities; a known critical vulnerability blocks the release, and lower severities are reported in the release evidence.

• Release gate: dependency scan step
• Test: tests/test_security_claims.py::test_critical_vulnerability_blocks

Responsible disclosure address (/.well-known/security.txt): being set up.

Independent penetration test. Annual independent testing is planned; this line changes only when its summary is published.

A managed firewall sits in front of the service: a common-attack rule set and per-address rate limits block traffic, with a tighter limit on sign-in and checkout.

• Infrastructure template: managed firewall attached to the load balancer
• Infrastructure template: sign-in and checkout rate limit (100 per address per 5 minutes)
• Live check after each deploy: the managed firewall is attached, with blocking rules

Blocking of known-bad input patterns at the firewall: stated here once verified on the live service.

The database sits in private subnets and accepts connections only from the application.

• Infrastructure template: database subnet group uses the private subnets only
• Infrastructure template: database accepts port 5432 from the application only

Application servers accept traffic only from the load balancer.

• Infrastructure template: application accepts traffic from the load balancer only

Card details are entered on the payment provider's hosted checkout and never reach our servers.

• Code: app/payments.py hosted checkout session

Suppliers are described by category on public pages; a test fails the release if any public page names one.

• Test: tests/test_e2e_matrix.py::D_Abuse::test_no_supplier_is_ever_named_to_a_customer

A named sub-processor schedule, released to customers under a signed data processing agreement.

Formal security reviews of each supplier.

Cyber Essentials certification (IASME) for the whole organisation, renewed every year; the certificate can be checked on the certification body's public register.

• Code: app/trustmarks.py certificate record

Registered with the Information Commissioner's Office (ICO) as a data controller.

• Code: app/trustmarks.py registration record

Cyber Essentials Plus (independently tested) certification.

SOC 2 report.

ISO/IEC 27001 certification.

Uptime service-level agreement (SLA).

Paid bug bounty programme.

HIPAA compliance. Do not use the service for US protected health information.