Run agent-chaperone alongside ECC
ECC, Everything Claude Code, installs a large set of Claude Code hooks, and two of the security pieces it ships are AgentShield and GateGuard. agent-chaperone installs next to it and screens something neither of those looks at: what each tool call is about to do, and what each result says, as they happen.
The two run side by side and stay independent. Nothing in ECC changes, ECC does not know agent-chaperone is there, and this is not an integration its maintainers have reviewed. It is two plugins whose hooks both fire.
What each one checks #
- AgentShield asks whether the setup is safe. It audits a Claude Code configuration for vulnerabilities, misconfiguration and injection risk, and reports what it found. It is a scan you run, so it looks at the configuration rather than at any particular call.
- GateGuard asks whether the agent has looked before it acts. It is one of ECC's
PreToolUsehooks: it stops edits, writes and shell calls until the agent has investigated what they touch. It checks that the agent did its homework, not what the call itself would do. - agent-chaperone asks whether this action or this result should be trusted. Before a call runs, it asks whether the call would destroy something, send private data or a credential somewhere external, or has nothing to do with a task you recorded. Before the agent reads a result, it asks whether the text is written to instruct the agent rather than inform you, which is how prompt injection arrives, and whether it exposes a credential.
None of the three substitutes for another. A configuration can pass a scan and a call can follow a thorough investigation, and the call can still be the one that posts a key to a stranger, because the instruction to do it arrived in a page the agent fetched a minute earlier.
Install it next to ECC #
From inside a Claude Code session:
/plugin marketplace add agent-chaperone/agent-chaperone
/plugin install agent-chaperone@agent-chaperoneThat registers three hooks: one before shell commands, file edits and web fetches, and two after shell commands, file reads and searches, and web fetches, including ones that failed. It brings the agent-chaperone skill as well, which tells the agent what to do when a call is held.
If agent-chaperone is installed globally the plugin uses that. Otherwise the first screened call installs the matching version into the plugin's own data directory, which took 13 seconds when I measured it, and every call after that runs it directly in about a seventh of a second. Uninstalling the plugin removes all of it.
Registering the hooks by hand works too, and the Claude Code guide has the configuration and what each entry is for.
How the two sets of hooks run together #
Claude Code runs every hook whose matcher fits a call, from every plugin and every settings file, in parallel. On shell commands, edits and writes, ECC's hooks and agent-chaperone's both fire.
- In shadow mode, which is the default, agent-chaperone gives no decision at all. It writes its judgment to its own log and returns nothing to Claude Code, so there is nothing for ECC's hooks to conflict with. GateGuard stops exactly what it stopped before.
- In enforce mode it answers ask or deny, and never allow. It can put a question in front of you or refuse a call, but it cannot approve something another hook stopped, and it never skips the permission prompts you set up yourself.
Claude Code's documentation does not say how it combines an ask from one hook with a deny from another. So do not build anything that depends on an order between ECC's hooks and these.
Start by reading, not blocking #
Probabilistic screens get some calls wrong, and the only honest way to choose where the lines go is on your own traffic. Leave it in shadow for a while, then:
agent-chaperone reportThat leads with what enforcement would have stopped and did not. If a line looks wrong, move its threshold with agent-chaperone replay --policy candidate.yaml, which decides again over what was already judged and shows which way each decision moves. When the log stops surprising you, set mode: enforce in the policy file.
The model screens need a TYPESAFE_API_KEY in the environment Claude Code starts hooks in. Without one the deterministic rules still run, which is the allow and deny lists, the secret patterns, dangerous shell forms and hidden text, and every judgment records that no model was asked.
What this does not cover #
- MCP servers. These hooks screen Claude Code's own tools. Calls to an MCP server go through the proxy, which wraps a server with one change to its configuration and uses the same policy file and log.
- Files you hand the agent. A file you reference in your own message is inlined into the prompt without any tool running, so no hook from either plugin sees it.
- What a command does rather than what it says. This is not a sandbox. It reads the call, and a program that does something its arguments did not describe is outside it.
- A guarantee. The measured results name what the screens miss and what they flag in error, including on documents that only discuss prompt injection.
The full hook reference, including how a withheld result is matched to a tool's own output shape, is in the hooks reference.