Encryption, access control, audit, and a contact that answers.
Tallywyrmis a 24/7 FinOps agent for multi-cloud spend. This page names what the security posture is built on — eight numbered sections, each anchored in an artifact the audit trail or the contact channel already publishes.
requireAuth() and requireAdmin(), a SHA-256-stamped audit trail, and a security inbox a human reads within one business day.TLS 1.3 outside, mTLS inside, HSTS preload on the surface.
Every byte the agent moves is encrypted on the wire, every time. The four bullets below are the channels the chain covers — external and internal.
- TLS 1.3 on every external connection — the marketing site, the dashboard, the API, and the inventory + recommendation channels the agent uses to read from your cloud.
- mTLS inside the worker fleet — every service-to-service call carries a short-lived workload identity; long-lived static keys are not used.
- HSTS preload on the marketing surface and Strict-Transport-Security on every authed endpoint, so the browser refuses to fall back to plain HTTP.
- Certificate transparency monitoring — any cert issued for one of our names is detected the same hour it appears in the CT logs.
AES-256, KMS-managed keys, per-tenant encryption context.
Storage is encrypted with AES-256, keys live in our KMS, and every tenant is wrapped in its own encryption context so a cross-tenant read is rejected at the KMS layer.
- AES-256 at the storage layer for inventory snapshots, audit events, weekly report payloads and the per-tenant encryption context.
- KMS-managed keys with quarterly rotation, separate key namespaces per region and per environment (prod, staging, dev) so a staging credential cannot decrypt prod inventory.
- Per-tenant encryption context — the audit row for one tenancy is wrapped in a key ring only your workspace can unwrap; cross-tenant reads are rejected by the KMS policy.
- Database backups encrypted at rest, integrity-checked nightly, and retained inside the SOC 2 Type II / ISO 27001 retention window /privacy publishes.
Least privilege, route-gated, brokered credentials.
Authed surfaces are gated with requireAuth(), admin surfaces with requireAdmin(), and the cloud credentials the agent uses are brokered through your OIDC trust — the agent never holds long-lived keys.
- Least privilege — every internal role has the smallest permission set the role needs to ship its slice of the agent; there is no wildcard-admin.
- Authed surfaces gated with requireAuth() at the route layer; admin surfaces gated with requireAdmin() in addition, so a session without the admin claim is rejected before any row is read.
- OIDC-issued, read-only cloud credentials — the credential is brokered, not held; long-lived static keys are not accepted, and the scope cannot be expanded from inside the agent.
- Separation of duties — the role that opens a recommendation PR is not the role that approves it; the role that schedules a stop/start is not the role that edits the inventory scope.
- Privileged access sessions logged in full and reviewed on the weekly audit pass; standing-access reviews on a quarterly cadence.
Every action, hash-stamped, exportable on request.
The same row that backs the verified-savings invoice is the row the auditor receives — with a SHA-256 over canonical-bytes, an X-Bundle-SHA256 response header, and a JSON bundle the auditor can re-hash from the sorted record set.
- Recommendation — the recommendation id, the inventory snapshot it was derived from, the diff summary, the approval state at each review, and the deploy timestamp.
- Pull request — the PR id, the repo it opened against, the merge state, the merge commit SHA, and the post-deploy measurement that certified the saving.
- Credential exchange — the OIDC token exchange, the requested scope, the granting STS response, the expiry, and the actor on whose behalf the exchange was performed.
- Schedule change — the schedule id, the prior state, the new state, the timezone, and the resource classes the schedule covers.
- Admin action — the actor, the change, the rationale, and the approver; surfaced under /dashboard/audit-trail with the same exportable bundle the auditor receives.
AWS for the control plane, US by default, one tenant per workspace, one credential scope per broker.
The cloud provider, the default region and the per-tenant isolation contract — three things a procurement or security reviewer asks about in the first call. The five bullets below name all three.
- Cloud provider — AWS. The Tallywyrm control plane, the audit log and the weekly report archive run on AWS in the regions you select at workspace signup; the sub-processor table on /privacy and the entry at /security-and-compliance#sub-processors name the same party.
- Default region — US (us-east-1, us-west-2). US-region data residency is the default so the SOC 2 / FedRAMP assessor sees the same boundary an agency buyer audits against. An EU region (eu-west-1 / eu-central-1) is available per workspace on request for buyers whose CSRD / GDPR evidence trail needs in-region processing.
- Tenant isolation — every read and write is scoped by `userId` plus `workspaceId`; sessions are tenant-scoped via better-auth (see src/lib/auth.ts and src/lib/require-auth.ts); the cloud credential is brokered through your own OIDC trust, never a shared role, and the scope is the smallest one that produces a useful saving (bring-your-own scope on /privacy).
- Tenant isolation — at the storage layer, the platform-managed per-tenant encryption context wraps the audit row, the inventory snapshot and the weekly report payload; cross-tenant reads are rejected at the data-plane boundary. The /security-and-compliance encryption section names the same posture from the controls side.
- Tenant isolation — at the network layer, the agent reaches your cloud account over TLS 1.3 (section 1) using short-lived OIDC tokens rotated by your IdP; long-lived static keys are not accepted, so a leaked token cannot outlive the rotation window.
Aligned with the frameworks finance and platform teams already audit against.
Same badge row /privacy publishes, now including SEC climate disclosure. The audit trail above is what these frameworks demand.
- SOC 2 Type II
- ISO 27001
- FedRAMP Moderate
- EU CSRD
- SEC climate disclosure
- GDPR
SOC 2 Type II, ISO 27001 and EU CSRD are supported today. FedRAMP Moderate and SEC climate disclosure map onto the same audit trail; the deeper control-to-framework matrix and the SEC Scope 3 category 1 evidence trail live on /security-and-compliance.
Read the deeper matrix →Annual external, quarterly internal, published SLAs.
An external firm runs the annual pentest; the in-house team runs the quarterly pass. Remediation SLAs are below; the executive summary is available under NDA.
- Annual external penetration test by a CREST-accredited firm — scope, methodology and executive summary available to procurement teams under NDA on request.
- Quarterly internal penetration tests against the same scope, run by an in-house team that is independent of the engineering org under test.
- Scope — the marketing site, the dashboard, the API surface (read-only inventory channels, recommendation and PR channels, the contact + email-proxy surfaces) and the IaC delivery channel the agent uses to ship PRs.
- Remediation SLA — critical findings remediated within 24 hours, high within 7 days, medium within 30 days, low on the next release train.
- Re-test on closure — the external firm re-tests critical and high findings on the same cycle the remediation ships, before the SLA timer is closed.
Named on-call rota, public status page, published post-mortems.
Every incident gets a severity, a comms cadence, and (for Sev-1 / Sev-2) a public post-mortem. The status page carries the live list, no sign-in required.
/status. Sev-1 and Sev-2 post-mortems are published within 14 days of resolution.- Named on-call rota — a primary and a secondary on-call engineer, plus an incident commander, on rotation 24/7 with a paging SLA of 5 minutes from page to acknowledge.
- Severity definitions — Sev-1 (active data exposure or agent-borne write against a customer workload), Sev-2 (degradation or partial loss of the daily audit pass), Sev-3 (localised defect), Sev-4 (cosmetic / informational).
- Customer communication cadence — Sev-1: status update within 60 minutes, then every 60 minutes until containment. Sev-2: status update within 4 hours. Sev-3 / Sev-4: bundled into the weekly report.
- Status page — /status carries every Sev-1 and Sev-2 incident from the moment it is declared; RSS + email + webhook delivery, no sign-in required to subscribe.
- Root-cause publication — every Sev-1 and Sev-2 incident gets a public post-mortem within 14 days of resolution; what happened, what we changed, and what we will not change.
A human reads every security message within one business day.
Vulnerability reports, procurement questionnaires under NDA, redlines on the security exhibit, and termination notices all land in the same inbox. Triage starts the same hour — acknowledgement within one business day, escalation if the message names a live exploit.
Looking for the cloud provider, region and tenant-isolation contract? Jump to “How we host your data”.
Read the deeper framework matrix →