Auditing an AI tool you did not build

You did not build any of the software that now does part of your work. You cannot read most of it, and for the parts you could read, you never will. That is not negligence. It is the normal condition of running a business on other people’s tools, and it was true of your accounting software long before it was true of an assistant that writes your emails.

What changed is reach. A chat window sees what you paste into it. An agent installed on your laptop sees your files, your shell, your network settings and whatever credentials are lying around, and it phones home on a schedule you did not set. So the useful audit is not “is this vendor trustworthy”. It is three smaller questions you can actually answer in an afternoon: what can this thing reach, what does it send by default, and how would I find out if either of those changed. This guide is for one to ten people with no security function and no procurement process. If you have either, you have a vendor questionnaire already, and this is the short version of it.

Three kinds of tool, and only one of them can open your files

Sort every AI tool you pay for into three piles before anything else, because the piles have different failure modes.

The first pile is the browser assistant: ChatGPT, Claude or Gemini in a tab, reaching nothing on your machine beyond what you type, paste or upload into it. The whole audit here is the retention and training settings, which the vendors publish.

The second pile is the desktop or mobile app of the same thing. The policy questions are identical. The extra reach is whatever permissions you granted at install time, which your operating system’s privacy settings will list back to you.

The third pile is the agent: something that runs on your computer with permission to read files and execute commands. This is where reach becomes real. Claude Code, in its manual permission mode, starts read-only, asks before it edits files or runs commands that can modify your system, and can only write inside the folder it was started in and that folder’s subfolders [3]. It stores API keys and tokens in the macOS Keychain where available, and behind file permissions on Windows and Linux [3]. It also keeps a plaintext copy of your session transcripts on disk, under ~/.claude/projects/, for 30 days by default, adjustable with the cleanupPeriodDays setting [1].

Read that list again as an inventory of what an agent can see, because that is what it is. The folder you start it in is the boundary of the audit. Everything else in this guide is detail.

The defaults decide what leaves, and the defaults are published

Nearly everyone treats “what does this tool send back to the vendor” as unknowable. For the tools in question it is written down, in public, in ordinary sentences.

Claude Code sends two kinds of operational telemetry, and the documentation names both. Usage metrics covering latency, reliability and usage patterns are on by default when you connect directly to the Claude API, and the docs state that metrics never include your code, prompts or file paths; DISABLE_TELEMETRY=1 turns them off [1]. Error reports carrying messages and stack traces from the tool’s own internals are on only for Pro and Max sign-ins on version 2.1.198 or later connecting directly to the Claude API, with known patterns of secrets, file paths and email addresses redacted before anything leaves the machine; DISABLE_ERROR_REPORTING=1 turns those off [1]. Setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC turns off all non-essential traffic at once [1].

Two exceptions in that same document are worth more than the rest of it. Before fetching a URL, the WebFetch tool sends the requested hostname to api.anthropic.com to check it against a safety blocklist, it runs regardless of which model provider you use, and it is not affected by the non-essential traffic switch; you disable it separately with skipWebFetchPreflight in settings [1]. And the /feedback command sends a copy of your conversation history including code, retained for 5 years [1]. Neither of those is hidden. Both surprise people.

Retention follows the same pattern of published specifics. On consumer plans, allowing your data to be used for model improvement carries a 5-year retention period and declining it carries 30 days; commercial accounts sit at 30 days as standard [1]. Google publishes the equivalent for Gemini: a subset of chats is reviewed by human reviewers, disconnected from your account before being sent to service providers, and those reviewed chats are retained for up to 3 years, while chats you have with Keep Activity off are retained for 72 hours [7]. Google also states plainly that even with the setting off it still uses your chats to respond to you and to help protect Google, its users and the public [7].

The audit action here is not to turn everything off. It is to open each tool’s data page once, write down what the setting is today, and know which of your three piles the answer applies to.

Your agreement does not promise you will be told

Small operators assume the terms of service contain a disclosure obligation. They generally do not. Anthropic’s consumer terms reserve the right to “modify, suspend, or discontinue the Services or your access to the Services, in whole or in part, at any time without notice to you”, alongside a commitment to strive for reasonable advance notice if a Service stops being offered, and an acknowledgement that urgent situations can make notice unfeasible [5]. One notice period in that document is specific, and it is about money: if a change increases the fees payable by you, Anthropic says it will inform you at least 30 days in advance [5]. Your money gets a notice period. The software’s behaviour does not.

The same holds one layer down, for the other companies that touch your data. OpenAI publishes a public sub-processor list, last updated 9 July 2026, covering cloud hosting, content delivery, customer support, data warehousing and content moderation [6]. The change process is a form: you sign up to receive notification of new third-party sub-processors by filling it in [6]. That is a reasonable arrangement, and it is also entirely opt-in. Nobody is going to email you because you once bought a subscription.

So the practical version of vendor oversight, at your size, is a subscription problem rather than a legal one. Subscribe to the changelog, the sub-processor notification and the status page for the two or three tools you would genuinely struggle to replace. It is one sitting of setup, and it converts an unknowable into an inbox item.

