Security reviews whether tool allowlists are enforced in the agent runtime or only suggested in prompts. Why does that distinction matter?
Select an answer to reveal the explanation.
Short Explanation
Telling the model “please don’t use that tool” is a suggestion; a runtime allowlist is a lock. Enforce tool limits in the agent runtime so a stubborn or injected model cannot ignore the rule. Prompt-only hope is not a control.
Full Explanation
Security reviewing whether tool allowlists are enforced in the agent runtime or only suggested in prompts is probing a critical control placement distinction. Runtime enforcement blocks disallowed tools even when the model ignores prompt advice, which is required because LLMs can be persuaded, confused, or injected into requesting forbidden tools. In municipal agent platforms, prompt text is advisory; the gateway or runtime must refuse unauthorized tool invocation regardless of model intent.
Prompt-only suggestions are cryptographically stronger than runtime gates fails by concept: prompts are not cryptographic controls and are weaker than runtime mediation. Runtime enforcement is unnecessary if the model temperature is set to zero fails by concept: temperature does not create a hard authorization boundary and does not stop tool requests under injection. Allowlists should live only in resident FAQ pages for transparency fails by concept: public FAQs do not mediate tool calls in the agent runtime.
Exam caveat: runtime allowlists enforce what can be called; they must stay aligned with role-based exposure and OAuth scopes so an allowed tool name cannot still perform over-privileged API actions. Operational check: instruct the model (or inject a prompt) to call a disallowed civic tool and confirm the runtime/gateway returns denial with an audit event even though the model emitted a tool call request.