Tool security starts by removing capabilities, not detecting misuse

I think tool security starts by removing capabilities, not detecting misuse. If an agent can read private data, consume untrusted content, and communicate externally in the same task, no classifier should be treated as the primary control. Detection asks a probabilistic system to recognize danger in time. Capability reduction makes whole classes of dangerous action impossible before interpretation begins.

The old “agent and tool security” bucket split for a reason: injection attacks, defenses, testing, supply-chain risk, and compliance are different operating problems. The defense side repeatedly returns to the same structural controls—least privilege, explicit tool allowlists, read and write scopes, sandboxing, short-lived credentials, and enforcement at the execution boundary. They are less glamorous than a model that labels malicious prompts, but they fail in narrower and more inspectable ways.

I would represent the task’s authority as data. A permission context can carry readable resources, an exact set of allowed tools, writable resources, a task identifier, and an expiry time. The important word is task. A broadly capable agent identity does not imply broad authority for the current run. A code-review task may read a repository and write a review artifact; it does not need deployment credentials, production database writes, or a messaging tool.

This changes how I interpret prompt injection as a permissions problem. Assume untrusted text succeeds in influencing the model. Then ask what the influenced model can actually reach. If the destructive tool is absent from the allowlist, the call is rejected before execution. If writes are restricted to one task output path, a persuasive instruction cannot widen that path. If the permission context expires with the task, stale agent state cannot quietly retain authority.

Capability reduction must reach below tool names. “Database” is not a meaningful permission boundary when one method reads public catalog rows and another deletes customer records. Read, execute, and write deserve separate scopes. Arguments need validation against those scopes, and their provenance should remain visible—whether a path, recipient, or account identifier came from the user, a trusted system, an untrusted document, or the model itself. A safe-looking tool can still become dangerous through an attacker-controlled argument.

The enforcement point matters just as much. Permissions belong in the trusted harness between model output and effectful execution, not inside prose instructions and not solely inside each tool implementation. Central enforcement gives every tool call the same default-deny check and one audit trail tied to the task that authorized it. It also supports a cleaner tool-schema security boundary: schemas describe possible calls, while policy decides which possible calls exist for this task.

Detection still has a role. Input classifiers, action-sequence anomaly detection, output checks, human approval, and shadow execution can catch mistakes that survive scoping. But those controls should operate on an already reduced action space. A detector deciding whether an unrestricted shell command looks suspicious is defending too late. A detector reviewing one proposed write inside a named directory, under an expiring task grant, has a tractable job.

I concede one precise limit: some open-ended operational tasks cannot enumerate every required capability in advance. In those cases the system needs controlled expansion—an explicit request for a new grant, with scope, reason, expiry, and approval—not a permanently broad allowlist. Discovery can remain flexible without making authority ambient.

The practical security question is therefore not “Can we detect a malicious instruction?” It is “Which effects remain possible if detection fails?” I want that answer to be small, task-specific, and recoverable. As the sandbox should match the blast radius, the tool surface should match the authorized outcome. Remove what the task cannot justify; then monitor the smaller system that remains.