Interface: IToolPolicyConfig
Defined in: internal/tool-policy/types.ts:17
The rules that decide which tools a run offers the model, and when. Lands in IAIGatewayConfig.toolPolicy.
ToolPolicy applies them to the registry's tools and to a call's additionalTools (D66) alike: a tool the app adds on a
call still needs the permission that unlocks it, still pauses when the profile's approvals name it, still waits for the
tools it requires.
Properties
permissionsToTools?
optionalpermissionsToTools?:Record<string,string[]>
Defined in: internal/tool-policy/types.ts:30
Which permission a user needs for a tool.
Keeps a tool away from users who may not use it, whatever the profile allows.
Key: a permission of IUserContext.permissions. Value: the tools it unlocks. A tool that no permission names is open to
everyone; a tool named by several is open to a user who has any of them. Decided once, at the start of the run.
Example
{"billing.refund": ["refund"]} - only users with the billing.refund permission ever see the refund tool
Default
{}
requires?
optionalrequires?:Record<string,string[]>
Defined in: internal/tool-policy/types.ts:47
The order of tools in a run: which tools must have run before another one is offered (D15, guarded workflows).
Forces a look-up before an action, so the model cannot act on a guess.
Key: the guarded tool. Value: the tools that must have run earlier in this run, each with a result that is neither rejected by the human nor failed (D76). Checked before every model step: a guarded tool whose required tools have not all run is left out of that step's tool list, so the model is not told about it; it appears in the step after they ran. A call to it anyway, by name, is refused with an error result that names the tools it requires (D88), also when its input would need an approval (D79). Tools not listed are offered from the first step. Earlier runs on the same thread do not count.
Example
{refund: ["lookup_order"]} - the model must look the order up before it may refund it
Default
{}