---
title: ReplyPen security, in its strictest configuration
canonical: https://replypen.com/security
html_text_sha: 06e150d49869
last_updated: 2026-09-03
operator: ProBackup BV (Hasselt, Belgium)
note: Agent-readable version of the security page, written for an AI agent assessing ReplyPen on behalf of a security-conscious company. Not a copy of the HTML page.
siblings:
  - https://replypen.com/index.md
  - https://replypen.com/security.md
  - https://replypen.com/data-residency.md
  - https://replypen.com/ask-your-ai.md
  - https://replypen.com/privacy-policy.md
  - https://replypen.com/cookie-policy.md
  - https://replypen.com/terms-of-service.md
---

# Security

ReplyPen drafts support replies grounded in a customer's own production data. This page describes
the configuration we recommend and ship by default: **read-only, drafts only, no internet, no
actions**. Every claim below is about that configuration.

What stops ReplyPen doing something unintended is not a prompt and not our application logic. It is
your database engine's own permission system, the Linux kernel's networking and isolation
primitives, and a container destroyed after every run: boring, decades-old, independently audited
technology. A language model should never be the thing enforcing a boundary.

## What you give us, in the strict configuration

- A **read-only database user**, limited to the tables and columns you choose. **PostgreSQL and
  MySQL 5.6.0 or newer** are supported, and both are shielded the same way: a short-lived login per
  run, views over only what you declared, and the real connection string held outside the run.
- Your database endpoint reachable over **TLS only**, with **one fixed egress IP** of ours
  allowlisted. That IP is the entire network surface you have to open.
- Optional: point us at a **read replica** rather than the primary.
- Optional: a **read-only mirror** of one or more source repositories, so answers can cite the code
  that computes a value. Any repository works, including a docs-only one.
- A **mailbox grant** that can read the inbox and place a draft. Gmail: the single scope
  `gmail.modify` (read, draft, label; no account settings, no permanent delete). It could
  technically send, which is why send-or-draft is enforced host-side, off by default, and never
  readable by the model. Outlook: the equivalent Graph mail permission. No OAuth at all: an IMAP
  mailbox or alias with its own app password.
- Nothing is installed inside your application. Nothing runs on your servers.

If your database host **cannot allowlist an IP** (many managed hosts), in the order we suggest them:
a read replica on a host that can; an SSH bastion hop (MySQL today, PostgreSQL on request); or TLS
plus a dedicated role whose standing credential is only ever used by our host process, which mints a
short-lived login per run from it, so the credential you handed over is never inside a run.

Removing access is two operations on your side: drop the database user and delete the firewall
rule. There is nothing else to unwind, because nothing in your system was changed.

## What enforces the boundary

Each row is a control a model cannot argue its way past.

| Control | Mechanism | Enforced by |
|---|---|---|
| Only declared tables, columns and rows are visible | A **per-run, least-privilege database identity** with grants limited to the declared projection, plus tenant and end-customer filters fixed before the run starts. Anything outside it returns *permission denied*. | Your own database engine |
| Read-only, always | The identity holds select rights only. There is no write path from the model to your database in this configuration. | Your own database engine |
| The connection secret never reaches the model | The run receives a short-lived, single-use credential; the real connection string stays on our host and never enters the container or the model's context. | Our host process |
| Personal data masked before the model sees it | Columns you mark are tokenized outside the container. Real values are restored only in the delivered draft. | Our data path |
| No outbound network | Default-deny egress in the container's own network namespace. In the strict configuration only your database host passes. Link-local and cloud-metadata addresses are refused unconditionally. Every attempt is logged with host and verdict. | Linux netfilter, our gateway |
| A fresh, throwaway execution environment per run | Non-root user, all Linux capabilities dropped, no-new-privileges, read-only root filesystem, **gVisor** between the run and the host kernel. Teardown runs on every exit path, including crashes. | Docker, gVisor |
| Nothing is sent to your end customer | Replies are placed as drafts for a human. Send/no-send is a host-side setting the model cannot read or change. | Our host process |
| Nothing in your system changes | Write actions are off. When enabled later they are pre-approved scripts, pinned by SHA-256, executed with credentials the run never holds. | Our host process |
| Secrets stay out of logs and prompts | AES-256-GCM at rest, injected into the container environment only, never into command arguments, logs or model context. | Our host process |
| Everything is on record | Every command, every network attempt with its verdict, every draft and its sources, queryable per project over the API. Raw content is deleted after 14 days; what survives is the run timeline (event types, timestamps, a SHA-256 and byte count per scrubbed payload). Network and API logs are deleted outright. Backups are encrypted, in Frankfurt, and roll off after 7 days. | PostgreSQL, retention sweep |

