Security overview

1. Architecture in one paragraph

Secret values live in OpenBao (a hard fork of Vault), one namespace per workspace, KV v2 with versioning. Secret metadata and the audit trail live in a managed Postgres (RDS) in a private subnet. The API is a single Go binary running behind Caddy on EC2 in a public subnet, with origin TLS terminated by a Let's Encrypt certificate refreshed via DNS-01 ACME against Cloudflare. The dashboard is a Next.js app on Cloudflare Pages and never holds secret values — it is strictly a thin client of the API.

2. Data at rest

• Secret values: encrypted in OpenBao with AWS KMS auto-unseal. The KMS key is account-scoped and only the OpenBao EC2 instance role can call kms:Decrypt.
• Postgres: AES-256 at rest via RDS encryption. Disk snapshots inherit the same encryption.
• EBS volumes (EC2 root, OpenBao Raft data): encrypted with AWS-managed KMS keys.
• S3 artifacts (Caddy build with cloudflare-dns plugin): SSE-S3 with sha256 verification at boot.
• Backups: 30-day retention on RDS automated backups; encrypted with the same KMS key as the source.

3. Data in transit

• Public traffic: TLS 1.3 to Cloudflare; Cloudflare to the API origin: TLS 1.3 against the Caddy certificate (proxied SSL/TLS Full mode).
• Internal traffic: API ↔ OpenBao stays within the VPC (private subnet, no public IP on OpenBao).
• Outbound from the API EC2 traverses an in-VPC NAT instance with no SSH key, source-dest-check off, and S3 traffic via a gateway endpoint that does not leave AWS's network.

4. Identity and authorization

• Sign-in is delegated to PrysmID via OIDC (issuer secrevo.auth.prysmid.com). We do not own a password database.
• Workspace authorization is decided server-side in the API on every request; the dashboard is an unprivileged client.
• Agents authenticate with bearer tokens prefixed agt_, hashed with SHA-256 at rest, and inherited from the human owner's identity at session-resolution time.
• OpenBao access uses AppRole credentials issued by the API, scoped per workspace; policies use +/... globs to traverse child namespaces only.

5. Audit

Every secret read, secret reveal, agent action, grant change, member transition and access request is recorded in an append-only audit log with: actor identity, target, timestamp, source IP, request ID. Bearer-via-agent calls are tagged with (via agent <id>) so attribution survives delegation. The audit is filterable, paginated, and exportable as CSV from /audit.

6. Operational controls

• CloudWatch alarms covering API error burst, EC2 CPU, EC2 status checks, healthz synthetic via Route 53, and RDS connection saturation. Alarms route to a Make.com webhook subscribed to the secrevo-prod-prod-alerts SNS topic.
• Disaster-recovery runbook covering full account rebuild from snapshot in infrastructure/runbooks/disaster_recovery.md.
• Branch-protected, OIDC-deployed CI/CD: every infrastructure change goes through a tofu-plan + human-merge gate before reaching production.
• Public status page at /status.

7. Software supply chain

• Go modules pinned by checksum; govulncheck runs on every build and blocks known vulnerable dependencies.
• Dependabot is configured for api, dashboard, web, and the GitHub Actions used by them; major bumps go through a manual review gate.
• Caddy build with the cloudflare-dns plugin is published as a tagged release with a sha256 sidecar; the boot fetcher verifies the digest before installing.

8. What we explicitly don't do

• We do not log secret values to application logs, audit messages, error reports, or telemetry. The audit captures who did what, never what value crossed the wire.
• We do not train ML models on Customer Data.
• We do not run a "shadow IT" copy of your secrets in third-party SaaS for analytics, search, or any other reason. The OpenBao instance is the only system of record.

9. Responsible disclosure

If you find a vulnerability, please write to [email protected] with reproduction steps. We acknowledge within 24 hours and aim to triage within five business days. Please do not test against a workspace you do not own; we are happy to provision a sandbox if you need one.

10. Compliance posture

Secrevo is at MVP stage. We have written controls and the technical posture above, but we are not yet SOC 2, ISO 27001, or FedRAMP certified. Customers with a strict compliance requirement should ask for our compensating-controls letter and a signed DPA.