Security architecture that scales
with your agents
Built for teams that need to prove their AI agents are secure. This page covers how 1Claw encrypts secrets, isolates keys, validates intents, and produces tamper-evident audit trails.
Envelope encryption with HSM root of trust
Three-layer key hierarchy. The root key never leaves the HSM. Each vault and each secret version has its own encryption key. Optional MPC splits DEKs across multiple HSMs.
Google Cloud KMS (HSM-backed)
FIPS 140-2 Level 3 hardware security modules. The root key never leaves Google's HSM boundary. All key operations are audited in Cloud Audit Logs.
Key Encryption Key (KEK)
Each vault gets its own AES-256-GCM KEK, wrapped by the Cloud KMS root key. Compromising one vault's KEK does not expose other vaults.
Data Encryption Key (DEK)
Each secret version is encrypted with a unique DEK. The DEK is wrapped by the vault's KEK and stored alongside the ciphertext. Rotation is per-secret, not per-vault.
Optional: Customer-Managed Encryption Keys (CMEK)
Business and Enterprise tiers can add a client-side AES-256-GCM layer on top of envelope encryption. The customer's key never touches our servers — only a SHA-256 fingerprint is stored. Server-assisted rotation re-wraps secrets in batches of 100 without downtime.
Learn more: CMEK setup, rotation, and SDKMPC key splitting
Eliminate single points of compromise by splitting encryption keys across multiple cloud HSMs and your own infrastructure. Three custody models, configurable per vault.
2-of-2 Client Custody (XOR)
The Data Encryption Key is XOR-split into two shares: one stored server-side (HSM-wrapped), one returned to the client. Both shares are required to reconstruct the DEK and decrypt the secret.
Encryption flow
- 1Secret stored → DEK generated
- 2DEK XOR-split into share_server ⊕ share_client
- 3Server wraps share_server with KEK, stores ciphertext
- 4Client receives share_client (one-time)
- 5Read requires X-Client-Share header with the client share
2-of-3 Multi-HSM (Shamir)
The DEK is split using Shamir's Secret Sharing with a 2-of-3 threshold across Google Cloud KMS, AWS KMS, and Azure Key Vault. Any two of three HSMs can reconstruct the key.
Encryption flow
- 1Secret stored → DEK generated
- 2Shamir split (k=2, n=3) produces 3 shares
- 3Share 1 → wrapped by GCP Cloud KMS KEK
- 4Share 2 → wrapped by AWS KMS KEK
- 5Share 3 → wrapped by Azure Key Vault KEK
- 6Read → any 2 shares unwrapped and recombined
2-of-3 + Client Custody
Combines multi-HSM Shamir splitting with an additional XOR client share. The server performs the Shamir split and then XOR-splits the DEK a second time, giving the client a share that is required for every read.
Encryption flow
- 1Secret stored → DEK generated
- 2Shamir 2-of-3 split across GCP, AWS, Azure
- 3DEK also XOR-split → client share returned
- 4Both server reconstruction AND client share needed
- 5Maximum isolation: neither 1Claw operators nor a single cloud provider can access data
Threat model: what MPC protects against
- Full compromise of any single cloud provider (GCP, AWS, or Azure)
- Insider threat: 1Claw operators cannot decrypt client-custody vaults
- Key exfiltration: stealing the database does not expose DEKs
- Regulatory seizure of a single provider's infrastructure
- HSM compromise: Shamir threshold means one breached HSM is not enough
- Supply chain attack on a single key management service
Trusted Execution Environment
Shroud runs inside AMD SEV-SNP enclaves on GKE Confidential Nodes. Secrets and signing keys exist only in hardware-encrypted memory.
AMD SEV-SNP on GKE Confidential Nodes
Shroud runs on Google Kubernetes Engine Confidential Nodes with AMD SEV-SNP. Memory is encrypted at the hardware level by the CPU's memory controller — not by software.
Memory encrypted at hardware level
Each TEE VM has a unique encryption key managed by the AMD Secure Processor. Neither Google, 1Claw operators, nor co-tenants on the same physical host can read TEE memory.
Attestation report verifiable by customers
Before trusting the TEE, customers can request an attestation report signed by the AMD firmware. This proves the code running inside matches the expected measurement.
Keys never leave TEE boundary
Signing keys are decrypted inside TEE memory and used for transaction signing. They are never written to disk, never logged, and never returned in API responses.
Intent validation pipeline
Every transaction goes through a six-step validation pipeline before a key is ever touched. Guardrails are enforced server-side — agents cannot bypass them.
Address allowlist
Reject if to-address is not in the agent's tx_to_allowlist
Value cap
Reject if value exceeds tx_max_value_eth per transaction
Daily limit
Reject if rolling 24h spend exceeds tx_daily_limit_eth
Chain restriction
Reject if chain is not in tx_allowed_chains
Tenderly simulation
Simulate via Tenderly; reject if reverted (when simulate_first or org requires it)
Signing
Sign with secp256k1 inside TEE memory; return signed tx hex + keccak hash
Replay protection
- Idempotency keys: UUID per request, SHA-256 hashed, 24h TTL. Duplicates return cached response.
- Server-side nonce serialization: SELECT FOR UPDATE on (agent_id, chain_id, address). Prevents concurrent nonce races.
- Nonce resolution: takes the higher of tracked DB nonce and RPC-reported pending nonce.
What Intents cannot do
- Sign to a non-allowlisted address, even if the agent is compromised
- Exceed the per-transaction or daily ETH value cap
- Skip simulation when the organization requires it
- Read or export the raw private key (blocked when intents_api_enabled)
- Replay a transaction (idempotency key + server-side nonce serialization)
Network isolation and data residency
Infrastructure-level controls that keep secrets off the public internet and data in the region you choose.
VPC-native deployment
Vault API and Shroud run inside a Google Cloud VPC with private service networking. Internal traffic stays on Google's backbone — it never traverses the public internet.
TLS everywhere
All external traffic is encrypted in transit with TLS 1.2+. Internal service-to-service calls use mTLS or VPC-internal endpoints. No secrets traverse the public internet unencrypted.
Data residency: US-West (configurable)
Default deployment region is US-West. Enterprise customers can configure dedicated infrastructure in their preferred region for data residency requirements.
Compliance roadmap
We're building toward the certifications your security team expects. Here's where we are today.
SOC 2 Type I
Controls assessment and documentation underway. Covers security, availability, and confidentiality trust service criteria.
SOC 2 Type II
Observation period will begin after Type I completion. Demonstrates controls are effective over time, not just designed correctly.
GDPR
Data minimization, purpose limitation, and right-to-erasure controls built into the platform. DPA available for Enterprise customers.
Need a BAA (HIPAA), ISO 27001 mapping, or a custom compliance assessment?
Contact our security teamTamper-evident audit log
Every action produces an immutable, hash-chained audit event. If anyone modifies a record, the chain breaks and the tampering is detected.
Append-only, tamper-evident
Every audit event stores a SHA-256 integrity hash chaining prev_hash, event_id, actor, action, resource, and timestamp. Tampering with any row breaks the chain.
Comprehensive coverage
Every secret access, agent token exchange, policy change, transaction signing, and share action is recorded with actor identity, client IP, and timestamp.
90-day export
Export audit logs in CSV or JSON for ingestion into your SIEM, compliance tooling, or archival storage. Enterprise customers get configurable retention.
Hash chain verification
Verify the integrity of your audit trail at any time by replaying the hash chain. Any gap or mutation is immediately detectable.
{
"event_id": "a1b2c3d4-...",
"prev_event_id": "f5e6d7c8-...",
"integrity_hash": "sha256(prev_hash | event_id | actor | action | resource | ts)",
"actor_id": "agent:9f8e7d6c-...",
"action": "secret.read",
"resource_id": "vault:abc/keys/stripe-live",
"timestamp": "2026-03-15T12:00:00Z"
}Ready to evaluate 1Claw for your team?
Schedule a technical deep-dive with our team, or start with the docs and free tier.
Questions? Reach us at ops@1claw.xyz