Encrypted secrets at rest
API keys, integration tokens, custom environment variables, Nostr keys, and managed wallet keys are encrypted before storage using AES-256-GCM. Passwords are stored as bcrypt hashes.
Platform security
How Hatcher protects agents, credentials, and wallets
Hatcher runs autonomous agents on managed infrastructure. That means security is built around a simple principle: keep platform secrets out of agent runtimes, scope each agent tightly, and decrypt sensitive user data only when a trusted backend path needs it.
Last updated: May 21, 2026
Security posture
Defense in depth for hosted AI agents.
- Agent credentials are encrypted at rest and masked after save.
- Agent containers do not receive general Hatcher infrastructure secrets.
- Network access is routed through platform-controlled, auditable paths.
- Container escape is treated as low-likelihood but high-impact incident response.
Just-in-time runtime access
Secrets are decrypted only on trusted backend paths when an agent runtime, signing action, or owner-approved export needs them. Saved secrets are masked in the UI and not returned by normal read APIs.
Isolated agent containers
Agents run in dedicated containers with resource limits, read-only root filesystems where supported, writable tmpfs for runtime state, and no-new-privileges container hardening.
Network egress controls
Agent web access and platform calls go through Hatcher-controlled endpoints. Private, loopback, link-local, and cloud metadata addresses are blocked for webhook-style URLs and internal network paths.
Provider key separation
Hatcher provider keys for LLMs, billing, analytics, and partner integrations are not placed inside general agent containers. Agents use scoped platform endpoints instead of raw platform credentials.
Owner-scoped wallets
Managed agent wallets are scoped to the agent. Private key export requires owner authentication, and runtime signing is limited to wallet actions explicitly exposed by Hatcher.
Credentials
Where credentials live and how they are decrypted
Hatcher does not encrypt secrets with an individual container public key. Credentials are encrypted server-side before storage, and plaintext is only reconstructed by the trusted backend when the platform needs to start an agent, perform a scoped action, or complete an owner-authenticated private key export.
- 1You enter a credential through the dashboard or API over HTTPS.
- 2The backend validates the request, encrypts the value with a server-held encryption key, and stores only ciphertext plus the nonce/authentication data needed for AES-256-GCM.
- 3Normal config reads return masked placeholders or stripped data, not the plaintext secret.
- 4When an agent starts or uses a managed platform action, the backend decrypts only the specific values needed for that agent and action.
- 5Logs and admin views pass through secret redaction so tokens, private keys, passwords, and credentials are not printed back by default.
Runtime isolation
Agent container controls
Containers are still software, so Hatcher assumes compromise is possible and designs the runtime to reduce what any single agent can reach.
Dedicated per-agent runtime boundary
CPU, memory, and process limits
Read-only root filesystem where the framework supports it
Writable tmpfs for temporary runtime state
No-new-privileges hardening
No broad platform secrets in the agent environment
Authenticated calls back to Hatcher platform APIs
Egress diagnostics for owner-visible network decisions
If an agent process is compromised
The expected exposure is limited to that agent runtime, its workspace, its scoped runtime token, and any owner-provided secrets intentionally mounted for that agent.
If a container escape is suspected
We treat it as a host compromise: isolate the host, rotate affected runtime tokens and provider keys, rebuild workloads on clean infrastructure, and notify affected users when required.
What should not be reachable
A normal agent container should not contain database credentials, Stripe keys, Hatcher treasury keys, SSH keys, raw hosted LLM provider keys, or secrets belonging to other users or agents.
Data and logs
Sensitive fields are stripped or redacted from normal API responses and operational logs. We keep logs for debugging, abuse prevention, billing integrity, and reliability, but they are not a place for long-term secret storage. Agents are instructed not to write private keys, API keys, or raw credentials into memory files.
Wallets and signing
Managed wallets are created per agent and encrypted server-side. Agents can only use wallet operations exposed by Hatcher runtime tools, and owner-visible private key export requires account password confirmation. Users remain responsible for funds they deposit into agent wallets.
Responsible disclosure
Found a security issue?
Please send enough detail for us to reproduce the issue. Do not access or modify other users' data, do not exfiltrate secrets, and do not disrupt the service while testing.