Security and data handling

What we store

• Titles of your pages and articles in Notion, GitHub, Zendesk and Intercom, and their classification (which repo or changelog they follow, whether they are watched).
• For a changelog URL a help center follows: the URL and, for each dated entry, its title, date, link and text. Nothing else from the page is kept.
• Short summaries the model writes about code changes (a few sentences plus the changed file paths and a link to the commit or release), not the raw code.
• Each correction: the model’s draft, the text that was applied, the section or blocks it replaced, and the change summary and source link behind it. Original and revised text are kept for review and undo, in plain text protected by the database provider’s disk encryption.
• A one-line index of the claims your pages make about your code (for example “the API allows 60 requests a minute”), written by the model in its own words, never copied page text. It is encrypted at rest and deleted when you stop watching the page.
• For repos a page maps as Background only, we cache a rendered snapshot of the README and selected source files at each head commit. A generation job also stores repository context, which can include selected source files, and its drafted output.
• For a cleanup: each page’s outcome and confidence, the names searched, and references to the proof (repo, commit, file path, tag). Each page’s reason and guidelines are encrypted at rest. No page text and no code is stored.
• For a diagram: the graph the model designed (names and connections), its layout, and the image and SVG rendered from it, in private storage. A deleted diagram’s files are removed 30 days later.
• Your team, members’ email addresses, and settings (writing style, timezone, review mode).

Code at rest during a run

• A cleanup copies each repo you pick, with its full history, to a temporary folder on our server. It copies one repo at a time, searches it, and deletes the copy when that repo’s search ends, whatever the outcome. Copies left by a crash are deleted when the server starts. The code lines a search finds are held in memory for the run and never stored.
• Reading or writing a GitHub wiki uses a short-lived copy of the wiki in a temporary folder, deleted when the read or write ends.
• Daily checks, change previews requested through the API or MCP, and generation read what they need through GitHub’s API. They do not copy the repo to our server.
• Diagrams are rendered on our server. The model designs a graph of names and connections; our server lays it out and draws the image with Graphviz. The model never produces the image.

What we do not keep as a full copy

• Routine checks do not keep a full snapshot of every watched page or article. The full read is discarded, but correction records and audit events retain relevant original and revised text. An affected section can contain much of a short page. We also keep an encrypted claim index and page and section hashes. Generation drafts are stored separately.
• Raw code diffs. They are fetched and processed, then discarded; change summaries and source links are kept. Selected source files can be stored in repository context as described above.
• A cleanup’s copy of your repo. It is deleted when the search of that repo ends.
• Your card details. Billing runs entirely through Polar’s hosted checkout (see Payments).
• A long-lived GitHub token. We store only the installation id and mint short-lived tokens per request from the app’s key.

Which model, and what we send it

Amendary uses Anthropic’s Claude through Anthropic’s API. The model selected for a task can change with configuration. Depending on the task, we send the model a code-change summary or diff, a page’s text (the whole page when its claim index is built, the matched sections when it is checked), the claim index, a repository README, or release notes. A cleanup sends each page it checks and the matching lines and commits its search found. A diagram suggestion sends the page and the repo’s code context. Every input that comes from your data is wrapped and marked as untrusted content to reduce prompt injection risk. We do not fine-tune models on your content or keep embeddings. A per-team daily usage limit, set by Amendary, caps use and pauses checks until the team’s next day if it is reached. Under Anthropic’s Commercial Terms, Anthropic may not train models on our customers’ content. It deletes API inputs and outputs within 30 days, unless they are flagged for a breach of its usage policy (kept up to 2 years), the law requires longer, or we agree otherwise (checked 29 October 2026).

