Security

Bartimaeus is a personal AI agent that runs in the cloud with your own model keys and acts in your real apps. That only works if you can trust it. This page describes the security posture we operate and are building toward at beta and launch — and where a control is not yet live, we say so.

1. The short version

Each user's agent runs in its own isolated container, hardened at the kernel boundary, with no shared secrets between users. Your model key is encrypted at rest under a separate key per user, and is never written to logs or shown to the model. The product itself is the biggest control: an approval protocol, read-only defaults, kill switches and undo on every action, and a curated allowlisted toolset with no arbitrary code execution in v1. Encryption is used in transit and at rest. No system is perfect; if a breach affects you, we will notify you and the relevant authorities as the law requires.

2. Isolation between users

Every user's agent runs in its own container with resource caps and per-user namespaces — the boundary between users is pod-level, never process-level, and no shared secrets cross tenant boundaries.

At launch, session containers run with hardened kernel isolation: namespaces, non-root execution, no-new-privileges, dropped capabilities, seccomp, AppArmor, a read-only root filesystem, no host mounts or devices, egress allowlists and cgroup v2 resource limits.

On top of that baseline, these strengthening controls are build requirements (in progress, complete before beta):

• Unprivileged user namespaces disabled (subject to a harness-compatibility check).
• Automated kernel patching with weekly node recycling, and a kernel CVE feed with 24–48h patch alerts.
• Landlock per-process filesystem confinement inside session pods.
• Minimal base images (no package manager or dev tooling).
• Single-tenant nodes for flagged or high-risk accounts.
• cgroup v2 memory, CPU and process limits everywhere.

Egress. Session pods can only reach the tool endpoints, your model provider's API, and the control plane — default-deny. Port 25 and common abuse ports are blocked, and session pods have no inbound exposure; the control plane is the only internet-facing surface.

The next boundary. We plan to add a second isolation layer (candidate: Kata microVMs) on top of this baseline when we have dedicated security expertise, on any escape-class incident in our runtime class, or at scale (~1,000+ paid users) — whichever comes first.

3. The safety floor (product controls)

These are non-negotiable, and they are build-gated: the approval protocol, server-enforced rails and kill switches must be live before any real user touches the service.

• Approval protocol. Anything sensitive pauses and waits for your explicit approval. Nothing irreversible happens automatically.
• Read-only by default. Every connection starts with read-only permissions. Gmail starts in drafts-only mode; nothing sends until you tap send.
• Kill switches. Every connection has a one-tap kill switch that revokes access instantly, and we can suspend a user's access with immediate effect if it is abused.
• Undo. Every action appears in your activity feed with a one-tap undo.
• Server-enforced rails. Usage rails and per-user rate caps on tool and model calls are enforced on the server, never in the client.
• No payment scopes. Bartimaeus has no payment scopes — moving money is structurally impossible in v1.
• Curated allowlisted toolset. The agent can only use the tools we ship. There is no arbitrary code execution in v1.
• Data, never instructions. Content the agent reads — emails, documents, calendar entries, web pages — is treated as data, never as a command. This protection is enforced in our development pipeline, and is verified in code before this policy goes live.

4. Your keys and tokens

• You bring your own model key (BYOK). It is stored encrypted at rest with a separate key per user (envelope encryption, AES-256-GCM, ciphertext only).
• It is never exposed to the model, never written to logs, and no prompt, transcript or debug output can contain it.
• Session pods hold short-lived handles, not your keys, and the vault's master key is held separately from your data — it never sits on a session node.
• You can remove your key at any time; the agent stops working until you add another.

In development builds the vault master key is a locally generated file; the infrastructure key (KMS) replaces it before beta. Connected-app credentials (Gmail, Calendar and so on) are handled by our integration gateway (Composio) under a written data-processing agreement — see the privacy policy for the processor details.

5. Platform controls

• Control plane. Authorisation on every route, read-only defaults inherited, rate limits, and an immutable audit log of who did what and when.
• Cluster segmentation. Session pods hold no Kubernetes credentials, and the cluster API is unreachable from the pod network.
• Supply chain. Pinned dependency hashes, signed images, dependency scanning (trivy) in CI, minimal base images, and no dev tools in production images.
• Config. Secrets live in a secrets manager, never in git; infrastructure changes go through reviewed Terraform only.
• Backups. Our operational archives are AES-256 encrypted before upload and stored in a private bucket, with secrets excluded.

6. Testing and monitoring

• Quarterly attack passes. We run our own documented attack scenarios against staging: escape attempts, abuse simulation (spam egress, scanning, mining), token-exfiltration attempts, config sweeps and dependency scans. Any finding is fixed in the same sprint.
• Red-team gate before beta. Before the beta opens, a formal red-team pass runs against the hardened staging environment, and beta entry depends on the results.
• Runtime detection. Egress volume or port anomalies, sustained CPU (mining signatures) and unusual process trees trigger an automatic pod kill and an account flag.
• Honesty about scope. These passes are our own. We have not yet commissioned an external penetration test — that is planned when funded.

7. What we don't do

• Read your tokens. Your model key is encrypted at rest, never written to logs, and never sent to the model. There is no readable copy for anyone to read.
• Run arbitrary code. The toolset is curated and allowlisted; there is no arbitrary code execution in v1.
• Sell your data. We do not sell data, and we do not advertise to you. There are no advertising partners and no third-party trackers in the product.
• Train models on platform data. We do not store your prompts or connected-app data for training, and we have no plans to train models on platform data.

8. Report a vulnerability

If you think you have found a security problem, we want to know. Email support@bartimaeus.app with: what you found, which area it affects (website, app, agent sessions), and the steps to reproduce it.

Please don't go beyond demonstrating the issue, don't access data beyond what you need to show it, and give us reasonable time to fix it before any public disclosure. We investigate every report and will let you know what we find. We're a small team, and responsible reports help us keep the service safe for everyone.

9. Data breaches and contact

No system is perfect. If a data breach affects you, we will notify you and the relevant authorities as the law requires. Security and vulnerability reports: support@bartimaeus.app. Privacy and data-rights questions: privacy@bartimaeus.app.