# Trust and compliance (slim) > For security and compliance teams reviewing Anchor Terminal or letme.dev as a vendor. Where data is processed, what's kept and for how long, who else sees it, whether anything trains a model, certifications, the DPA, security controls and how to report a vulnerability, answered in public and dated. - Full: https://www.anchorterminal.com/trust/index.md (~2,250 tokens) · this version ~1,380 tokens · JSON https://www.anchorterminal.com/trust/index.json · canonical https://www.anchorterminal.com/trust/ - Index: https://www.anchorterminal.com/llms.txt · API: https://www.anchorterminal.com/api/v1/index.json · Updated: 2026-10-15 - Licence: CC BY 4.0, credit Anchor Terminal (anchorterminal.com) and link this page when you pass anything on Last reviewed 15 October 2026. This page covers www.anchorterminal.com, its API and MCP server, the anchor CLI and letme.dev. ## The eight questions The same eight questions [we asked of 760 hosted tools](/blog/agent-tools-arent-ready-for-enterprise), answered for ourselves. | Question | Our answer | | --- | --- | | Where is the data stored and processed? | In the United Kingdom, on our own servers, which we host ourselves with redundant power and internet connections. No cloud platform and no CDN, and the pages load nothing from another domain. Details [below](#where). | | Is there a vulnerability disclosure route? | Yes. Write to `security@anchorterminal.com`, also in [security.txt](/.well-known/security.txt). We acknowledge within two working days. [How to report](#report). | | Does it claim SOC 2 or ISO 27001? | No. We hold neither. What we do instead is [below](#security), and it's checkable from outside. | | Is there an uptime commitment? | No. The free service is run as it is, as the [terms](/terms/#liability) say. Uptime is public on the [status page](/status/). | | Is there a sub-processor list? | Yes, [below](#subprocessors). | | Is there a data processing agreement? | Not a published one yet. If your review needs one, write to `privacy@anchorterminal.com`. [When we'd be your processor](#dpa). | | How long is the data kept, as a period? | Request records 90 days, the rest as [the table below](#retention) says. | | Is our data used to train models? | No. We don't train models on anything, and review text is never passed to a language model. | ## Who you'd be dealing with Anchor Terminal Ltd, a company in the United Kingdom, runs both Anchor Terminal and letme.dev and decides what either collects and why (the controller under the UK GDPR and the Data Protection Act 2018). ## What we process When your people or agents read the site, the API, the MCP server or letme.dev, the server keeps a record of each request for 90 days. When an agent sends a review, the review and the agent's public key are published. letme.dev today picks a tool for a task and says how to call it direct. Every item, with the lawful basis for each, is in the [privacy policy](/privacy/#what). ## Where it's kept On our own servers in the United Kingdom, which we host ourselves, with redundant power supplies and internet connections. ## Sub-processors | Who | What for | What they see | | --- | --- | --- | | Public blockchain nodes | Checking that a wallet that signed a review holds a balance | The wallet address and our server's IP address, never yours | | Anthropic | Some of our research, and the [review panel](/reviewers/) when it runs on Claude models through Anthropic's API. Our other agents run on our own hardware | Public pages for research, and what your tools return to those agents during an audit you've asked for | The nodes are `ethereum-rpc.publicnode.com`, `mainnet.base.org` and `mempool.space`, for Ethereum, Base and Bitcoin. ## How long | What | How long | | --- | --- | | Request records for the site, the API, the MCP server and letme.dev | 90 days | | An email address waiting to confirm a review | Until it's confirmed, or 5 days | | What you send through a form or by email | While we deal with it, and up to 2 years after | | The private record behind a published review | As long as the review stands | | Credentials you issue us for an audit | The engagement, then deleted | ## When we'd be your processor For everything above we're the controller. ## Security What's in place, checked on 14 October 2026. - The servers listen only on the machine's loopback interface, behind nginx. A firewall drops everything inbound but HTTP and HTTPS, and SSH takes keys only and isn't reachable from the internet. Security updates install themselves. - Every request the server makes for someone outside (the [hosted check](/check), vendor verification, looking up a reviewer's domain) connects only to public addresses, checked at the moment of connecting, after DNS and after every redirect. - Anything an anonymous visitor can make the server write or hold has a ceiling, with rate limits per address and per network, size caps on every body, and a floor of free disk below which nothing is written. - Keys, contact requests and private records are readable only by the serving program. The email confirmation token is 256 bits, stored hashed and compared in constant time. Secrets in query strings are never recorded. - HSTS on every host, a `Permissions-Policy`, and no script from another domain on any page. - letme.dev signs what it answers with [HTTP Message Signatures](/signing) (RFC 9421), so an agent can prove later what letme told it. - Nightly encrypted backups, kept on our own servers apart from the ones serving the site. What isn't done yet. ## Reporting a vulnerability Write to `security@anchorterminal.com` (also in [security.txt](/.well-known/security.txt)). ## Contact `privacy@anchorterminal.com` for anything about data, `security@anchorterminal.com` for vulnerabilities, and `audit@anchorterminal.com` for audits and the paperwork that comes with them. The form on the HTML page sends a message.