A workspace owner can set the team’s own Anthropic API key. While Anthropic accepts it, every model call for that team uses the team’s key and is billed to the team’s Anthropic account, not made through Amendary’s key, and the daily usage limit above does not apply. The key is encrypted before it is stored and is never shown again after saving; Settings shows only its last 4 characters. If Anthropic refuses the key, a team without a subscription has its checks paused and is never switched to Amendary’s key; a subscribed team falls back to Amendary’s key and its plan until the key is fixed or removed.

How your data flows

You sign in through Supabase using Google or GitHub. Email-and-password sign-in exists only as an explicitly enabled development option and is not offered by the production sign-in page. Your sign-in identity is separate from the GitHub App installation that you connect to let a workspace read repositories. You can also connect Notion, and sign in to Zendesk or Intercom. Once a day we read what shipped from GitHub or a changelog URL, match each change against the claim index of your watched pages and articles, ask Claude whether the matched sections are now wrong and how to fix them, and store the summary and the proposed change. The correction is then applied or held for review by the rules in Queue & reviews. Whole pages and raw code diffs pass through our server’s memory and the Anthropic API. The full page read and raw diff are discarded; correction records can retain page excerpts and replaced blocks. Background repos and generation context can retain selected source files. Stored data lives in Supabase Postgres; payment data lives only at Polar.

If a help center follows a changelog URL, our server reads that page or feed once a day. It fetches public addresses only, never one inside a private network, and keeps only the dated entries described above.

GitHub access: reads always, docs writes only where you turn them on

The GitHub App reads repository contents and metadata to see what shipped. It writes to a repo only when you turn on GitHub docs for that repo; a repo with it off is never written to, and settings are never changed anywhere. When you turn it on, you choose where docs are written (a docs folder or the repo wiki) and whether changes are opened as a pull request you review and merge (the default) or committed directly. We never touch a repo you have not enabled, and we never change code, only the docs you point us at.

Zendesk and Intercom access

• You connect by signing in at Zendesk or Intercom (OAuth). Zendesk access is limited to Help Center content (hc:read hc:write). Intercom access is limited to reading and writing articles.
• We read your articles, their translations, and the categories, sections or collections that hold them. We write approved fixes to the article body, drafted translations, and new articles from Generate docs. New translations and new articles are always saved as drafts. A fix never changes whether an article is published.
• Zendesk access and refresh tokens, and the Intercom access token, are encrypted before they are stored.
• When an owner disconnects, we ask the provider to revoke our access, then delete the stored tokens, the watched articles and their fixes. If the provider cannot be reached, the tokens are deleted anyway. An Intercom app another Amendary team also uses stays installed for that team.
• If you remove the Amendary app inside Intercom, Intercom tells us, and we delete the stored token and that help center’s data.

Controlled edits, full audit trail

Every applied change records the model draft, the applied text, the exact text it replaced, and its evidence (the release or diff) in an append-only audit log. New workspaces start on Review first for both audiences, trials are review-only, and the rules for what auto mode applies and what it holds are in Queue & reviews.

Undo lives in Amendary: for 30 days after a correction is applied it restores the stored original text after a conflict check, on every Notion plan (see how undo works).

Isolation and access control

Workspace owners can create API keys for the scoped REST and MCP surfaces. The raw key is shown once; Amendary stores only its hash, a short identifying prefix, creation and last-used times, and revocation state. Each key is bound to one workspace, is rate limited, and can be revoked immediately. API and MCP reads cannot edit documentation, resolve a correction, change settings, or spend model budget. Owners can separately grant checks:run for documentation previews over GitHub-resolved pointers. These consume bounded model tokens, keep every review hold, and never publish. We store request pointers, immutable SHAs, outcomes, idempotency keys, note hashes and token reservations. Raw notes are not stored or sent to a model (see API and MCP).

Every team’s product data is isolated. Workspace-scoped tables have Postgres Row Level Security enabled, and the Supabase Data API roles have no privileges on them, so product data cannot be reached through that API. The application backend uses a privileged database role, so its verified membership checks and workspace filters are the primary tenant boundary; integration tests exercise that boundary. Database constraints also prevent a page and a repo from different teams being linked. On every authenticated API request, the backend verifies the issuer, audience, expiry, signature, and user id of the Supabase token. Production accepts tokens signed with the project’s asymmetric keys; legacy shared-secret tokens require an explicit non-production configuration.

