Zero trust

1claw is designed with zero-trust principles: no implicit trust of the network or the database; every access is authenticated and authorized, and secrets are protected at rest and in use.

Secrets at rest

• Every secret is encrypted with a DEK; the DEK is wrapped by a KEK that never leaves the HSM. The database stores only ciphertext and wrapped DEKs. There is no “master key” in the app; decryption requires a successful KMS unwrap.

No implicit access

• Every request must present a valid JWT. There is no “open” read. Policies explicitly grant read/write to principals for path patterns. Vault owners have full access to their vault; everyone else needs a policy. Agents have no access until a human creates a policy.

Revocation is immediate

• Deleting a policy removes access on the next request. When an agent's access policy is created, updated, or deleted, all of that agent's active JWTs are automatically revoked — the agent must re-exchange credentials to obtain a fresh token with updated scopes. This eliminates the window where an agent retains stale permissions from a prior token.
• Deactivating an agent prevents new tokens. Rotating an agent key invalidates the old key. There is no long-lived cache of secrets in the API.

Audit

• Access (and relevant failures) are logged. Secret values are never written to the audit log. You can use the log for compliance and incident response.
• The audit log uses a tamper-evident hash chain (SHA-256). The application database role is restricted from inserting directly into audit tables — all writes go through a SECURITY DEFINER function, preventing log fabrication.

In transit

• Clients must use HTTPS. The API is served over TLS. Do not send tokens or secrets over plain HTTP.

See Trust model for a short summary.