In LangChain-style stacks, a tool is a callable with arguments. Model quality does not tell you if the call is allowed. Security lives where you bind each tool to a surface and require an execution authorization decision before the handler runs. TrigGuard provides that as middleware or a thin client in front of your tool broker.
For the cluster pillar overview, see runtime authorization for AI agents.
Key concepts
1. Name surfaces, not prompts
Policies key off stable surface identifiers, for example data.export or payments.refund, not the natural-language tool description. The model still proposes the tool; the gate evaluates the structured request against the policy version in force.
2. Put the gate on the real commit path
Tool wrappers that only log, or that run after a side effect, are too late. The TrigGuard boundary belongs on the path that would issue the network call, file write, or transfer, so a DENY or SILENCE can stop execution. See hello world for a minimal pattern with Express.
3. Use receipts for audit, not for prompt debugging
Every decision can be bound to a signed receipt you verify with published keys without a callback. That is how you prove, after the fact, which policy version authorized or blocked a call.
Related architecture
Next step
Wire the gate at your tool boundary, then verify receipts offline.