In transit and at rest

All traffic between your browser, our servers, and the services we connect to is encrypted over HTTPS. OAuth access and refresh tokens, the claim index and a team’s own Anthropic API key are additionally encrypted by the application before they are written to the database, using authenticated symmetric encryption with a key held separately from the database, so they stay protected even in a database backup. Other stored data is protected by the disk encryption of our database provider (Supabase) and host.

Subprocessors

The providers that process data for us, and what each sees:

• Anthropic (Claude API): the code-change summaries, page and article text, READMEs, release notes, changelog entries, code context and cleanup search results we send for a check, a generation, a diagram or a cleanup.
• Supabase (EU, Ireland): hosts our database, sign-in and private file storage; holds everything under “What we store” (diagram files included), your account email, and your Google or GitHub sign-in identity.
• Sliplane: runs the application and terminates HTTPS. A cleanup’s temporary repo copy lives on its disk for the length of that repo’s search.
• Polar (merchant of record): payment, tax, and invoicing through their hosted checkout.
• Resend: if outbound email is enabled, receives the recipient address and the content of team invitations, welcome messages, and notification emails you have enabled (weekly digests, review reminders, and trial reminders).
• Cloudflare Web Analytics: measures aggregate visits to the public marketing site without cookies. It is not loaded in the signed-in product. We run no advertising pixels or session replay.

Regions and transfer safeguards are listed in the Privacy Policy. A Data Processing Addendum (DPA) is available on request at hello@amendary.com.

Platforms you connect

These are not our subprocessors. You choose and connect them, and they process your data under your own agreements with them. We read and write there only with the access you grant.

• GitHub: the source of your code. If you turn on GitHub docs for a repo, we also write docs (a folder or the wiki) to that repo, never its code.
• Notion: the source and destination of your docs; we read watched pages and write corrections, comments and the diagram images you add through the public API. Notion does not offer integrations a suggested-edit mode, so an applied correction is a direct edit, logged and reversible in Amendary.
• Zendesk Guide: we read the articles and translations you watch and write approved fixes, drafted translations and draft articles to them. Access and refresh tokens are stored encrypted.
• Intercom Articles: we read the articles you watch and write approved fixes, drafted translations and draft articles to them. The access token is stored encrypted; removing the app in Intercom deletes it.

Retention and deletion

An owner can export the team’s data or delete the team at any time from Settings. Deleting a team uninstalls the GitHub App (unless the same installation is shared with another team), revokes the Notion access token at Notion, asks Zendesk and Intercom to revoke Amendary’s access (an Intercom app another team also uses stays installed), removes the Polar customer, and deletes all of the team’s records. You can also disconnect a single connection. A Zendesk or Intercom disconnect revokes Amendary’s access at the provider. A GitHub or Notion disconnect removes it from Amendary only; to also revoke access there, remove Amendary in your GitHub or Notion settings. We do not currently apply a fixed time limit to operational logs and the audit trail; they are kept until the team is deleted, then removed with it.

Deleting your personal account removes your memberships and deletes teams for which you are the sole owner. It also removes the Supabase sign-in identity when the production service-role integration is available; if that final step fails, the product reports it and directs you to support. Provider logs and database backups age out according to each provider’s retention settings, so deletion from live systems does not imply immediate erasure from backups.

Payments

Billing is handled entirely by Polar, our merchant of record: their hosted checkout and customer portal process payment, tax, and invoicing. We store only a customer reference and order records, never your card details.

Reporting a security issue

If you believe you have found a security issue, please email hello@amendary.com rather than filing a public issue. We will acknowledge reports as quickly as we can.