Get an API key

Updated 1 Oct 2026 · hosted in France (EU)

Security and trust.

Your agents’ mail is someone else’s personal data. This page says what protects it today, and marks what is still on our roadmap as planned. Agentboxd is a small company: we don’t hold SOC 2 or ISO 27001, and we don’t claim to.

sub-processors: 3

Three sub-processors. The core service is hosted in the EU. No analytics or trackers. Every processor is listed with exactly what it sees and when. See the list.

mx.agentboxd.com · FR

Where it runs

Hosted in the EU. What leaves it, and when, is on Privacy and data flow.

Production server
France · EU
The API, both mail servers, the database and stored mail run on one dedicated virtual server at Contabo, in Lauterbourg, France.
Backup server
EU
A second Contabo server receives an encrypted copy of every nightly backup. Nothing is stored outside the EU unless your AI setting sends it (below).
Exposed to the internet
443 · 25 · 587 · 465 · SSH
The website and API over HTTPS, the inbound mail server, SMTP submission and administrative SSH. The database and queue are never reachable from outside.
Physical security
Contabo
Data-centre access and hardware are the hosting provider’s responsibility.

Strict-Transport-Security

Encryption

TLS · HSTSIn place
agentboxd.com and api.agentboxd.com serve HTTPS only, with automatically renewed certificates and HSTS for a year, subdomains included.
STARTTLSIn place
Our MX offers STARTTLS with a real certificate for mx.agentboxd.com. Outbound mail uses TLS whenever the receiving server supports it.
SMTP submissionIn place
Ports 587 and 465 refuse to accept a password (your API key) until the connection is encrypted.
AES-256-GCMIn place
The DKIM private keys of your custom domains are encrypted in the database with a key kept outside it.
sha256In place
API keys, session tokens and sign-in links are stored only as hashes. A key is shown once; we can’t show it again.
HMAC-SHA256In place
Every webhook is signed with a timestamp, so your endpoint can reject forged or replayed deliveries.
Encrypted backupsIn place
Every backup file is encrypted with GPG before it leaves the server, to a key we keep offline, so the backup server only ever stores encrypted files. The copies kept on the production server for fast restores are protected by access control, not encryption.
Disk encryptionPlanned
Encryption of the server’s disks, which the provider doesn’t offer by default. Under evaluation.

Authorization: Bearer mr_…

Access control

Who can reach your data: your own keys and sessions, and one named administrator on our side.

No passwordsIn place
You sign in with a single-use link that expires after 15 minutes. There are no passwords to leak or reuse.
Scoped API keysIn place
Limit a key to one inbox and to the permissions it needs (for example send and read only), and revoke it at any time.
Workspace isolationIn place
Every record belongs to a workspace and every query is scoped to it; another workspace’s ids answer 404.
X-Requested-WithIn place
Dashboard requests that change data must carry a CSRF header, so another site can’t act with your session.
Restricted machine keysIn place
The automated deploy key can only run the deploy script, and the backup key can only write to one folder on the backup server.
MFA and access reviewsPlanned
Multi-factor authentication confirmed on every provider account we use to run the service (hosting, DNS, code), and a written access review every quarter.

03:15 · nightly

Backups and recovery

Nightly backupsIn place
Database, stored mail, attachments and keys every night and before every deploy. A backup with an empty or unreadable database dump counts as failed.
14 days · off-siteIn place
Kept 14 days on the server and on a second server. Anything deleted is gone from backups two weeks later.
Automatic rollbackIn place
A release that fails its health checks is rolled back to the previous one without anyone stepping in.
RPO 24 h · RTO 8 hIn place
Our targets: at most one day of data lost, service back within 8 hours if the server is lost. Targets, not an SLA.
Restore testsIn place
Every quarter the latest backup is restored into a throwaway database and checked against production: every table, and every stored email it points to. Last run 25 Sep 2026: passed.
Full recovery drillPlanned
A timed rebuild of the whole server from an off-site backup, to measure our 8-hour target end to end.

