Infrastructure security controls

How the Delegus service is hosted and what that hosting enforces, as of the move off AWS on 4 November 2026. This is the companion to docs/threat-model-mapping.md: that document maps spec threats to protocol and service controls; this one states the controls that live in the hosting, the key store and the evidence store. The configuration is Terraform in infra/gcp and infra/vendors.

Where it runs#

• The API runs on Render in Virginia, two instances in production, from a container image.
• Postgres is Neon and Redis is Upstash, both in us-east-1; those providers run on AWS infrastructure. Evidence is Backblaze B2 in us-east-005. Signing keys are Google Cloud KMS in us-east4. Everything is in the US.
• Postgres has Neon's point-in-time restore over the last seven days. Longer database backups to locked storage are planned.
• DNS is Cloudflare, with our records set to DNS only. Render's own edge network runs on Cloudflare, so API traffic passes through Cloudflare as part of Render's service.

Signing keys#

• Receipt and status-list signing keys are Ed25519 keys in Google Cloud KMS (EC_SIGN_ED25519), at the software protection level. Cloud KMS keys can't be exported. The API asks KMS to sign each receipt and status list; private key material never enters the API process.
• The API signs in to Google through workload identity federation: short-lived credentials from the hosting provider, and no stored cloud key.
• The production service account may sign, verify and read public keys on the production signing keys, and nothing else. It holds no permission to destroy a key. Every key is created with a 120-day destroy schedule, so a destroy request can be undone for 120 days, and the signing keys are also protected from deletion in Terraform. An organization-wide policy that denies key destruction is planned.
• Keys are addressed by purpose and generation (receipt-1, receipt-2, status-1, status-2). Rotation adds a generation. Retired generations stay published in the DID document so every receipt ever issued keeps verifying. Nothing removes a key from the document.
• Production now signs with receipt-2 and status-2. The earlier receipt-1 and status-1 were AWS KMS keys; they are retired and no longer used for signing, and their public halves stay published.
• Development keys belong to did:web:dev.delegus.ai and production keys to did:web:delegus.ai; the two sets never meet. The development document isn't served while the development service is offline.
• Company keys Delegus holds (passkey approval): when a company chooses to let Delegus hold its signing key, the API creates one Ed25519 key for that identity in a separate production key ring in Google Cloud KMS. The private key never leaves KMS. The API asks KMS to sign only after it has verified a passkey approval over the exact bytes of the grant; no API key, console session or staff action can make it sign. The service account can create and use keys in that ring but can't destroy them, and each has the same 120-day destroy schedule. If the company moves to its own key, Delegus's key stops signing but stays published, so the grants it signed keep verifying.

Evidence store#

• One private B2 bucket per environment with Object Lock. Production uses COMPLIANCE mode with a seven-year default retention, which no one can shorten once an object is written. Objects are encrypted at rest by B2.
• The API writes objects addressed by SHA-256 over TLS and never deletes.
• The default retention runs from an object's first write, but a later receipt can reference an object first stored long before (a DID document, a profile, a trust configuration). A daily job in the API extends the retention of every object a receipt references to at least seven years after the end of that receipt's UTC day. It only ever moves a date later.
• Evidence written before the move on 4 November 2026 was copied to the production bucket under the same lock, and each object was checked by its SHA-256 hash before and after the copy.

Network and edge#

• Callers reach the API over TLS, with certificates issued by Render.
• The API connects to Postgres over TLS and verifies the server certificate, and to Redis over TLS.
• The API enforces its own rate limits per key and per IP and answers 429 with Retry-After. There is no web application firewall in front of it today; one is planned.

Secrets and deployments#

• Service secrets (the admin token, the provisioning key, the database and cache URLs and the evidence-store key) are environment variables on Render, set by Terraform. That Terraform state is held on one operator machine, outside the repository. The API is designed to log a secret's name and fingerprint, never its value. Rotating the admin token and the provisioning key is planned.
• Images are built by GitHub Actions on each push to the main branch and pushed to GitHub Container Registry; Render pulls them with a read-only registry credential. Building an image doesn't deploy it. A production release happens only when the reviewed Terraform names a new image, or by a deliberate manual deploy.
• Each release must pass a health check on /healthz before it takes traffic; a release that fails it never serves a request. Under Render's deploy model the previous release keeps serving.

Logging and monitoring#

• Google Cloud's admin activity audit logs record every administrative change to the key project, such as creating a key or changing who may use it. Per-signature access logs are not enabled.
• The API keeps its own append-only audit log (GET /audit), and every receipt is a signed record of its decision.
• Production and development are monitored from outside, with results on the public status page. Alerts on error rates and on tampering with keys or evidence are planned.

Separation of environments#

• Development and production are separate Render services, Neon projects, Upstash databases and B2 buckets with their own keys.
• Signing keys share one Google Cloud project but sit in separate key rings, and each environment has its own service account that can reach only its own keys.

What is deliberately not in place yet#

• No Terraform apply from CI: applies run from an operator workstation after a plan is read.
• An organization-wide deny on key destruction, a web application firewall, error and tamper alerting, and rotation of the carried-over admin token and provisioning key are planned.
• Single region.