This is a product-class write-up, not a named-client story and not a results press release. Counts below describe the pack we actually write (approach points, tools, layers) — not invented bug totals or conversion lifts.
Overview
The agent’s “fix my build” path added a plausible npm/pypi package that was not on the registry at test time. That is a supply-chain incident waiting for a squatter.
A second path echoed a GitHub token that had appeared in a prior trace the model could see.
Research on HalluSquatting shows coding agents will invent repository and package names at high rates. Adversaries register the invented names. Generated config that embeds secrets from traces is a second, quieter failure.
Highlights
- Registry resolve before install
- Secret non-reproduction from traces
- Docs vs live API contract tests
Typical launch bar: Wait until journeys and evals agree — do not ship on demo scores alone.
Challenges
The agent had network on by default in CI, so a hallucinated install could have succeeded after squat.
Docs showed an API that did not match the live OpenAPI — the agent copied the docs.
Developers wanted autocomplete speed more than resolve checks.
How we tested
Generated install commands must resolve against the real registry or fail. No “this is probably the package.”
Secrets scanners on generated files; tokens from traces must not reappear.
Webhook signatures and token revoke on the product’s own install path.
Published rate limits behave as documented (429 + Retry-After).
Starting point vs what we required
| Starting point | What we required |
|---|---|
| The agent had network on by default in CI, so a hallucinated install could have succeeded after squat. | Generated install commands must resolve against the real registry or fail. No “this is probably the package.” |
| Docs showed an API that did not match the live OpenAPI — the agent copied the docs. | Secrets scanners on generated files; tokens from traces must not reappear. |
| Developers wanted autocomplete speed more than resolve checks. | Webhook signatures and token revoke on the product’s own install path. |
What we delivered
Adversarial evals
- Promptfoo — Invented package names and secret-echo
API / contract
- Postman — Webhook signatures, replay, revoke
Journeys / UI
- Playwright — Install → first successful action
Dependency review
- Snyk — Dependency and generated lockfile review
CI regression
- GitHub Actions — CI eval on agent prompt changes
Outcomes
Allow-listed package sources and a resolve-before-install hook. Secret-echo evals on generated Docker/env samples.
We tested the product’s webhook signature and revoke flows with Newman — the agent was not the only risk.
Stack
| Layer | Tool | What we validated |
|---|---|---|
| Adversarial evals | Promptfoo | Invented package names and secret-echo |
| API / contract | Postman | Webhook signatures, replay, revoke |
| Journeys / UI | Playwright | Install → first successful action |
| Dependency review | Snyk | Dependency and generated lockfile review |
| CI regression | GitHub Actions | CI eval on agent prompt changes |
Same method as the rest of our work: severity-ranked findings, pass rules in writing, and a ship / wait / block call. See the evaluation method and tool comparison.