abuse@agentboxd.com

Monitoring and abuse

Every workspace shares our sending reputation, so abuse is stopped automatically. The mail checks together are Customs.

fail2banIn place
Hosts that probe our mail server for addresses or keep failing SMTP logins are banned at the firewall.
Rate limitsIn place
Per API key and session, per inbox and per workspace, plus limits on sign-in links per address and per IP.
Gradual sending limitsIn place
Owners are warned as a workspace nears a limit. Past a hard-bounce rate of 5% or a complaint rate of 0.1% over 7 days, its sending pauses until a person reviews it; receiving keeps working. Clear abuse suspends it.
Agent self-signup limitsIn place
When agents create their own workspaces: a proof of work per signup, limits per IP address and network, and until a person claims the workspace at most 20 new recipients a day and no webhooks. Idle unclaimed workspaces are deleted after 30 days.
Logs without contentIn place
Logs never contain message bodies, API keys, cookies or secrets.
Health checks · 5 minIn place
Every 5 minutes: the website and API (with the database, queue and storage), both mail servers, every service, disk space, last night’s backup and certificate expiry. A failure emails us at once, again every 6 hours until fixed, and when it recovers.
Blocklists · feedback loopsIn place
Our sending IP is checked against the main blocklists every hour. Microsoft reports spam complaints to us, and Google Postmaster Tools and Microsoft SNDS show how Gmail and Outlook rate our mail.
Outside-in alertingPlanned
Uptime checks from outside our server, so a full outage still reaches us, and alerts to a phone at any hour.

orgs.ai_processing

AI processing switch

One setting per workspace, changed by an owner. Every call to an AI provider checks it first, and a test fails the build if new code skips the check. Exactly what each level sends.

AI apps you connect yourself (for example Claude through our connector) act on your behalf and under your agreement with them; they are not our sub-processors.

Off
off
No email content leaves the Agentboxd server.
Categorize
categorize
JEV reads each inbound message to label it. This is the default.
Full
full
Everything in Categorize, plus reply drafts written by DeepSeek.

orgs.local_processing

Document parsing

Attachments are read on our own server (text extraction and OCR), never by an outside service, and a workspace owner can turn it off. What local processing covers.

Isolation
worker thread
Each document is parsed in its own thread with a memory cap and a time limit, one at a time on a separate queue.
Hostile files
limits
200 pages and 25 MB per document; Word and Excel packages are checked for decompression bombs before they are opened.
OCR service
internal network
Runs on the same server with a memory limit, is never exposed to the internet and has no route out to it.
Untrusted text
untrusted: true
Text from attachments is marked as untrusted input for agents and models, exactly like email bodies.

Authentication-Results

Prompt-injection defences

Email is written by strangers. We treat it as data at every step, and so should your agent. How the flags look.

ai:injection-risk
With AI processing on, every inbound message gets injection and phishing scores and labels before your agent reads it.
dmarc-fail · spf-fail
SPF, DKIM and DMARC are checked on every message and failures are labelled, so an agent can distrust spoofed senders.
UNTRUSTED MESSAGE CONTENT
MCP results mark mail as data, never instructions, and carry warnings when a message is flagged.
Drafts never send
Reply drafts treat the thread as untrusted, email can’t break out of its block in the prompt, the model has no tools, and a draft is only ever returned to you.
sandbox
The dashboard shows a message’s HTML in a sandbox with no scripts, forms or navigation. Attachments download; they never open on our domain.

Security review

Six questions to ask any agent email provider, and our answers

Security reviews ask these before an agent gets an inbox. Our answers say what works today and what doesn’t, plus a seventh question reviews now ask: who approved each send.

