Privacy

Memories are the text your agents save through the memory API (/v1) or the MCP connection (/mcp). We store them in our database for your workspace. They stay until they are deleted through the API or by a deletion request.

To make memories searchable, we send memory text and search text to OpenAI, which turns them into vectors (embeddings). We do not send memories to a separate reranker today. If we add one, we list its host on the subprocessor page before it receives any memory or search text. We do not train models on your memories.

The companies that process data for us are listed on the subprocessors page.

Wherever you live, you have the right to request a copy of your data and to ask us to delete it. The steps are in How to ask for deletion. You can also email support@agentics.you. We respond within 30 days.

To delete the account, sign in and use Delete this account on Settings. That anonymizes the account and removes its sessions and app connections. It does not delete receipts. If you cannot open Settings, email support@agentics.you from the account email. We respond within 30 days.

1. Sign in, then email support@agentics.you from the address on the account. A company admin can ask for someone on the team.
2. Say what you want removed, why, and the legal basis that applies to you.
3. We clear the stored input and output text and write a deletion receipt: who asked, when, why, and the legal basis.
4. The hash can't be changed afterward without breaking the chain. Digests and hashes stay. Asking to delete also clears the free-text reason, target, outcome, and error text. The stored hash stays, so the chain still links.

The Agentics browser extension (/extension/) captures conversation turns from LLM-chat surfaces (claude.ai and chatgpt.com today; gemini.google.com and others as opt-in). This addendum is what the Chrome Web Store / Microsoft Edge Add-ons / Firefox AMO reviewers point at.

1. The content script captures a turn after both halves of a (user → assistant) exchange land in the DOM.
2. The redactor replaces matched PII with placeholder tokens client-side.
3. The service worker canonicalizes the receipt body (RFC 8785 / JCS) and signs it with the device's Ed25519 key.
4. The signed body is POSTed over HTTPS to https://agentics.you/v1/receipts/extension with the user's session JWT.
5. The backend writes the row to ledger_events with capture_source='extension'. The Merkle anchor job, which runs every 30 minutes, posts the batch root to Solana mainnet via the public anchor wallet CR6sxx8d9jR4AF4hvyQy3bbcAghGyS7gd4sGQvDmMqq4.
6. The receipt becomes verifiable at https://agentics.you/ledger/tx/<receipt_id> permanently.

• Captured conversation original text: kept locally inside the extension for 30 days, then expired automatically. Never transmitted to our servers in original form.
• Anchored hash + receipt metadata: kept in our database for the life of the account; on-chain hashes remain immutable (immutability is the product).
• Telemetry: 13 months.
• Account deletion: tombstones the row immediately, purges the local DB copy after 30 days, on-chain hashes resolve to "deleted by user" in our UI.
• Export: Settings → Privacy → "Export all my data" returns a JSONL bundle of everything we hold.

• Neon — Postgres, encrypted at rest, hosted in AWS us-east-1 (US).
• Solana mainnet — Public verifiable ledger (anchor hashes only, never receipt content).
• Resend — Email verification + digest emails.

Full sub-processor list at /security/subprocessors.html. The extension does not send anything to advertising networks, model training pipelines, or any party not on that list.

The Agent Bond, seller payouts and paid contracts are not offered. This section describes the data we keep from identity checks and Sign in with X that were done earlier, and how we would handle them if those features return.

• Verified person / Verified business. When you ask for an identity check, a vendor (Persona, Stripe Identity, or Didit, whichever is selected) performs it. We store the vendor reference, the result, and whether it was a person or a business. If you agree, we also store a public business name. We do not store the identity document, date of birth, street address, or an identity number.
• Owner on X. Sign in with X is a social signal, not an identity check. We store X's stable user id, the current handle, whether X marked the account verified, and when the X account was created (so we can show its age). We do not store X access tokens. We do not invent an email for an X login. The handle can change; the user id is the key. This signal does not make you a Verified person.
• State. If you tell us your US state during the identity check, we store that two-letter code so a later real-money path can refuse states we do not serve. We do not show it on the Bond page.
• Sanctions. Before a seller is activated, and again before a claim is filed or paid, we screen the payout account. The local list is the OFAC digital-currency address list and is always checked. When sanctions screening is on, an Ethereum or Base address is also checked on the public Chainalysis sanctions oracle. A hit blocks the payout. We do not publish the account on the Bond page.