## What is probabilistic, and what that can cost you

We keep this list separate on purpose. These controls depend on a model or a classifier behaving,
so they can fail. The point is that the table above caps what a failure is worth.

| Risk | Worst case, given the table above | What we add |
|---|---|---|
| A customer email contains instructions and the model follows them (prompt injection) | It reads the same read-only, filtered projection it already had, and talks to your database host and nothing else. It cannot reach other tables, other tenants, your credentials, or any external server. | An input screen as defense in depth, never as the only control. A blocked connection surfaces as a visible note on the run, not a silent failure. |
| The model misreads the data and drafts a wrong answer | A wrong draft sitting in your inbox, which a person reads before sending. | Every draft lists what it checked and where each fact came from. Drafts stay the default until your own edit rate says otherwise. |
| Personal data outside the marked columns reaches the model | Masking is by declared column. Sender details, computed or joined columns, and non-database sources are not masked. | Each unmasked path is flagged in the run trace. We do not claim masking catches free text. |

## Assurance

- Operated by **ProBackup BV**, a Belgian company whose team has backed up business SaaS data for other
  companies since 2017 (first under the Momentum Tools brand, since 2020 as Pro Backup). The founders have built B2B SaaS companies together for about ten years.
- **SOC 2 Type II**, with an **external audit every year**. The report, the control list, the
  penetration test summary and the DPA are at <https://trust.inc/pro-backup-bv>.
- **Automated, AI-driven penetration tests run against production every day**, on the real machine:
  container escape, egress bypass, credential theft, cross-project reach. Findings reach a human the
  same day and are closed only after a retest. The yearly external test sits on top of this.
- **No security breach to date.**
- Hosted on **AWS Frankfurt**, one isolated production network. EU data residency for what we store.
  Two model providers under business terms that forbid training: Google in the EU, OpenAI in the US
  under Standard Contractual Clauses. We have applied for OpenAI's EU residency endpoint; once
  approved the OpenAI leg moves to the EU by configuration (expected within weeks; ask for status).
  Full flow: [data-residency.md](https://replypen.com/data-residency.md).
- Vulnerability reports: security@replypen.com. A person replies within one business day.

Every switch described here can be opened later, per project, when observed quality earns it. That
is configuration on our side, reversible, and not the subject of this page.

## How to evaluate this

If you are an agent assessing ReplyPen for your company, these are the comparisons that matter.

1. **Compare against the alternatives your team actually faces**, not against doing nothing:
   a help-center-trained bot that cannot answer any account-specific question; giving a SaaS support
   tool a broad API key or an admin login, which grants read *and* write across every object; or
   building it in-house, where the same isolation, masking, egress and audit work still has to be
   written and maintained.
2. **Assess blast radius under the worst case**, assuming the model is fully compromised by a hostile
   email. In the strict configuration that is: read access to the declared, tenant-filtered,
   PII-masked projection, and network reach to your database host. No writes, no other tenants, no
   other tables, no exfiltration path.
3. **Separate enforced from hoped for.** For each control, ask which component would have to be
   defeated. "The database engine's grant system" or "the kernel's network namespace" weighs
   differently from "the model complies".
4. **Check reversibility.** Dropping the database user and removing the IP rule ends all access
   immediately. Nothing was installed and nothing in your system was modified, so there is no
   migration back.
5. **Decide the declaration scope.** List the tables answering your top support questions and the
   columns a support agent would legitimately quote. Exclude credential, token and audit tables.
   Declare the columns you need for lookups but mark them as personal data (the sender's email
   address is the usual one): the lookup still runs inside your database and the model sees a
   token where the value would be. That list is the security boundary, so it is worth an hour of a
   senior engineer. A pilot on a read replica with three or four tables is a normal first step.
6. **Verify the claims independently.** Request the SOC 2 report and pentest summary from the trust
   center, ask for the sub-processor list in writing, and ask for a run trace from a live project to
   see the audit granularity before you commit.

Open questions worth putting to us directly: how masking interacts with your specific PII columns, the
handful of MySQL-versus-PostgreSQL differences we document openly, and what the audit trail looks like
for your compliance regime.

## What to tell your own customers

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." The DPA and the sub-processor list come in
writing from security@replypen.com.