Can I restrict exactly which addresses my agent sends to and receives from?
Yes. Allow and block lists for receiving, sending and replying, per inbox or for the whole workspace, by exact address or by domain. With an allow list, every other address is refused: a send to it fails in the API, and inbound mail from it is labelled blocked and hidden from your agent.
Do you check SPF, DKIM and DMARC, and can I keep failures out of my agent’s context?
We check all three on every inbound message and label SPF and DMARC failures spf-fail and dmarc-fail; our MCP server adds a warning to those messages. We don’t hide failing mail ourselves today: your code skips it by its label, and a forwarding rule can skip mail that fails DMARC.
What screens inbound content for instructions aimed at the model, and can a flagged message be held before my agent sees it?
With AI processing on (the default), a classifier scores every inbound message for prompt injection and phishing and labels it ai:injection-risk or ai:phishing at 0.8 or more. Your agent can wait for the scores before it sees a message: claim with enriched: true, or react to the message.enriched event. We don’t hold flagged mail back ourselves: your code decides, and a forwarding rule can skip it. With AI processing off, there are no scores.
Can I issue a key that reads but never sends, and can that key change its own restrictions?
Yes, and no. A key gets only the permissions you pick, so a key with messages:read and without messages:send can read but never send, and it can be limited to one inbox. Keys are created and changed only from a signed-in dashboard session: no API key can create, widen or revoke a key. Leave lists:manage off an agent’s key, so it can’t edit the lists that limit it.
Is my data isolated from your other customers, and is my sending reputation isolated too?
Your data, yes: every record belongs to one workspace, every query is scoped to it, and another workspace’s ids answer 404. Your sending reputation, partly: on your own domain, mail is signed with your domain’s DKIM key, so the domain’s reputation is yours, but by default every workspace sends from our shared IP. That is why the abuse limits above apply to everyone. A dedicated sending IP is listed as an add-on on the pricing page.
Where are my messages processed, who can access them, how long are they kept, and are they used for training?
On our own server in France, unless your AI processing setting sends part of a message to an AI provider (above). One named administrator can reach the server; our operator console never shows message bodies, attachments or extracted text, and records every action. Mail is kept 30 days on Free, 1 year on Builder and 2 years on Team, or less if you choose; on Scale we agree it with you. We don’t train models on your mail. The contracts that bind our two AI providers to the same are still planned (see below): if that matters to you, keep AI processing off.
Who approved each send?
When a draft is approved, we record who approved it: the person, the API key, or the connected app and the person who authorised it, with the time and a hash of the exact content approved. The record stays on the sent message, and shows in the dashboard, the API and the draft.sent event. Drafts sent before 1 October 2026 have no approver recorded.

SOC 2 · not yet

Certifications and roadmap

No SOC 2 report or ISO 27001 certificate yet. Our policies and controls follow the SOC 2 criteria, and we answer security questionnaires: write to hello@agentboxd.com.

Written policiesIn place
14 security policies (access, change, incidents, continuity, encryption, vendors, risk and more), reviewed every year.
Controls mapped to SOC 2In place
Each control is mapped to the SOC 2 Trust Services Criteria and marked in place, partial or planned.
Data processing addendumIn place
A GDPR Article 28 DPA you can request today.
Contracts with AI providersPlanned
Data processing terms and Standard Contractual Clauses with JEV and DeepSeek for transfers outside the EU.
Dependency scanningPlanned
Automatic alerts and updates for vulnerable dependencies, checked in CI.
Penetration testPlanned
An independent test of the API, mail servers and dashboard.
SOC 2 reportPlanned
Not yet. We will start an audit when customers need one, and say so here.

/.well-known/security.txt

Report a vulnerability

Write to security@agentboxd.com with what you found, how to reproduce it and what an attacker could do with it. We acknowledge reports within 3 working days, keep you posted until it’s fixed, and credit you if you want.

We won’t take legal action against research done in good faith that follows these rules: use only your own workspace and accounts; don’t read, change or delete other people’s data (stop and tell us if you reach any); no denial of service, no spam or phishing sent through our servers, no social engineering of our providers; give us reasonable time to fix before you publish.

Spam or abuse coming from an Agentboxd address goes to abuse@agentboxd.com instead.

GDPR