🛡 Security

Security Architecture

A technical security whitepaper covering the design decisions, threat model, and defense-in-depth strategy behind Agent Secret Store.

Last updated: January 2025 · Version 1.1

Defense in depth

No single security control is foolproof. Agent Secret Store is designed so that an attacker must defeat multiple independent layers simultaneously to access secret material.

Network perimeter

›Cloudflare DDoS protection and WAF on all endpoints
›TLS 1.3 mandatory for all API and MCP connections
›Certificate transparency monitoring
›IP allowlisting support on scoped tokens

Authentication & authorization

›All requests require a valid agent key or scoped token
›Scoped tokens enforce least-privilege path restrictions
›Token TTL limits the window of exposure
›IP allowlisting on tokens provides host-binding
›Single-use tokens for one-time operations

Human-in-the-loop approvals

›Sensitive secrets require at least one human approval
›Critical secrets require two approvals + time delay
›Approval decisions are logged in the audit trail
›MoltbotDen Trust Tier integration for agent-aware policies

Encryption at rest

›Envelope encryption: per-secret DEK wrapped by per-tenant KEK
›AES-256-GCM for all encryption operations
›KEKs live exclusively in GCP KMS (FIPS 140-2 Level 3 HSM)
›Tenant cryptographic isolation — one KEK per tenant
›90-day automatic KEK rotation

Database security

›Cloud SQL PostgreSQL 16 with private networking
›Database password hashed with bcrypt (cost 12) + secret pepper
›Row-level security with enforced tenant_id scoping
›Database audit logging via pgaudit
›Automatic backups with 30-day retention

Audit & observability

›Every read, write, and token issuance is logged
›Audit events are immutable (append-only log table)
›Real-time alerting on anomalous access patterns
›Audit export for compliance evidence (CSV, JSON)
›GCP Cloud Audit Logs for all KMS operations

Encryption stack

Transport

TLS 1.3 (ECDHE-AES-256-GCM)

Secret encryption

AES-256-GCM (per-secret DEK)

Key wrapping

GCP KMS AES-256 (per-tenant KEK)

HSM standard

FIPS 140-2 Level 3

Password hashing

bcrypt cost=12 + secret pepper

Token signing

HMAC-SHA256 (opaque bearer)

GCP KMS key hierarchy

GCP KMS RESOURCE HIERARCHY

projects/agent-secret-store-prod/
  locations/us/
    keyRings/tenant-keys/
      cryptoKeys/
        tenant-{tenant_id_1}/           ← KEK for tenant 1
          cryptoKeyVersions/1            ← active
          cryptoKeyVersions/2            ← previous (rotation)
        tenant-{tenant_id_2}/           ← KEK for tenant 2
        tenant-{tenant_id_3}/           ← KEK for tenant 3
        ...                             ← one key per tenant

Purpose: ENCRYPT_DECRYPT (symmetric)

Algorithm: AES-256-GCM

Protection: HSM (FIPS 140-2 Level 3)

Rotation: 90-day automatic rotation policy

IAM principal: agent-secret-store@{project}.iam.gserviceaccount.com

IAM role: roles/cloudkms.cryptoKeyEncrypterDecrypter (per-key)

Tenant isolation is enforced at the IAM level — the service account used for encryption can only access keys in its own tenant key, enforced by KMS resource-level IAM policies. A bug in multi-tenant routing cannot cross cryptographic boundaries.

Threat model

Threat	Impact	Mitigation	Residual Risk
Database breach	High	Envelope encryption — ciphertext useless without KMS access	Low — metadata exposed, no secret values
Compromised agent key	High	Rotate key immediately; audit log reveals what was accessed	Medium — secrets accessible until rotation completes
Compromised scoped token	Medium	Scope limits, TTL limits, IP allowlisting, max_uses	Low — bounded by scope, expires automatically
Insider threat (our engineers)	High	Engineers cannot access KMS keys; all access logged; zero-knowledge architecture	Low — KMS HSM boundary prevents key extraction
GCP KMS compromise	Critical	FIPS 140-2 L3 HSM; GCP's own security posture; KMS audit logs	Very Low — nation-state level attacker required
Supply chain attack (SDK)	High	SDK pinned deps; npm provenance; SBOM; reproducible builds	Low — signatures verified at install time
Rogue agent accessing wrong secrets	Medium	Scoped tokens, namespace isolation, approval workflows	Low — scope violations rejected server-side
Denial of service	Medium	Cloudflare DDoS; rate limiting; Cloud Run autoscaling	Low — availability impact only, no secret exposure

Access control model

Agent Secret Store uses a three-layer access control model:

1. Tenant isolation

Every database query is scoped by tenant_id. Row-level security (RLS) policies enforce this at the PostgreSQL level — a bug in application routing cannot expose cross-tenant data because RLS blocks it at the database boundary.

2. Scope enforcement

Scoped tokens carry a permission scope (e.g. secrets:read:production/openai/*) that is validated server-side on every request. The token cannot be used to access paths outside its scope, regardless of what the client claims.

3. Approval gates

Sensitive and critical secrets have a human approval gate on token issuance. Even a valid master key cannot bypass this — the approval must come from a separate human actor authenticated through the dashboard.

Audit trail design

Every operation that touches a secret produces an immutable audit event:

Secret ops

secret.read

secret.write

secret.delete

Token lifecycle

token.issued

token.expired

token.revoked

Approvals

approval.requested

approval.approved

approval.denied

•Audit events are written to an append-only log table with a PostgreSQL trigger that prevents UPDATE and DELETE operations.

•Events include: actor (key/token ID), IP address, user agent, path accessed, success/failure, timestamp (microsecond precision).

•GCP Cloud Audit Logs capture all KMS wrap/unwrap operations independently of our application logs.

•Export audit events via the REST API for ingestion into your SIEM (Splunk, Datadog, etc.).

Compliance roadmap

SOC 2 Type II

In progress

ETA: Q3 2025

Security, availability, and confidentiality trust service criteria.

ISO 27001

Planned

ETA: Q4 2025

Information security management system certification.

FedRAMP Moderate

Roadmap

ETA: 2026

Required for federal agency deployments. Aligned with VETS GWAC.

Security inquiries

To report a security vulnerability, email security@agentsecretstore.com. We follow responsible disclosure and will respond within 24 hours. For enterprise security reviews, contact enterprise@agentsecretstore.com.

Encryption Architecture →

Technical deep dive into envelope encryption and KMS.

Best Practices →

Operational security best practices for production deployments.