What it does not stop
The threat model, said before a customer finds it.
What it does not stop
Said first, because a guardrail whose limits arrive as a surprise is worse than one whose limits were on the page.
| Editing your settings file | The hook is registered there, and whoever can write that file can remove it |
| A session on another machine | Coco governs where it is installed |
| What a permitted call does next | The gate authorises a call and does not supervise it. A rule that allows a database write cannot decide what the write contains |
| A contract that is wrong | Enforcement is only as good as the rule, which is why observe mode exists |
| Prompt injection, mostly | Injection reaches the model and not the gate, so an injected instruction has nothing to argue with |
The first row is the whole threat model
Installed by you, Coco binds the agent and not you. Installed by an organisation
through managed settings with allowManagedHooksOnly, it binds you too, and a
developer cannot override it.
Which of those two you are running decides what your ledger is worth to anyone else. A developer's own install is a good guardrail and a weak piece of evidence. See Managed fleet.
What a permission mode does and does not do
A permission mode is not on that list, which surprises people. A permission mode changes when the runtime prompts you, and the hook runs before the prompt.
This was measured rather than argued. On Claude Code 2.1.228 the hook fired and
the command did not run in all four arms, including
--dangerously-skip-permissions and including a hook returning ask. The table
and the probe that reproduces it are in Can the agent get past
it.
Prompt injection, precisely
An injected instruction reaches the model. The gate never sees the conversation, so there is nothing in the injection for a verdict to be argued with.
What injection can still do is steer the agent towards calls your contract already permits. The gate bounds what a steered agent reaches and it does not detect the attack. Those are different claims and only the first one is Coco's.
Where it does not go yet
- Receipts are tamper-evident and not cryptographically signed. Signing and an external anchor are the next step.
- Cross-session and cross-agent state is not implemented. Two agents co-ordinating across separate sessions are outside what the gate sees.
- The npx install needs a runtime that exposes hooks. Any other runtime goes through the gate over HTTP, which is one check at the point where tools execute.
- MCP interception is client-side. An MCP call is stopped before it leaves the runtime, and Coco does not today reject anything at the MCP server. Describing it as server-side enforcement would be wrong.