How it compares

Each of these is a real control that does a real job. The question is which job.

Against the permission rules already in your runtime

Permission rules match a tool and its arguments. They are a good fit for "never run this command" and they are the right tool for that job.

They have no memory. Every call is judged alone, so a run of individually allowed calls is allowed. Reading a credential is fine and fetching a URL is fine, and doing the second after the first is exfiltration.

They have no view of the work. They cannot express "the risk assessment may not be written until five independent searches are evidenced in this customer's folder", because that fact is in the case folder rather than in the call.

Coco reads both. The session's own history, and live state from the system of record, at the moment of the call.

Keep the permission rules. They cost nothing and they catch the flat cases faster than a contract will.

Against an MCP gateway

An MCP gateway sees MCP traffic. It cannot see a shell command, a file write or a subagent being spawned, because none of those goes through MCP.

Coco sits at the tool-call boundary, so an MCP call arrives at the same gate as Bash and is evaluated by the same contract.

The two protect different things and they compose. A gateway protects one server from every client. Coco governs one agent across all of its tools. A bank with a sensitive MCP server probably wants both.

Coco's MCP interception is client-side, which means the call is stopped before it leaves the runtime. Coco does not today reject anything at the MCP server.

Against writing the rules into the prompt

A prompt shapes what the agent tries. It does not decide what runs.

An instruction is a request the model can reason its way past when the context gets long or the case looks unusual, and the failure is silent. Nothing tells you the agent talked itself into an exception, because there is no record of the rule having been consulted.

There is a version of this worth keeping. Feed the contract text into the agent's own prompt, read only, so the agent knows the rules it works under and takes fewer paths that end in a block. rules() on the SDK exists for that. The agent understands the rules and still cannot touch the gate that enforces them.

Against a human reviewing the output

Review after the fact catches what already happened. For an action that settles, or sends, or approves a customer, that is too late.

Coco is the same control moved earlier. ESCALATE is human review, put in front of the action instead of behind it, and the answer goes on the record next to the receipt.

Against an eval or a model-graded judge

An eval tells you how often the agent behaves. It is the right instrument for that question and it is measured on a sample, after the fact.

A gate answers one call. It is not a probability, it is deterministic, and it is answerable to an auditor asking about one specific decision on one specific day.

A model-graded check at runtime is a model, which means the same call can be graded differently twice and the grade itself can be argued with. That is why no model runs on Coco's decision path.

What Coco is worse at

Anything that needs judgement. A contract cannot decide whether a customer's explanation is plausible, whether a piece of writing is any good, or whether a case is unusual in a way nobody wrote down. Those are ESCALATE at best, and outside the contract at worst.

The gate is also blind to everything that is not a tool call, and it does not supervise a call once it is permitted. A rule that allows a database write cannot decide what the write contains.

If your risk is that the agent produces poor work, Coco is not the control. If your risk is that the agent takes an action nobody authorised and you cannot prove otherwise, it is.