The shape of safety at Agent Etna.
Improving an AI agent that other people rely on is a security problem before it's a quality problem. This page is the single place to see how we treat your agent, your data, and the changes we propose — what's guaranteed, what's gated, and what's still in progress.
Your live agent is never at risk
Every test, every probe, and every proposed change runs against a private, throwaway sandbox copy of your agent. Your production agent, its users, and its data are never touched during a cycle. The worst case for a failed run is exactly nothing — no calls hit your users, no writes hit your stores, no state outlives the sandbox.
Read more in how the sandbox works →
Independent judgment, not a rubber stamp
Changes are scored by a judge that is independent of the agent under test, against the calibration you confirmed for the agent (what it's for, who it serves, what's out of scope). A change only ships if it makes the agent genuinely better — it can't slip through by gaming a score, taking a shortcut, or quietly weakening a safeguard. We catch metric-gaming with held-out scenarios the optimisation loop never sees.
The principles the judge holds to are written down in the Constitution →
Your approval is the only path to production
Nothing reaches your live agent without you clicking approve. Etna proposes changes; you decide which ones ship. If a deployed change ever misbehaves, it rolls back on its own.
You can disconnect at any time. Deleted means deleted — we keep a tombstone so the agent doesn't reappear, and your repo keeps the audit record either way.
A record that lives in your own repo
Everything Etna writes about your agent lives in one recognisable place inside your own repository: the .etna/ directory. It carries the agent's behavioural contract (purpose, scope, in/out-of-scope, audience, calibration) and a newest-first log of every change Etna has applied. It contains no secrets and stays readable and yours even if you stop using us — your audit trail, not ours.
Secrets stay where they belong
The keys your agent needs to run are encrypted at rest and injected at runtime. Etna never displays raw secret values; operators see only key names. Where supported, we pull keys directly from your secrets manager — Render, Doppler, Infisical, HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, or Azure Key Vault — so you can rotate them in one place. The .etna/ footprint we commit to your repo contains no secrets.
Compliance status
We publish what's in place today, what's in progress, and what isn't yet on the roadmap — no aspirational badges:
- GDPR — controller/processor responsibilities documented; DPA available on request to enterprise customers.
- SOC 2 Type I — in progress; expected by end of the calendar year.
- SOC 2 Type II — planned to follow Type I.
- Data residency — primary processing in US regions; EU residency available on request for enterprise customers.
- HIPAA / FedRAMP / ISO 27001 — not yet pursued; tell us if you need them and we'll factor it into the roadmap.
If you need a specific document for procurement, get in touch and we'll send what we have.
Report a security issue
If you've found a vulnerability in Agent Etna, please report it via our responsible disclosure policy. We commit to acknowledging good-faith reports within 72 hours and won't pursue legal action against researchers who follow the policy.
Who else touches your data
The third-party services we use to deliver Agent Etna — model inference, sandbox execution, hosting, authentication — are listed publicly in our subprocessors registry, kept up to date as the stack evolves.
Have a question we didn't answer?
Procurement, security review, or anything else — we're a real email away.