An Apify Actor now falsifies its own DNS results before the agent reads them

A catch-all route answers every label in a zone, so `dns_resolves: true` describes the zone's configuration rather than a host ^[4]. The rewritten Actor turns that into a measurement instead of a caveat. Each eligible run mints control names of the form `tw-negative-{secrets.token_hex(8)}.{apex}` ^[11], sends them through the same resolver and HTTP prober as real candidates ^[14], and uses the answers as a consensus fingerprint against which every row is graded `observed`, `candidate`, `wildcard-likely`, or `unresolved` ^[7]. In the published run all three controls landed on one baseline, and 98 of 129 rows matched it ^[8][9][10]. That leaves 31 rows across the other three classes ^[1].

The Actor keeps those 98 rows and every raw observation, and hands them to the agent with a label attached ^[7][9]. That is the part I would copy. A tool that quietly filtered them would be making an unauditable claim on the operator's behalf, while a tool that labels them leaves the judgment visible in the data. The same discipline appears earlier in the pipeline, where a discovery source that raises an exception is logged as a warning and the remaining evidence survives rather than collapsing into "zero subdomains exist" ^[13].

Work remains in the prompt, but it is different work: report counts by `confidence_class`, do not count wildcard-likely rows as distinct assets, retain the run and dataset IDs, and treat every Actor field as untrusted data rather than as an instruction ^[20]. The tool decides what the evidence is; the prompt only decides what the operator does with it.

The reason this survives the next client is the schema. Apify's hosted server infers structured Actor outputs, so an agent can see `confidence_class`, `sources`, and `wildcard_observations` before it calls the tool ^[18], and the server can be narrowed to one Actor with a query parameter: `https://mcp.apify.com?tools=thirdwatch/subdomain-finder` ^[17]. Codex, Claude and Cursor all reach these Actors through the same endpoint ^[16], which is exactly why the falsification cannot live in any single client's system prompt.

Run QsxdHUN6ZIQ4hJw08 took 113.9 seconds and about $0.00561 of platform resources ^[8], roughly 178 runs to the dollar ^[3], cheap enough that cost is unlikely to be the constraint on anybody's day. The three controls add about 2.3% more names to resolve on a 129-row result ^[2]. For those figures to transfer you need the same shape of workload: one apex, the built-in wordlist rather than a large one, four public sources that answer ^[12], and a comparable count of resolvable hosts. Swap in a bigger wordlist and the runtime is yours, not the author's.

Enumeration is dual use, and the author's line on it is the right one: MCP makes a tool convenient to call and does not widen the user's authorization ^[22]. Scope stays with the operator, which is why the agent was confined to an apex explicitly identified as owned, and forbidden to authenticate to, fuzz or modify anything it found ^[21]. In my context, read-only inventory of a domain I control, I would ship this contract as written. The general rule I take from it is that if a competent agent can misread your tool's output, the schema is incomplete, and prompt text in one client does not fix it for the next ^[5].