Security and data handling
Reflects the current implementation
Amendary reads your code and writes to your documentation, so you deserve a plain account of what happens to your data. This page describes what the system does today, not aspirations. Questions we do not answer here go to hello@amendary.com.
What we store
- Your Notion page titles and their classification (which repo they describe, whether they are watched).
- 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 block it replaced, and the evidence behind it, so every change is reviewable and reversible.
- For repos you mark as background context, and for the one-time “docs from scratch” add-on, we cache selected source files and the README so we do not refetch them each run.
- Your team, members’ email addresses, and settings (writing style, budgets, review mode).
What we never store
- The full text of your Notion pages. It is read into memory for a check and discarded; only a short one-way hash of each model input is kept, for cost accounting.
- Raw code diffs. They are fetched, summarized, and dropped; only the summary is kept.
- 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 (currently the Sonnet model) through Anthropic’s API. Depending on the task, we send the model a code-change summary or diff, the current text of the page being checked (capped), a repository README, or release notes. Every input that comes from your data is wrapped and marked as untrusted content, so a page or a commit message cannot issue instructions to the model. Anthropic does not train its models on data sent through its API, and we make only ordinary API calls: no fine-tuning, no training, no embeddings kept. A per-team daily token budget caps spend and pauses checks if it is reached.
How your data flows
You sign in through Supabase (Google or email). You connect GitHub and Notion. Once a day we read what shipped from GitHub, read your mapped Notion pages, ask Claude whether a page is now wrong and how to fix it, and store the summary and the proposed change. A confident, complete-context correction is applied to the Notion page directly (or waits for your approval if you turn that on, if the context was incomplete, or if the correction removes a value the change does not mention). Whole pages and raw code diffs pass through our server’s memory and the Anthropic API but are not stored; what we keep is the model’s change summary and, for a correction, the exact block it replaced and the new text, so the change stays reviewable and reversible. Stored data lives in Supabase Postgres; payment data lives only at Polar.
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 committed directly or opened as a pull request you review and merge. We never touch a repo you have not enabled, and we never change code, only the docs you point us at.
Controlled edits, full audit trail
By default Amendary applies confident, complete-context corrections to your mapped Notion pages directly. Every 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. Corrections built from incomplete context, without a drafted edit, or that remove a value the change does not mention, are never applied on their own; they wait in the review queue. A team setting switches the workspace to review mode, where nothing is written until a person applies it.
Undo lives in Amendary. For 30 days after a correction is applied, the queue offers an Undo that restores the stored original text after checking the block has not been edited since. It works the same on every Notion plan. Notion’s own page history is an additional safety net, but its retention depends on your Notion plan and it is only available in the Notion UI, so we do not treat it as the undo.
Isolation and access control
Every team’s data is isolated. Each application table is scoped to a team and has Postgres Row Level Security enabled; the backend filters by your verified membership on every query, with Row Level Security as a backstop. The Supabase Data API roles hold no privileges on this data, so it cannot be reached over that API at all, and the database enforces that a page and a repo from different teams can never be linked. Sign-in tokens are verified with asymmetric signatures on every request.
In transit and at rest
All traffic between your browser, our servers, and the services we connect to is encrypted over HTTPS. OAuth access tokens 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 third parties that may handle your data, and what each sees:
- Anthropic (Claude API): the code-change summaries, page text, READMEs, and release notes we send for a check.
- Supabase: hosts our database and sign-in; holds everything under “What we store” and your account email.
- 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 mapped pages and write corrections and comments 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.
- Polar (merchant of record): payment, tax, and invoicing through their hosted checkout.
- Our host: runs the application and terminates HTTPS.
- Email: only if enabled, and only for team invitations and the optional weekly digest.
We run no third-party analytics, advertising, or session-tracking on the product.
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, removes the Polar customer, and deletes all of the team’s records. You can also disconnect a single GitHub or Notion connection, which removes it from Amendary; to also revoke Amendary’s access at the provider, remove it from 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.
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.