This is a really helpful comment, and I actually ran straight into the exact failure mode you’re describing. I had a PreToolUse hook enabled that was supposed

This is a really helpful comment, and I actually ran straight into the exact failure mode you’re describing. I had a PreToolUse hook enabled that was supposed to block reads of ~/.env. Claude tried to read it, hit an error, then asked me for permission. When I said yes, it retried the read and succeeded. The hook was effectively bypassed via user consent. That was the “oh wow” moment for me. Hooks can influence behavior, but they don’t remove authority. As long as the agent process still has filesystem access, enforcement is ultimately negotiable. I even tried adding an MCP server, but again its upto Claude to pick it up. Your capability token approach is the missing piece here. It makes the distinction very clear: instead of asking the agent to behave, you never give it the power in the first place. No token, no read, no amount of prompting or approval changes that unless a new token is explicitly minted. The way I’m thinking about it now is: hooks are useful for intent capture and policy decisions capability tokens are the actual enforcement primitive approvals should mint new, narrower tokens rather than act as conversational overrides Really appreciate you sharing Tenuo. This feels like the right direction if we want agent security to move past “prompt engineering as policy” and toward real runtime guarantees.