Autopilot for Delphi – Security and privacy

Your Compliance or Risk team wants to know what Autopilot for Delphi can see, where your data goes and how to keep it under control. Here are the short answers.

In one sentence: Autopilot runs only on the developer’s own computer, only inside a test build of your own application, and it does not send your application’s data to us.

How it works

Autopilot has three parts:

  • The bridge – a few Delphi units that you compile into a test build of your application.
  • The Autopilot server (Autopilot.Mcp.exe) – a small program that your AI assistant (for example Claude Code) starts on the developer’s PC.
  • A local Windows named pipe between the two. The pipe works only on the same computer, and only for the same Windows user.

The AI assistant asks, the Autopilot server passes the request through the pipe, and your application answers.

What Autopilot can read

Autopilot cannot read your application’s memory freely. It does only what its tools allow:

  • list the forms and controls (their names and types);
  • read the text or caption of a control;
  • read and change the published properties of components – the properties you see in the Object Inspector;
  • take a screenshot of a form;
  • click buttons, type text and close dialogs.

It cannot read private variables, files, databases or other programs. What your application shows on a form, or keeps in a published property, the AI assistant can see – exactly like a tester sitting in front of the screen.

Where the data goes

  • To your AI assistant. The answers (texts, property values, screenshots) go to the AI assistant, which sends them to its AI provider (for example Anthropic) as part of the conversation – the same as any code or text the developer shares with it. Your agreement with the AI provider covers this part.
  • To a local log. Autopilot writes a log on the developer’s PC, in %TEMP%\Autopilot\. The log of the Autopilot server holds the requests and the answers. It stays on the PC; delete it whenever you like.
  • To us: only a crash report, and only if the Autopilot server itself crashes. The report goes to our server over HTTPS. It holds the error, the program’s call stack, basic system details (Windows version, computer name, Windows user name) and a short raw dump of the program’s stack, which in rare cases could hold a fragment of the data the server was handling at that moment. It never holds the log or a screenshot.

How you keep it under control

  • Test builds only. The bridge is compiled in only when the compiler define AUTOPILOT is set. Put it in a test build configuration. A release build without the define has no bridge and no pipe at all.
  • Test data only. Autopilot sees only what your application has loaded. Point the test build at a test database with synthetic data, and that is all the AI assistant can see.
  • One project only. claude mcp add autopilot -- <path>\Autopilot.Mcp.exe uses Claude Code’s default “local” scope: the Autopilot tools load only in the project folder where you ran the command (Claude Code documentation, “MCP installation scopes”). The instructions for the AI, AI-INSTRUCTIONS.md, go into the project’s own CLAUDE.md. Nothing needs to go into a global configuration.
  • Only your application. The tools reach only an application that was compiled with the bridge. Other programs on the computer are out of reach.
  • Read the code. The bridge comes as source code with your seat, so your team can review exactly what it does. It never connects to the internet.

More questions from your Compliance team? Write to us at I@GabrielMoraru.com – we are happy to answer.

Scroll to Top