How your data is kept safe.

Not a promise not to look. A structure that cannot.

Security in a personal AI product is not a checklist of features; it is a posture. The right posture is paranoia about user data — assume the application will have bugs, assume the underlying model will sometimes be wrong, assume the network is hostile — and design so that none of those failures can leak your information into someone else's account or out to the world.

Everything below follows from that posture.

Every account gets its own infrastructure. This is the most important security property of the product — and the most expensive to provide. Specifically:

• Per-user storage. Your vault files live in a cloud object storage prefix scoped to your account. The cloud's IAM enforces access at the infrastructure level — even if our application code had a bug, the cloud would refuse to serve another user's data.
• Per-user agent server. Your conversations run in a process no other account can reach. The cluster's network policy prevents cross-account traffic.
• Per-user service account. A per-user identity of its own, with permissions granted only to your prefix.
• Per-user memory. Knowledge graph and memory map are scoped per account in isolated stores.

These are not policy guarantees that say "we promise not to look." They are infrastructure properties that say "we structurally cannot serve user A's data into user B's session."

• Connections use each service's own OAuth flow. We never see your password.
• Tokens are stored in encrypted cloud secret management — one secret per user per service.
• Tokens never appear in application logs. We strip them at the source.
• Tokens are not returned by any API endpoint, even to you.
• Revocation is one-tap. The token is destroyed immediately; your agent loses access on its next turn.
• You can also revoke from the service side at any time (Gmail, Notion, Slack all support this).

• In transit: TLS on every client connection — 1.2 at minimum, 1.3 for modern browsers. Internal traffic between the gateway and agent pods stays on the cluster's private network — it is never routable from the public internet.
• At rest: Vault files in cloud storage are encrypted at rest using Google-managed keys (AES-256). OAuth secrets sit in cloud secret management, encrypted at rest by the store itself.
• Memory: Knowledge graph and memory stores inherit the same at-rest encryption as the underlying storage layer.

This is the question that matters most, and it deserves a plain answer. When 1Presence opens an email — including one with bank details, an invoice, a contract, anything sensitive — that content has to travel to the underlying models so they can read, summarise, or act on it. Here is the whole path that data takes, with nothing hidden:

• In transit. Every leg of the journey is TLS-encrypted — your device to our gateway, gateway to your dedicated agent server, agent server to the model APIs, agent server to the connected service (Gmail, Drive, Notion). No plain-text hops.
• At the model layer. The content goes to commercial AI APIs governed by contracts that explicitly forbid using customer content to train models. We do not train models. Those contracts also forbid the providers retaining what we send. Your content is sent so the model can read it and answer; once the answer comes back, the providers we use retain neither what went in nor what came out. There is no copy sitting in a review window, and no human reviews routine traffic.
• At rest, on our side. Anything saved into your vault — an attachment 1Presence pulled in, a summary it wrote — lives in isolated cloud storage scoped to your account, encrypted at rest, reachable only by your dedicated agent server. Anything written into your memory lives in a per-account store with the same isolation.
• Out to anyone else. We do not sell, share, syndicate, or otherwise hand your content to advertisers, brokers, partners, or third parties.
• Visibility on your side. Everything 1Presence read or wrote in a session is in your conversation history and, where it matters, in the file or memory it created. You can see what was looked at. You can delete it. You can revoke the connector it came from.

Two practical knobs if you want tighter control over what flows where:

• Per-connector scope. Each connector requests only the access it needs, and you can disconnect at any time — the token is destroyed immediately.
• Just ask. If a particular email or document is too sensitive even for a summary, tell 1Presence not to open it. It will not.

We are not going to claim the content never travels — that would be a lie, and the product could not work that way. What we will claim is true and simple: it travels through an encrypted pipeline, and every endpoint is bound — contractually and structurally — to handle it the way you would want a personal assistant to handle your inbox. Read it, do the work, do not keep it, do not share it, do not learn from it.

An AI assistant that takes real-world action is dangerous unless it gates every consequential operation behind explicit user confirmation. We do.

• Email sends always show the draft, recipients, subject and body for confirmation. You tap Send.
• Deleting an event or clearing a calendar shows a confirmation card first; an event that invites other people asks the first time, and that answer sticks.
• 1Presence cannot replace an existing vault file until it has read the whole of it in that session; a write that has not is refused.
• Posts to social services (LinkedIn, X) show drafts before publishing.
• The first time an agent attempts a consequential action it has not been cleared for, the action pauses and asks you to grant it — for that specific recipient, channel, or folder. Your answer is remembered and logged, and you can withdraw it any time from the Access tab.

Read-only work runs freely. Your main assistant works across your own account by design — and the action with the most reach, sending an email, always pauses as a draft for you first. For the specialist agents you add, anything that leaves a mark on the world is checked, at the moment it runs, against what you have granted that agent; if there is no grant, it stops and asks rather than guessing. Grants are specific — this recipient, this channel, this folder — not a blanket "do anything" switch.

• We do not train models on your conversations, vault, or memory.
• We use commercial AI APIs whose contracts forbid training on customer content.
• The model providers we use do not retain your content after answering. It is processed to produce the response, then it is gone from their side.
• We do not sell your data — not to advertisers, brokers, or anyone else.
• Aggregate, anonymised usage metrics (request counts, latencies, feature usage) are visible to us so we can keep the service running.

• Sign-in is by an emailed code or link, with Google, or with Apple.
• No passwords stored on our side.
• Sessions use short-lived tokens, verified at the gateway on every protected request.
• Signing out revokes your session across your devices.

Found a security issue? We take it seriously. Email security@1presence.com with the details. We will acknowledge within 24 hours and work with you on a coordinated disclosure timeline.

We do not currently run a paid bug bounty, but we do credit researchers publicly with permission and we move quickly on reports.