Integration proposal: agent-chaperone as an optional runtime security layer

[sepehr-safari]

I've been looking at whether agent-chaperone could fit into ECC's security model.

Agent Chaperone is an open-source runtime layer for AI agents that screens:

• tool calls before they execute
• tool results before the agent reads them

It uses Jev for fast probabilistic decisions around things like destructive actions, secret exposure, task relevance, and suspicious instructions / prompt injection.

Repo: https://github.com/agent-chaperone/agent-chaperone

Where I think it fits

I don't see it as replacing AgentShield or GateGuard.

Roughly:

• AgentShield: is the agent environment/configuration safe?
• GateGuard: has the agent investigated enough before acting?
• Agent Chaperone: should this particular action or result be trusted at runtime?

Possible ECC integration

Chaperone already supports Claude Code's hook interfaces, so the initial integration could stay very small and optional.

Something roughly like this could run alongside ECC's existing hooks while keeping the two projects independent:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash|Edit|Write|WebFetch",
      "hooks": [{
        "type": "command",
        "command": "agent-chaperone hook pre"
      }]
    }],
    "PostToolUse": [{
      "matcher": "Bash|Read|WebFetch",
      "hooks": [{
        "type": "command",
        "command": "agent-chaperone hook post"
      }]
    }]
  }
}

For a first integration, I'd probably keep the scope to:

• optional Agent Chaperone integration
• Claude Code hook registration
• shadow/audit mode by default
• docs and tests

If that proves useful, later we could explore automatic task capture for off-task detection and optionally wrapping configured MCP servers through Chaperone's MCP proxy.

Would something along these lines fit ECC's direction? If so, I'd be happy to put together a small PR following the existing hook/module conventions.

[redbotster]

the layered framing makes sense and the hook-based integration is the right call since it keeps chaperone optional and doesn't require ECC to take a hard dependency. the shadow/audit mode before enforcement is critical, probabilistic filters have false positives and you really want a baseline before you start blocking.

one thing worth noting on the secret exposure detection: if secrets are managed so the raw value never reaches the model context or tool output in the first place (via something like path-reference vaulting), chaperone's post-tool-use screening has a lot less surface area to worry about. i work on 1Claw which takes that approach, and it would complement this layer well rather than overlap. but even without that, the runtime screening for destructive actions and prompt injection is valuable on its own.

[sepehr-safari]

Update: agent-chaperone now installs as a Claude Code plugin, so it can run next to ECC with no change on ECC's side. I wrote up what AgentShield, GateGuard and agent-chaperone each check, and how the two sets of hooks run together:

https://agentchaperone.dev/guides/ecc

The hook config in my post is out of date. The plugin also covers PowerShell, Monitor, NotebookEdit and Grep now, and tool calls that failed.

If an ECC-side integration would still be useful, I'm happy to put one together.

[chenhz01]

Layering makes sense, and shadow-first is the right default. Two things bite in practice.

Hook ordering across two plugins isn't deterministic, so shadow logs won't predict what enforcement would actually have done — either ECC owns the ordering, or chaperone runs as the single entry hook that invokes the rest.

PostToolUse on Read|Bash also streams every full tool result through a second process. At ECC's file sizes that is per-call latency and tokens, not a fixed cost — worth measuring before it's default-on.

Landing path: audit-only hook, always exit 0, append {tool, decision, latency_ms} to a log; add --enforce later; test by replaying recorded payloads. Happy to PR the replay harness.

[sepehr-safari]

@affaan-m @haelyra any ideas on this?