Release notes are the audit surface almost nobody opens

The changelog is the cheapest control in this guide and the most ignored. Claude Code’s public changelog led with version 2.1.260 on the day this guide was checked, and entries are listed by version number with no dates attached [4]. That tells you two things. Releases are frequent enough that dates would be noise, and the record of what changed in the tool on your disk is a text file anyone can read in a few minutes.

It also tells you the limit of the control, which is the durable lesson of the case this guide exists for. On 1 July 2026, Anthropic was reported to be rolling back code in Claude Code that covertly tracked and transmitted information based on a user’s timezone and potential connection to Chinese tech companies accused of training their own models on Claude’s answers. A cybersecurity newsletter reported the behaviour, and an Anthropic employee called it an experiment [8]. Note what did the work there. Not a release note, not a policy page, not a contract clause. Someone outside the company noticed and published.

You are not going to read every release of every tool you run. What you can take from the case is a change in default assumption: a shipped feature can carry behaviour that is not described to you, at a vendor that publishes compliance artefacts through a public trust centre [3] and that treated the behaviour as an experiment [8]. Treat vendor documentation as accurate about what it covers and silent about the rest.

For anything you install rather than merely log into, the follow-on habit is version discipline. Know which version you are running, upgrade deliberately rather than automatically where the tool lets you choose, and read the entries between your old version and your new one. This matters most for the small pile of tools with file and shell access, and barely at all for the browser tab.

Blast radius is the part you actually control

Since verification is off the table, containment is the whole game, and the controls are boring and effective.

Start agents inside a project folder, never in your home directory. This is not just tidiness. Claude Code’s trust acceptance is held for the current session only and is not written to disk when you start it directly in your home directory, whereas trust acceptance is saved per directory when you start it from a project subdirectory [3]. The wider boundary also gives an agent, and anything that manages to talk to it, a much larger surface to work with.

Use the isolation the tool ships with. Claude Code offers a sandboxed bash tool with filesystem and network isolation, configured with /sandbox, and its security guidance suggests dev containers for additional isolation when working with sensitive code [3]. Commands that fetch content from the web, such as curl and wget, are not auto-approved by default and can be blocked entirely with a deny rule [3].

Be hardest on connectors. Third-party extensions are the part of your stack with the least oversight, and the vendor says so: Anthropic reviews connectors against its listing criteria before adding them to the Anthropic Directory, but “does not security-audit or manage any MCP server” [3]. Every plugin, connector or integration you attach is a separate supplier inheriting your agent’s reach. If you cannot name the maker, remove it.

Finally, keep credentials out of reach by construction rather than by policy. An agent that never has a directory containing your .env files in its working boundary cannot leak them, whatever it is told to do by a poisoned web page.

A fixed set of test prompts is how you notice a change at all

Everything above catches changes the vendor documents. The last control catches the ones it does not, and it costs almost nothing.

Write down 5 tasks you actually run: the weekly summary, the invoice extraction, the tone rewrite, whatever your real work is. Keep them in a file, with the exact inputs. Run them once a quarter and save the outputs with the date and the version number next to them. Then when the tool feels different in November, you have October to compare it against instead of a memory.

This is a smoke test, not a benchmark, and it should stay small enough that you keep doing it. Five prompts you run every quarter beat 50 you ran once. The signal you are looking for is not a score. It is the moment you read this quarter’s output next to last quarter’s and think, that is not the same tool.

If you also run your own telemetry, the same instinct applies to what you collect. Claude Code can export telemetry to an OpenTelemetry collector you control, off until you set CLAUDE_CODE_ENABLE_TELEMETRY=1, with prompt content redacted by default and separate opt-in flags, OTEL_LOG_USER_PROMPTS and OTEL_LOG_TOOL_CONTENT, before prompts or tool input and output are logged [2]. Turning those on gives you a record of what the tool did. It also creates a store of your prompts and file contents in your own infrastructure, which is a new thing to protect.

What still goes wrong

The largest gap is the one you cannot close. Models served from a vendor’s own infrastructure have no version number you can pin and no diff you can read. The behaviour of a chat product can change on a Tuesday with nothing in your hands to prove it did, which is exactly why the 5 saved outputs are worth more than they look. They are the only evidence you will ever have.

The second gap is that this audit reads documentation, and documentation describes what the vendor chose to describe. The July 2026 case is the honest illustration: the tracking was in a shipped Claude Code feature, and it reached the public because a cybersecurity newsletter reported it, not because anyone read a page like the ones cited here [8]. A published data-usage page is strong evidence about the things it covers and no evidence at all about the things it does not.

The third failure is the ordinary one. An audit becomes a ritual. You tick the seven boxes, change nothing, and file it. The test of whether this is worth your time is whether the last four quarters produced any action, a connector removed, a setting changed, a tool dropped. If they did not, either your stack is genuinely stable or you are not looking hard enough, and only one of those is likely.