Skip to main content

Module policy

Module policy 

Source
Expand description

Tool-call policy: an ordered list of operator verdicts on the call itself — allow, deny, ask a person, or hold it and say so.

Grants answer may this caller reach this tool at all, and they are name patterns, so they cannot express “delete anything outside /tmp” or “a person signs off before any egress-tagged call”. agent.approval only decides whether to honour a gate the MODEL asked for. This is the layer in between: the arguments are already schema-validated one step earlier, so judging them here costs nothing extra and is the only place it can happen.

It composes with the machinery either side rather than duplicating it: tools.overrides says WHERE a call goes, this says WHETHER, and an ask verdict suspends on the same deferred-human path ask_human and the human node already use.

First match wins and no match is allow, so an empty list is exactly today’s behaviour and the common path pays one is_empty check.

Structs§

Call
What a call looks like to the policy list.
Verdict
The verdict, plus which rule produced it (for the log and the audit line — “denied” without “by which rule” is not an answer an operator can act on).

Functions§

caller_name
could_apply
Whether any rule could apply to this tool for this caller, ignoring the argument guard (which needs the actual call).
evaluate
Evaluate the list. Ok(None) means no rule matched (allow); Err(rule) means a rule’s argument guard failed to evaluate, which is fail-closed rather than a pass.