Identity-check vendors and the sanctions vendor are sub-processors for those requests only. The Bond page shows "Owner on X: @handle" when an X account is the only signal, and "Verified person" only after a completed ID check. A completed business check shows "Verified business" plus the public business name you agreed to. An owner with neither shows "Self-declared". It does not show the vendor, a tier number, or the underlying personal data.

This is the data a connected agent writes through the MCP connection. It is separate from the extension path above.

OAuth grants. We store the client id and the scopes that were allowed. A grant bound to an agent stores that agent and the workspace, and leaves the account id empty. A grant that is not bound to an agent stores the account id. Access tokens and refresh tokens are stored as hashes. The token strings are not stored. Authorization codes are stored as hashes, marked used, and they expire. Reuse of a refresh token sets revoked_at on that token family and stops that family from issuing new tokens. It does not delete receipts or stored text.

Revoking a connection. Revoking a connection only sets revoked_at on the live tokens for that client and that agent. It does not delete those token rows. Receipts and stored text stay until the retention window or an explicit erase. Revoke does not delete them and does not purge them. The retention window is 90 days unless that workspace has a retention_days setting. After the window, the short text and the reason, target, outcome, and error text are cleared, and the receipt row stays. An explicit erase deletes the receipt rows. activity_erase_agent deletes the rows for one agent. activity_erase_tenant deletes the rows for one workspace. Each writes an erasure record and does not write a receipt. No console page and no support form calls either function. Delete this account on Settings anonymizes the account and removes its sessions and app connections. It does not erase receipts. To ask for a deletion of stored text, follow How to ask for deletion.

OAuth audit log. Token issue, refresh-token reuse, and revocation are written to the audit log with the client id, the grant type, the token family, and whether the refresh token was reused. The client IP address is handed to that writer and is not stored, so it has no retention period.

Receipts. A tool call can write a receipt. The receipt hash covers digests of the scrubbed inputs and outputs, plus a set of fields that includes the action label, the reason, the target, the outcome, and any error text. The hash does not cover a full copy of the tool payload. Beside the hash, we may keep the first 240 characters of the scrubbed inputs and the first 240 characters of the scrubbed outputs. Emails, phone numbers, card numbers, government ids, and keys are removed before that text is stored. An http or https address in that text, in the question sent to the owner, and in the action label loses its credentials, query string, and fragment. A record_action target that is a postgres, mysql, mongodb, redis, or amqps connection string keeps only the scheme and host. The action label is scrubbed the same way and is kept when that other text is cleared, because it is part of the hash. After the retention window (90 days unless the account sets another) or a deletion request, the short text and the reason, target, outcome, and error text are cleared, and text_cleared_at is set. The stored hash is not rewritten. The digests stay, so a later check can still link the receipt. A receipt that was already anchored stays anchored. When a receipt has no recorded time, the window is counted from created_at, or if that is also missing, from the earliest of the logged, started, occurred, and finished times. A receipt with none of those times is left unchanged.

Retrieval feedback records: when memory feedback is on for your organization, we keep which memories a search returned, which were used and how the task turned out, as identifiers and hashes without their text, for 13 months, and after that only monthly counts.

Funnel rows. Launch counters are separate from a connected agent. One table holds an integer per Pacific day and event name, with no cookie, IP address, or account id. Another stores an event name and a subject id that is already public on a check URL, and no task text.

On-chain anchors. A Solana transaction memo carries the Merkle root, which is a hash, and the chain records the transaction signature. Receipt text is not written on chain.