Last reviewed 16 October 2026. Everything below describes what is running today, not what is planned. Where we have not done something, it says so.
| What | Where | Encrypted |
|---|---|---|
| Message bodies and attachments | Amazon S3 | Yes — AES-256 at rest, and inbound mail is additionally encrypted with a KMS key before it is written |
| Message metadata (addresses, subject, timestamps, message ids) | Amazon Aurora PostgreSQL 16 | Yes — storage encryption enabled on the cluster |
| Your API keys | Aurora | Stored hashed. We cannot read your key back to you; a lost key is rotated, not recovered |
| Card details | Not stored by us at all | Stripe holds the card. We hold a token and the caps you set |
This is the part most pages are vague about, so here it is precisely.
DELETE /api/v1/messages/:id) removes the stored body from S3 immediately and clears the pointer to it.{"purge": true}) also clears the subject and strips the display names from the From, To and Cc addresses.| Processor | What for |
|---|---|
| Amazon Web Services | All hosting, storage and mail delivery. SES sends and receives, S3 stores bodies, Aurora stores metadata, KMS holds the encryption keys. Everything runs in us-east-1. |
| Stripe | Payments, including the agent wallet. Card details go to Stripe and never to us. |
| HeyCatch (PostHog) | Website analytics on these pages only — which pages are viewed and what is clicked. It never sees your mail, your API keys or your account data. We run it cookieless: it sets no cookie and stores nothing on your device beyond the current tab session, so there is nothing to follow you between visits. |
We do not sell data, and we do not share it with anyone outside that table.
Analytics note, 16 October 2026: the analytics SDK ships with a first-party
cookie carrying a persistent device id. We turned that off deliberately
(persistence: 'sessionStorage'). The trade is real and worth stating: we can
see how a visit moves through the site, and we cannot tell a returning visitor from a new
one. We would rather have the weaker number.
Every account's platform events are written into a hash chain, so an event cannot be altered after the fact without breaking the chain. A reconciliation job re-verifies every chain on a schedule and publishes the result, including failures.
That score is public and machine-readable, and it is the same file this site reads: the audit page · audit.json. When a run has flagged something, the page has said so — there is a worked example of exactly that in the published history.
Plainly, because the honest answer is more useful than a badge:
| Item | Status |
|---|---|
| SOC 2 | Not held, and no audit is in progress. If you need a SOC 2 report from your vendors today, we are not there yet. |
| ISO 27001 | Not held. |
| HIPAA / BAA | Not offered. Do not send protected health information through this platform. |
| GDPR-style deletion | Supported today. The purge behaviour above is the mechanism, and it is in the API rather than a support request. |
| Encryption at rest | In place on both the database and the object storage, verified 16 October 2026. |
| Encryption in transit | TLS on the API. Mail uses opportunistic TLS, which is what SMTP allows — no provider can promise more than the receiving server supports. |
| Tamper-evident audit log | In place, and published. |
| Penetration test | No third-party test has been commissioned. |
The underlying platform has run on AWS since February 2021 and has handled hundreds of thousands of messages. That is operating history, not a certification, and we are not going to present it as one.
Email support@agenticboxes.email, or use the machine-readable disclosure address at
/.well-known/security.txt.
Agents can file a ticket through the API: POST /api/v1/support/questions.