The Anthropic Agent SDK fundamentally re-frames the traditional API security model by introducing an autonomous actor—the agent—into the runtime. While the SDK's authentication and permission grant mechanisms provide a structured control plane, the principle of least privilege must be applied with extreme prejudice at the tool definition layer. The security surface is not defined by what you *can* expose, but by what you deliberately and absolutely *must not*.

Based on the inherited security properties of the SDK and the zero-trust posture required for agentic systems, I categorize tools into three high-risk classes that should be excluded from any agent's toolbelt, barring an extraordinarily controlled, air-gapped research environment with compensating controls.

**1. Direct System or Infrastructure Mutation Tools**
Agents operate on a loop with potential for error amplification. Tools that allow direct, unmediated changes to production infrastructure, data plane configurations, or system state are an existential risk. The SDK's permission grants are not a sufficient compensating control for the speed and autonomy of the agent.

* **Examples to exclude:** `kubectl`-style executors, cloud provider CLI tools for deleting resources (e.g., `aws s3 rm --recursive`, `gcloud compute instances delete`), database `DROP` operations, or service restart/stop commands.
* **Why:** The agent's reasoning is probabilistic. A single misparsed user intent or hallucinated parameter could lead to irreversible destructive action. The correct pattern is to expose a tool that creates a *ticket* or *change request* in a human-in-the-loop system, not to perform the action directly.

**2. Broad Data Exfiltration or Enumeration Tools**
The agent's context window is a data sink. Tools that allow unbounded querying of sensitive data stores, user directories, or logs present a massive data leakage and privacy violation risk. The "lineage" and "what Anthropic sees" boundaries become moot if the agent can simply read and then include sensitive data in its responses.

* **Examples to exclude:** Unfiltered database connection tools with `SELECT *` capability, full-text search across all internal documents, tools that list all users with all attributes, or raw access to audit logs.
* **Why:** This violates the core tenet of data minimization. Even with user authentication, the agent should not become a super-user data broker. Tools must be scoped to return only the specific, minimal data needed for the task, using pre-defined, parameterized queries with strict row limits and field masking.

**3. Credential and Secret Management Tools**
This is perhaps the most critical exclusion. The agent SDK handles authentication *to* the agent, but the agent must never be given tools to manage the credentials *it or other systems* use. The moment an agent can read, write, or rotate secrets, you have created a self-propagating credential compromise engine.

* **Examples to exclude:** Tools to retrieve secrets from a vault (like `vault read secret/...`), tools to generate new API keys, tools to modify IAM role bindings or OAuth client configurations.
* **Why:** It breaks the chain of custody and explicit consent in credential management. If the agent's context is compromised or its reasoning is manipulated via prompt injection, it could exfiltrate secrets or escalate its own privileges. The agent must only receive ephemeral, task-specific tokens with narrowly scoped permissions, injected at runtime by a trusted sidecar process, not tools to acquire them itself.

The implementation stance should be a default-deny list. The SDK's `tool_execution` is the new `sudo`. Consider this not just a configuration exercise, but a threat modeling imperative: every tool you expose creates a new attack vector where the agent is the pivot point. The question is not "why not expose this tool?" but "what is the catastrophic failure mode if this tool is invoked erroneously or maliciously, and can we accept that risk?" In most production IAM frameworks, the answer for the above categories is a resounding no.