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 bucket. 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. Network policy at the Kubernetes layer prevents cross-account traffic.
• Per-user service account. Authenticated via Workload Identity, 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 1.3 for all client connections. Internal traffic between gateway and agent pods runs on a managed mesh with mTLS.
• At rest: Vault files in GCS are encrypted at rest using Google-managed keys (AES-256). OAuth secrets are encrypted at rest using a separate KMS key.
• 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. Our providers do not train on what we send. Inputs and outputs are retained briefly (up to thirty days) only for automated abuse review, then deleted by the providers. 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 your own isolated cloud storage, 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. There is no analytics pipeline that sees the inside of your conversations.
• 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. We will claim, accurately, that it travels through an encrypted pipeline whose every endpoint is contractually and structurally bound to handle it the way you would expect a personal assistant to handle the contents of 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.
• Calendar create/update/delete always shows the change for confirmation.
• Vault overwrites of existing files require explicit confirmation.
• 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. 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.
• 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. The contents of your conversations are not.

• Sign-in is via Firebase Auth — magic email link or Google OAuth.
• No passwords stored on our side.
• Sessions use short-lived JWTs verified at the gateway on every request.
• Sign out invalidates the session immediately.

Found a security issue? We take it seriously. Email [email protected] 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.