Nice architecture. The hook layer is the right interception point — that's where intent becomes executable action, and that's where you want enforcement.

One structural question: the IDE hook works when the agent is running in that environment. Does enforcement travel with it when the agent runs in CI (GitHub Actions, a Docker container, remote server)? Or is it IDE-only today?

The pattern worth designing toward: policy enforcement not coupled to the client surface. IDE hooks are genuinely useful for local dev — but the attack surface expands once the agent runs outside your local context. A clean tool on your machine can be a different tool in a CI environment with different secrets and broader filesystem access.

The `rm -rf /` block is the easy case. Harder: a shell command that looks benign in dev (e.g., `curl $ENDPOINT`) but becomes a credential exfiltration path in prod. Context-aware policy enforcement is the hard version of what you're building.

Curious if you're thinking about environment-specific policy strictness — tighter defaults for non-dev contexts where the blast radius is larger.