DeviosLang

Security research on the boundaries of AI coding agents.

Every serious AI-agent escape of 2026 had the same shape: the agent trusted something the repository supplied. Not a model bug — a boundary bug. The component that enforces the boundary runs in the environment it polices, and takes its parameters from untrusted input: a repository, an issue, a patch, a tool result.

Current focus

• Repository-controlled execution surfaces in git — which git operations a coding agent performs on its own, and which of git's execution sinks survive the vendor's hardening.
• Agent configuration surfaces — MCP server declarations, hooks, permission files, environment channels.
• Differential testing of agent boundaries — what the approval layer believes will run vs. what the shell actually runs.

Open source

agent-boundary-scan (abs) — scan a repository for the places where an AI coding agent gets hijacked: git config sinks, filter drivers, repo-declared MCP servers, agent hooks, GIT_* env channels, devcontainer lifecycle commands, escaping symlinks. CLI, SARIF, CI gate.

pip install agent-boundary-scan
abs .                     # text report
abs . --format sarif      # GitHub code scanning
abs . --fail-on high      # CI gate

mcp-surface-scan (mss) — read an MCP client config and report what each declared server can reach before you mount it: launch-time package resolution, remote endpoints, credentials in env, host-reaching container flags, path arguments that mean "everything".

Writing

• Fifteen popular MCP servers, and what they can reach — a capability-surface measurement of the npm tarballs people actually install.
• A checklist for running AI coding agents on code you did not write — ten concrete checks, none of which wait for a vendor patch.

Writing

• How to test an agent boundary — crash fuzzing found nothing; the oracle has to be differential.

Method notes

• Every finding is reported with an A/B pair: identical payload, only the suspected evasion differs. Anything weaker gets triaged down.
• Crash fuzzing alone is not enough on a hardened parser; the differential oracle is what surfaces real issues.
• A sink that "does not fire" is only meaningful if a pinned sink also failed to fire in the same run.

Writing

A write-up covering twelve coding agents — reproducing each vendor's git hardening exactly and measuring which execution sinks still fire — is under coordinated disclosure and will appear here once the vendors have responded.

Services

Agent boundary review — one scope: where does the thing that enforces the boundary take its parameters from? Git sink coverage, approval-parser differentials, MCP and configuration surfaces.

Contact

Vendor-side boundary reviews (git sink coverage, approval-parser differentials, MCP and config surfaces) and team training on using coding agents safely: open an issue on the repo, or reach out — first contact costs nothing.