The answer to "why was I charged twice" or "where is my invoice" already sits in your database. ReplyPen looks it up, drafts the reply, and a person on your team sends it. Reading production data is a big ask, so this page says what stops the model doing more than that: which limits your database engine and the operating system enforce, which depend on a model behaving, and what we do about the second kind.
Last verified: 29 September 2026 · Operated by ProBackup BV, SOC 2 Type II
The short version
Every one of these is the default. Loosening any of them is a setting you change per project, later, if the quality earns it.
Replies land as a draft in your own inbox. Someone on your team reads it and clicks send. Automatic sending is a switch you can turn on later, per project.
The model works with read-only database access. Actions are off unless you enable them; when you do, changes go through scripts you approved in advance, and by default each one waits for a human to click confirm.
You declare what it may read. Everything else does not exist from its point of view. Your own database engine enforces this.
When a customer asks something, their database view is filtered to their rows before the model reads a single byte. It cannot widen that view, whatever the email says.
Names, emails and phone numbers in columns you mark are replaced by tokens on the wire. The real values are put back only in the finished draft.
Two model providers, one in the EU and one in the US, both under business terms that forbid training. The full list, and everything else we keep, is on Where your data goes.
Audited
ReplyPen is built and operated by ProBackup BV, a Belgian company whose team has backed up SaaS data for other businesses since 2017, first under the Momentum Tools brand and since 2020 as Pro Backup. That company holds a SOC 2 Type II report, re-examined by an external audit every year, and a public trust center where you can request it, along with the control list, the penetration test summary and the data processing addendum.
For the technical reader
Some of our controls are enforced by a kernel, a firewall or your database engine. A language model cannot talk its way past them. Others rely on a model or a classifier doing the right thing, and those can fail. Both lists are below, and we say which is which.
Where the last column says ReplyPen, the control runs on our side, outside the container the model works in. You do not have to take that on faith: the run trace shows every network verdict and every action, and the daily break-in attempts further down target exactly these components.
| What holds | How | Enforced where |
|---|---|---|
| A fresh container per run, destroyed afterwards | Non-root user, all Linux capabilities dropped, no new privileges, read-only root filesystem, gVisor sandbox between the run and the host kernel. Teardown runs on every exit path, including crashes. | Docker, gVisor |
| Read-only database access | The run receives a one-time token for our database proxy. The real connection string never enters the container. The role behind the proxy can only select. | PostgreSQL or MySQL, ReplyPen wire proxy |
| Only declared tables and columns exist | Before each run we mint a short-lived database login and a private set of views over exactly the tables and columns you declared. The base tables answer permission denied. PostgreSQL and MySQL 5.6.0+ are shielded the same way. | PostgreSQL or MySQL |
| One customer, one set of rows | Tenant and end customer filters are baked into those views before the run starts, from an identity the host verified. The model never supplies the filter. | PostgreSQL or MySQL |
| Your database stays fast | Every query is cancelled on your server after 30 seconds, not merely abandoned by us. At most two connections per run, results capped at 50,000 rows, read-only transactions. A heavy query fails; your database does not. A read replica is welcome. | PostgreSQL or MySQL, ReplyPen wire proxy |
| No write path through the model | Our knowledge repository and your source mirrors are mounted read-only. A write returns a filesystem error. The only write path is an action: a script pinned by its sha256 that you approved, executed with credentials the run never holds. | Linux mounts, ReplyPen action runner |
| Every outbound connection goes through our gateway | A default deny firewall inside the container network namespace. In enforce mode only allowlisted hosts pass. Internal and cloud metadata addresses are refused regardless. Every attempt is logged with host and verdict. | Linux netfilter, ReplyPen gateway |
| Secrets stay out of the model | Your credentials are encrypted with AES-256-GCM at rest and injected into the container environment only. They never appear in command arguments, logs or the model's context. | ReplyPen host, outside the run |
| Personal data masked by column | Columns you mark are tokenized inside the database wire proxy before any byte reaches the container. Real values return only in the delivered draft. | ReplyPen wire proxy |
| Autonomy switches live on our side | Draft versus send, and human, policy or auto per action, are settings the host checks at the moment of delivery or execution. The model has no way to change them. | ReplyPen host, outside the run |
| Everything is on record | Every command, every network attempt and every action is stored per project and available over the API. Raw content is deleted after 14 days; a redacted copy of each command stays for 90 days. | ReplyPen host (Postgres) |
Read the first column as the risk, the second as the ceiling on the damage, the third as what we add.
| What can go wrong | Worst case, given the list above | What we add |
|---|---|---|
| A customer email, or a web page the model fetches, contains instructions and the model follows them | It reads the scoped view it already had and talks to hosts on the allowlist. It cannot reach other tables, other customers, your credentials or an arbitrary server. | An input screen on inbound content as defense in depth, never as the only control. A blocked connection produces a visible note on the run, not a silent failure. |
| The model misreads your data and drafts a wrong answer | A wrong draft in your inbox. With auto-send on, a wrong email to a customer. | Every draft shows what it checked and where each fact came from. Drafts stay the default until your own edit rate says otherwise. Your corrections feed the next run. |
| In a customer-facing chat, the model paraphrases how your product is built: a file, a schema, a column list | A description of your internals in a chat answer. Not the data itself, which is covered above. | A rule in every prompt, a deterministic output guard, a check that no attachment copies your source, and a second model that judges the answer. That last judge can miss. We say so, and every block raises an alert to us. |
| Personal data outside the marked columns reaches the model | The email sender's own details and values in computed or joined columns are not masked. A database we cannot shield is refused rather than used unmasked. | Each unmasked path is flagged in the run trace so you can see it. Masking is by declared column and we do not claim it catches free text. |
| An action on policy mode runs with a wrong parameter | A change inside the bounds of the policy you wrote, for example a refund below your cap. | The policy is one line of code you wrote, not a model judgement. Caps and human mode are the defaults. Every execution is logged with its parameters. |
This is what a project looks like with every switch closed. You can open any of them later, per project, without a deploy on your side.
The model provider is the one connection that cannot be switched off, because it is the model. Google already runs in the EU; the OpenAI leg moves to OpenAI's EU residency endpoint as a configuration change once our application is approved, with current status on Where your data goes. Every other switch here opens something you may want later.
The filter is a database view, minted per run from an identity our host verified before the model started. The model never writes it. The example uses a dental software company with many practices.
Every table, every row
40 000 patients
Only declared tables and columns
WHERE practice_id = :scope
1 practice · 1 480 patients
AND patient_id = :patient_id
1 patient
A database login that can only read stage 4 is what the run logs in with. Asking for stage 1 returns permission denied.
On top of the yearly external test, AI agents run break-in attempts against our production, on the real machine, every day: container escape, network egress, credential theft, reaching one project from another. Findings go to a human the same day and are fixed with a retest before they are closed.
We publish the results because we would want to read this about a vendor. In June 2026, during our internal-only pilot, the first full assessment found two critical issues. The network gateway that should filter and log every outbound connection could be bypassed from inside the container, and the container could reach the cloud metadata service and read the machine's credentials. Both were fixed and verified live within four days. The container escape battery held. The same battery runs again on every assessment, and a regression is treated as the headline.
Prefer to let your own AI check us? Paste the prompts on Ask your AI into the coding agent that knows your codebase. Every page on this site has a plain-text twin it can read, listed there.
No. Runs use a read-only role. We also hold a provisioning credential that can create roles and views, used only by our host process and never by a run. Everything we add is our own objects. Drop them and your database is byte for byte what it was.
Very little, and never unbounded. A query that runs longer than 30 seconds is killed on your server, on MySQL by a KILL QUERY from our proxy, on PostgreSQL by statement_timeout. A run holds at most two connections. We tested this on a customer's MySQL 5.6 server with deliberately abusive queries and watched them vanish from the process list at 30 seconds. Point us at a read replica if you prefer.
Not for reading. If you want actions, there is an optional library for your framework that executes approved scripts inside your own runtime. Every call to it is signed with a per-project secret and verified with a constant time comparison.
Amazon Web Services in Frankfurt, one isolated network, production only. Model calls go to Google in the EU and to OpenAI in the US under standard contractual clauses. Nothing else sees email content.
Yes. Every command it ran, every network attempt with its verdict, and every action with its parameters are on the run trace and the API. The knowledge it keeps about your product is a git repository you can read and edit.
Enough to read the inbox and place a draft in it. On Gmail that is one scope, gmail.modify: read, draft and label. It cannot touch account settings or permanently delete mail. It could technically send, which is why send-or-draft is enforced on our host, off by default, and never readable by the model. On Outlook it is the equivalent Graph mail permission. If you would rather grant no OAuth at all, connect a mailbox or alias over IMAP with its own app password.
Three options, in the order we suggest them. A read replica on a host that can allowlist. An SSH bastion hop, which we support for MySQL today and for PostgreSQL on request. Or TLS plus a dedicated role whose standing credential is only ever used by our host process: each run gets its own short-lived login minted from it, so the credential you handed over is never inside a run.
Declare the email column and mark it as personal data. The lookup by the sender's address still runs inside your database, and the model only ever sees a token where the address would be. The sender wrote their own address in the email, so nothing new is revealed. Tenant matching in a multi-tenant setup comes from a trusted signal we control, a per-tenant mailbox or a signed token, never from anything read out of the thread.
Yes, per project and tenant. A token is a keyed hash of the value, with a key derived per project and tenant, so the same person gets the same token across runs within that scope and a different one in another project or tenant. The model can therefore tell that two threads concern the same account without ever seeing a name or an address; the mapping back to real values lives only in our host's memory for the duration of a run. Stable pseudonyms are still personal data under the GDPR, and our DPA treats them as such.
The parts a run reads, yes: the model cannot reason about code it has not seen, and that is where most of the value comes from. You choose which repositories to mirror, and a docs-only or support-relevant subset is a normal choice. Both providers work under business terms that forbid training; retention is limited to short abuse-monitoring windows, listed on Where your data goes. And the reply path is guarded against code, file names and schemas appearing in an answer (the probabilistic table above says how, and where that guard can miss). If a self-hosted model in the EU is a requirement, ask: the grounding work does not need a frontier model, and we plan for that option.
Email bodies, drafts, notes, the exact commands the agent ran, query output, model reasoning and the network and API logs are all deleted after 14 days. Three things outlive that. For 90 days we keep a redacted copy of each command, with text values replaced by placeholders, plus output sizes and the type of error if a step failed. It still carries internal record IDs, so it is pseudonymous, not anonymous, and it never contains query output or model reasoning. It exists so a problem you report weeks later can still be traced. For 12 months we keep the run's timeline: event types, timestamps, and a SHA-256 plus byte count of each deleted payload, readable over the API, then deleted too; earlier on request. Chat conversations you see in the chat window are kept for the project's chat retention period (90 days after the last activity by default, configurable per project, and never more than one year from the conversation's start), together with the files shared or generated in them, then deleted. Database backups are encrypted, stay in Frankfurt and roll off after seven days, so nothing deleted outlives a backup by more than a week.
Drop our role and schema. Within 30 days of your written request we delete the knowledge repository, the project's rows and the audit timeline, and confirm it in writing. Raw email and run content on our side is gone after 14 days anyway (chat conversations follow the project's chat retention period). Nothing was installed and nothing in your system was modified, so there is no migration back.
No. A pilot is one project, one mailbox and a handful of tables, and a few threads a week is a normal starting volume. The paperwork is the same DPA either way.
Name us as a processor in your privacy policy, with Google and OpenAI as our sub-processors for the AI step. One sentence usually does it: "Support requests may be processed by ReplyPen (ProBackup BV, Belgium), which uses Google Cloud (EU) and OpenAI (US, under Standard Contractual Clauses) to draft replies; none of them train models on your data." We send the DPA and the sub-processor list in writing.
Write to [email protected]. A person reads it, you get a reply within one business day, and we will tell you what we changed. We do not run a bounty program at this time.
This page describes the system as deployed on the verification date at the top. Where it summarises another company's terms, that company's own policy is the authoritative text. Legal detail lives in the Privacy Policy and Terms of Service.
