Security
Wrasse runs an autonomous agent that holds your credentials and acts on your behalf. That is a serious thing to be trusted with, and the architecture is built around assuming the agent itself can be compromised — then making sure that is survivable.
This page describes what we actually do. Where something is a target rather than a fact, it says so; there is a table of exactly that further down. If you are running a security review and need more than this, write to security@wrasse.ai and ask — we will send our review materials and a data processing agreement.
The design assumption
An AI agent is an untrusted process by construction: it takes instructions from the outside world, and it decides what to do next. So Wrasse does not try to make the agent trustworthy. It puts the boundary somewhere the agent cannot move it — the isolation is around the container, the policy check happens before the tool runs, and the credentials that matter live on the other side of the fence entirely.
Controls
One container per user, and it cannot reach the network
Your agent runs in its own isolated machine — not a shared process, not a shared filesystem, not a shared network namespace. The container runs unprivileged, under a restricted syscall profile, with raw networking disabled. Outbound network access is denied by default: a bundle declares the hosts it needs, and those are the only hosts reachable. A skill that tries to call anywhere else does not get a refusal it can catch — the route does not exist.
Every action is checked before it happens, not after
A policy sidecar sits in front of the agent's tools. Every single tool call is evaluated against your policy before it executes, and recorded either way. That ordering is the point: a log that tells you what already happened is a receipt, and a check that runs first is a control.
The keys that matter never enter your container
The container is treated as untrusted, and the credential model follows from that. It holds a token minted for that one container, which resolves to exactly one user, so a compromised container cannot act for anyone else. Model-provider keys are held only by the control plane, which makes the call on the agent's behalf — the container never learns another provider exists. This is enforced by an automated test that fails the build if any variable outside a fixed allowlist is injected into a container.
Secrets are encrypted under a key we can rotate
Third-party tokens, integration keys and platform secrets are encrypted with AES-256-GCM under an envelope scheme backed by a key-management service, with a key version stored alongside each record so a re-encryption sweep can find what it needs to rotate. Secrets are never written to logs, and the console shows a fingerprint rather than a value — for credentials that a provider only ever shows once, there is no reveal path at all.
The audit trail is the product, not a feature
Every tool call, message and memory write is appended to an audit log you can read, filter, export and replay. Records carry a digest that makes tampering detectable, and the digest is kept indefinitely even after the full payload ages out at 90 days — so an old action stays verifiable long after its contents are gone.
Least privilege for our own people, too
Operator access to the platform console is permission-based rather than role-based: a person is granted the specific capabilities they need, every privileged action is attributed and recorded, and support access to a tenant appears in that tenant's own audit trail. There is no shared administrator login.
Data protection
- In transit — TLS for every connection between you, the platform, and any third party we call.
- At rest — AES-256 encryption, with secrets under the envelope scheme described above.
- Residency — your agent runs in US East (Virginia) or London (United Kingdom) and is pinned to that region. It does not move on its own.
- Segmentation — one container, one volume, one user. Enterprise tenants can be placed on dedicated infrastructure with a customer-managed encryption key.
- Deletion — closing an account starts a 30-day grace period, then deletion. See the Privacy Policy for the full retention schedule.
What we don't do
- We do not train models on your conversations, your documents, or your agent's activity.
- We do not sell personal data, and we do not share it for advertising.
- We do not aggregate one user's content with another's for any purpose.
- We do not run third-party analytics, advertising, or tracking scripts on this website.
- We do not send marketing messages to a phone number you connect.
Where we are on certifications
We are a small team working toward certifications methodically, and we would rather tell you the truth about the timeline than imply an audit we have not had. Wrasse is not currently SOC 2 certified and has not yet completed an independent penetration test. Here is the plan, and where each item stands:
Email security@wrasse.ai for current status, our security review materials, or a copy of our data processing agreement. Our subprocessors are listed at wrasse.ai/subprocessors.
Reporting a vulnerability
Send security issues to security@wrasse.ai. Please include reproduction steps, impact, and any proof-of-concept code. We acknowledge within 24 hours and triage within 72 hours, and we credit researchers in our public disclosure log unless you would rather stay anonymous. The bug bounty opens publicly in Month 3; we pay privately now.
Please do not test against accounts that are not yours, exfiltrate any data, or run automated scanning that affects availability for other users. Everything else is on the table, and we will not pursue researchers who act in good faith within those limits.
Incidents
If an incident affects your data, we will tell you — what happened, what was reached, what we did, and what you should do — without waiting for the investigation to close. Where the law sets a notification deadline, we meet it; where it does not, we still tell you.