Where Does Your Data Go When an "AI Pentest" Runs?

When a vendor sells you an “AI-powered” penetration test, ask one question before you sign: where does my data go? The pitch is always speed and cost. The part nobody volunteers is custody. In a lot of AI-driven engagements, your source code, your scope, your architecture notes, and the findings about your weaknesses are sent to a third-party model you never chose, sometimes without anyone asking you first. Speed is easy to measure. Where your data went is not, until it matters.

The question the pitch skips

“AI-powered” has become a booth slogan. It gets used to describe two opposite setups that happen to share a label: a firm that built and runs its own model on infrastructure it controls, and a firm that quietly routes your engagement through someone else’s cloud API. To the buyer, both say “AI.” Only one of them can tell you, with certainty, where your data spent the night.

That distinction almost never comes up in the sales conversation, because it complicates a clean story. It is a lot easier to say “our AI works your whole attack surface in parallel” than “your repository and our list of your exploitable flaws were processed by a model operated by a company you have no contract with.” Both can be true at once. You just have to ask.

What actually leaves your environment

It helps to be concrete about what “processed by AI” can mean during a test. Depending on how a vendor is built, an outside model may receive:

Reconnaissance output: your external footprint, hostnames, technologies, and exposed services, assembled into one tidy profile.
Source and configuration: snippets, or in some workflows entire repositories, plus infrastructure-as-code and architecture notes that describe exactly how your systems fit together.
The findings themselves: the single most sensitive artifact of the whole engagement. A validated finding is not a vague warning. It is a step-by-step description of how to compromise you.

That last one deserves emphasis. The output of a good penetration test is a map to your weaknesses. If that map is generated by, or passed through, a third-party model, it can end up in that provider’s logs, retained for “abuse monitoring” or model training, or reachable by a legal process aimed at a vendor you never signed anything with. The value of the test and the sensitivity of the test are the same document.

Why custody is the real risk

For a lot of organizations, this is not an abstract privacy preference. It is a compliance and contractual problem.

Regulation. Data-residency rules, HIPAA, PCI DSS, CMMC, and similar frameworks care a great deal about where regulated data goes and who processes it. “We sent it to an AI to speed things up” is not a control your auditor will love.

NDA and data handling. You signed an NDA with your testing vendor. Did that vendor sign a matching agreement with its model provider? Does it forbid training and retention? If the vendor cannot answer, your confidential data may be governed by a consumer API’s terms of service rather than the contract you negotiated.

M&A and diligence. Some of the most sensitive testing happens during an acquisition, on a target’s confidential systems. Routing that data to an outside model, mid-deal, is exactly the kind of exposure a deal team exists to prevent.

“The AI is fast” does not answer any of these. The question underneath all of them is simple: who is now holding a description of how to break into you, and did you agree to that?

The honest position is not “we never touch the cloud.” That would be posturing, and it would not be true for everyone. Sometimes a frontier model is genuinely the right tool for a hard problem, and some clients specifically want that horsepower on their engagement. Ruling it out entirely is its own kind of dishonesty.

The honest position is that it is your call, made on purpose, not a default buried three layers down in a vendor’s pipeline. Private by default. An outside model only when you ask for it, knowing what leaves and to whom. Where your data goes should be a decision you made, never one that was made for you.

How we handle it

This is a large part of why we built our own engine instead of renting someone else’s. Every Alpha Defense engagement runs on Argus, our proprietary AI, built in-house and run on hardware we own and operate. By default, your data, your code, and your findings stay in our environment and do not leave for a third-party AI cloud. If you want the added reach of a frontier model on your engagement, we can enable that, but only at your direction and with your explicit consent. Where your data goes is your decision, every time.

That is not a limitation we work around. It is the point. It is what lets us give you the reach of automation without asking you to give your data away to get it.

Questions to ask any AI-using vendor

You do not have to be technical to hold a vendor to this. Ask five things, and listen for whether the answers are specific:

Whose model runs my engagement, yours or a third party’s?
What exactly is sent to it: reconnaissance, source code, the findings?
Is anything retained, logged, or used to train a model, and for how long?
Do you have a data-processing agreement with the model provider that matches the NDA you signed with me?
Can I choose private-only, and is that the default or an upgrade?

A vendor who answers these plainly is one you can trust with the map to your weaknesses. A vendor who reaches for “it is all very secure, don’t worry about it” has answered a different question than the one you asked.

The AI conversation in security has been stuck on price and speed. The more important question, especially if you are regulated, under NDA, or in the middle of a deal, is custody. Fast is good. Fast and private, on your terms, is the standard you should be buying to.

Want testing that keeps your data under your control by default? Talk to an expert about how we scope it.