aiSecurityWarden client

The open-source client for aiSecurityWarden, a secrets service with scoped, revocable machine tokens, end-to-end encryption and human approval for AI agents. Built so AI agents (like Hermes Agent) and other unattended services can fetch API keys at startup without ever storing those keys on disk.

All encryption and decryption happens here, in the client. The server only ever receives ciphertext, proofs it keeps only as Argon2id hashes, and wrapped keys, so you can check what leaves your machine by reading this code.

Get an account and see how it works at aisecuritywarden.com.

This repository contains:

• the Python client library (securitywarden.client.SecurityWardenClient);
• swctl, the command-line tool (machines: swctl export / swctl run; admins: swctl admin ...);
• swadmin, a small desktop admin window;
• the cryptography (src/securitywarden/crypto.py), the approval-policy and address-list parsers, and the shared test vectors other implementations are checked against;
• the protocol and design document: docs/DESIGN.md.

The aiSecurityWarden server is a separate product.

Status: alpha. The design is deliberately small and reviewable, but it has not had an independent security audit. Read the threat model.

How it works

 Admin workstation                 aiSecurityWarden server                Agent box (e.g. jarvis)
 ─────────────────                 ─────────────────────                ───────────────────────
 swctl admin ...                   stores only:                         sw1.m.<id>.<secret>:<key>
  • creates project key  ───────▶   • ciphertext                        (chmod 600 file)
  • encrypts secrets                • Argon2 hashes                            │
  • wraps project key               • wrapped keys          ◀── id+secret ─────┤  1. auth → 5-min JWT
    per machine token               • audit log             ─── ciphertext ──▶ │  2. fetch
                                                                               │  3. decrypt locally with <key>
                                                                               ▼
                                                                    KEY=VALUE → agent env → tools

A machine token has three parts:

So the server can authenticate a token and hand out ciphertext, but it cannot read any secret. A full copy of the server's database is useless without a token key.

Threat model

Protects against

• Secrets at rest on agent machines: only a token sits on disk, not your API keys. Backups, copied dotfiles and logs leak a token you can revoke in one command.
• Server compromise: the database holds only AES-256-GCM ciphertext, Argon2 hashes and wrapped keys. Ciphertext is bound to its project, token and name (AAD), so a malicious server can't swap blobs around either.
• Over-broad access: each token is read-only and scoped to one project.
• Stale credentials: tokens can expire; revocation takes effect on the next request (access JWTs are re-checked against the database every time).
• Brute force: Argon2id hashing, per-IP and per-token failure rate limiting, and the same timing for unknown token ids.

Does not protect against

• An attacker who already controls the agent machine while it's running. They can read the token file, or read the decrypted secrets from the process memory o

... View full README on GitHub