Agent boundary review

One question, asked about your product: where does the thing that enforces the boundary take its parameters from?

Every serious AI-agent escape of 2026 had the same shape — the agent trusted something the repository supplied. The component enforcing the boundary runs in the environment it polices, and reads its parameters from untrusted input: a repository, an issue, a patch, a tool result. That makes these boundaries testable, and I have tested them on fourteen products.

What the review covers

• Git sink coverage — reproduce your hardening exactly (arguments + environment, from source or the shipped binary) and measure which execution sinks still fire. This is the check most products have, and the one most often incomplete in the same place.
• Approval-parser differentials — what the permission layer believes will run vs. what the shell actually runs. Prefix wrappers, shell option flags, quoting, permission derivation from attacker-influenceable paths.
• Agent configuration surfaces — MCP server declarations, hooks, permission files, environment channels, devcontainer lifecycle commands, instruction files.
• Repository-controlled execution surfaces — everything a directory you did not write gets to say.

What you get

• A report: per finding, the exact command, the A/B pair that proves it, and the fix.
• The regression tests that keep it closed — I know which test is missing, because I have seen suites that pass while the sink fires.
• A re-test 30 days later, so a fix that drifted is caught.

Formats

• Single review — scoped to one product or one surface, 5–10 days.
• Retainer — monthly, for teams shipping agent features continuously.
• Training — half a day on using coding agents safely, a day on auditing them. Usually pairs with a review: the review finds it, the training stops it recurring.

Scope-dependent pricing; a short call first is free and I can usually tell you in twenty minutes whether your git path is one of the known gaps.

What I don't do

• Red teaming, network penetration testing, or compliance audits.
• Model security: jailbreaks, prompt-injection evaluations, safety evals.
• Anything that needs me to publish something about you.

One scope, done properly, beats a list of services. If your problem is outside it, I will say so in the first call.

Contact

Open an issue on either repo, or reach out directly. Findings I come across are reported privately to the vendor first and published only after they respond — that applies to reviews too.