Inspiration
AI agents are getting real power — today they run shell commands and edit code; tomorrow they'll browse, email, pay, and operate apps on your behalf. The core flaw scales with them: an agent can't tell your instructions from ones an attacker hides in a file, a web page, or tool output. In 2025 this already caused damage through coding CLIs — the Amazon Q VS Code extension prompt, the Nx npm attack that stole ~2,300 credentials via developers' own AI tools, and a Replit agent that wiped a production database. Blocking one tool doesn't help — the agent just uses another, and its built-in safety flips off with one flag. We wanted enforcement from outside the agent that reasons about where data came from — an approach that works for coding agents now and generalizes to any agent that acts.
What it does
TrustAgent routes every agent action through a central guard that answers ALLOW, BLOCK, or STOP before it runs. A lightweight hook wraps the agent from the outside and fails closed if the guard is down. Instead of scanning for bad text, the guard tracks provenance — labeling everything the agent reads by trust (trusted/untrusted) and sensitivity (public→secret). Reading is always allowed; it blocks only when it traces untrusted or secret data into a dangerous action — reaching an exit (the lethal trifecta), a secret leaving, or a destructive command. Because the guard reasons over actions and their provenance — not any one agent's internals — the same control plane spans coding CLIs today (Claude Code and Codex) and extends to any tool-using or general-purpose agent. A live dashboard shows the traffic, a provenance graph that traces each block back to its source, and a STOP button that revokes the session.
Our core idea: we don’t detect the injection, because that’s an arms race. We track where context came from, so injected content can be read but can never drive a dangerous action.
How we built it
TrustAgent is a control layer for CLI coding agents: every action an agent tries to take is routed through a central gateway — "the guard" — that returns ALLOW, BLOCK, or STOP before the action actually runs. The guard is a deterministic reference monitor written in plain Python with no LLM in the decision path. Agents reach it through a thin PreToolUse/PostToolUse hook that we deliberately made agent-neutral, so a single sensor wraps both Claude Code and OpenAI Codex by mapping each one's tool surface (apply_patch, shell, argv-style commands) onto a common action model. Every file read and tool call gets two provenance labels — trust (trusted/untrusted) and sensitivity (public through secret) — assigned by where the data came from, propagated across derived files, and recorded in a real-time provenance DAG. The guard then enforces at the sink: it blocks when untrusted data reaches an exit (the lethal trifecta), when secret data heads to an unapproved destination, or when a planted honeytoken is touched, using a graph traversal (trace_back) that pinpoints exactly which sources connect to the action. A React/Vite dashboard renders the live provenance graph, animates the decision trace-back, and shows an unmistakable ACTION BLOCKED banner.
Challenges we ran into
The hardest constraint was that we can't modify the agents themselves — Claude Code and Codex are closed CLIs, we had to infer provenance from the outside through hooks, which is approximate by nature. The "bash problem" bit us early: a single shell command can hide many actions, and a real agent bypassed our guard by opening a socket with python -c "import socket" instead of curl — a gap we only found because we tested against actual adversarial agents, then closed. We also had to navigate the tension between soundness and precision: our conservative session-level union never misses a tainted flow but over-blocks, so building a source-level trace_back that cut false positives without ever introducing an under-block (we kept the union as a fail-closed floor) was a genuinely delicate design decision. On top of that came cross-platform friction — Windows tool names, path normalization, hooks that must fail closed — and the irony of our own guard repeatedly locking us out of the very session we were using to build it. Finally, making the sensor truly multi-agent meant handling Codex's different tool names, argv-style commands, and its hook-trust model.
Accomplishments that we're proud of
Our top priority is moving from a cooperative hook toward real isolation — adding an OS- or container-level sandbox so the guard holds against a genuinely adversarial agent, not just a well-behaved one. Next we want to prove it with numbers by running TrustAgent against a standard prompt-injection benchmark such as InjecAgent or AgentDojo and publishing block-rate and false-positive figures, including the honest misses. We also plan to make the provenance graph the default decider across more rules by calibrating edge confidence, so the source-level trace_back can safely replace the conservative union more broadly. Beyond the tool hook, we'll add more sensors — an egress proxy and an MCP/tool proxy to cover channels the hook doesn't see — along with cross-agent provenance for delegated multi-agent workflows. Finally, we want an AWS-native deployment story: Bedrock for a real model-level kill switch and Cedar/Verified Permissions for policy, so TrustAgent can run self-hosted or fully in the cloud.
What we learned
The biggest lesson is that you can't win by detecting "malicious text" — the research is right that the robust approach is to control what untrusted data is allowed to do (reach a secret, reach an exit), not to guess whether some input looks like an injection, which is an unwinnable arms race. A corollary that shaped the whole design is that reading is safe and acting is where the risk lives: letting the agent read anything and only intervening at the sink keeps over-blocking low while still stopping the attacks that matter. We also learned, somewhat humbly, that outside-in monitoring is fundamentally approximate, and that being honest about confidence and soundness is more valuable than pretending to have perfect taint tracking. Most importantly, we came to understand the real difference between mediation and isolation: a cooperative hook is a powerful policy and observability layer and a legitimate defense-in-depth win, but it is not a containment boundary — and recognizing that gap honestly is exactly what shaped our roadmap.
What's next for TrustAgent
Our top priority is moving from a cooperative hook toward real isolation — adding an OS- or container-level sandbox so the guard holds against a genuinely adversarial agent, not just a well-behaved one. Next we want to prove it with numbers by running TrustAgent against a standard prompt-injection benchmark such as InjecAgent or AgentDojo and publishing block-rate and false-positive figures, including the honest misses. We also plan to make the provenance graph the default decider across more rules by calibrating edge confidence, so the source-level trace_back can safely replace the conservative union more broadly. Beyond the tool hook, we'll add more sensors — an egress proxy and an MCP/tool proxy to cover channels the hook doesn't see — along with cross-agent provenance for delegated multi-agent workflows. Finally, we want an AWS-native deployment story: Bedrock for a real model-level kill switch and Cedar/Verified Permissions for policy, so TrustAgent can run self-hosted or fully in the cloud.
