A security team reviews agent logs and discovers that an agent has been invoking a delete_file tool repeatedly, despite delete_file not appearing in the agent's configured tool allow list. The allow list contains only read_file, write_file, and search_code. How was the agent able to invoke a disallowed tool?

There is a critical architectural distinction between an allow list as a prompt instruction and an allow list as an enforced runtime constraint. A prompt-based allow list (e.g., 'You may only use the following tools: read_file, write_file, search_code') is a soft instruction that the model may follow most of the time but can override when it reasons that a different tool is needed. The model is not bound by its own system prompt at the execution layer.

A properly enforced allow list operates at the agent runtime or tool dispatch layer: when the model requests a tool call, the runtime checks the call against the allow list before dispatching. If delete_file is not in the enforced allow list, the runtime rejects the call and returns an error to the model regardless of how the model reasons about it.

Option A (LLM hallucination) mischaracterizes how tool calls work. Tool calls are not hallucinated — they are structured outputs that the runtime actually dispatches. If the call was executed, the runtime accepted it.

Option C (namespace sharing) is not a real mechanism. Tools in MCP and similar frameworks are registered individually; sharing a name prefix does not create implicit inclusion.

Option D (automatic tool discovery) describes tool discovery from a server schema, which is a real feature — but adding tools to the available set requires explicit registration in the client configuration, not automatic inclusion at invocation time.

Allow lists must be enforced as runtime constraints, not relied upon as prompt instructions.