Tool-using agents moved from demo to production faster than most security teams expected, and the result is an uneven landscape where some organizations have rigorous controls and others have agents with broad cloud access running on engineer laptops. This post is an attempt to codify the baseline we now consider non-negotiable for any production agent deployment. None of these controls are exotic; the failure mode is omission rather than complexity.
The framing is borrowed from the standard application security baseline, adapted to the agent threat model. Tool use creates a new attack surface that traditional appsec controls do not cover, and several traditional controls become more important rather than less. The baseline assumes the model is not trusted, the network is not trusted, and the user is not trusted, and the controls flow from those assumptions.
What does least privilege look like for tools?
Least privilege for agents starts with refusing to grant tool access in bulk. The common failure pattern is wiring an agent to a broad credential, an AWS admin role, a database connection with full read-write, a Slack bot token with all scopes, and then relying on the model to behave well. The baseline is the opposite: every tool gets the minimum credential it needs, and every credential is scoped to the minimum resource set. For AWS, this means per-tool IAM roles with explicit resource ARNs, not wildcards. For databases, it means per-tool read-only connections with row-level security where the platform supports it. For SaaS APIs, it means dedicated service accounts with only the scopes each tool requires. The work is real but one-time, and the resulting blast radius from a compromised agent is bounded rather than unbounded. We have seen this single control prevent multiple incidents from escalating into reportable breaches.
How should tool inputs and outputs be validated?
Tool input validation is the boundary between the model's probabilistic output and your deterministic systems, and it deserves the same rigor as a public API. Every tool entry point should have a strict schema with value-level validators, not just type-level ones. URL allowlists, file path containment, parameter range checks, SQL bind variables rather than string concatenation. The OWASP API Security Top 10 applies directly here; the agent's tool call is effectively an internal API request, and the same broken object level authorization and injection patterns recur. Output validation matters too, because tool outputs flow back into the model context and can themselves carry prompt injection payloads. Stripping or escaping known-bad content from tool outputs before they enter the context window blocks the most common indirect injection vector. Schema validation alone catches the obvious cases; semantic validation catches the rest.
How is authentication and audit handled in 2026?
Authentication for tool calls has moved decisively toward short-lived credentials and explicit user delegation. The standard pattern is OAuth-style token exchange where the agent presents user context and receives a per-request, narrowly scoped, short-TTL credential for each tool call. Long-lived service tokens stored in agent configs are increasingly considered a finding rather than a normal pattern. Audit logging has matured in parallel: every tool call should produce a structured log entry capturing the requesting user, the model version, the prompt that triggered the call, the tool name and arguments, the response, and a request ID that ties the entry to the upstream conversation. This audit trail is the only way to investigate an incident after the fact, and the teams who skip it discover this the hard way. Centralized log aggregation with retention long enough to support post-incident analysis is part of the baseline, not an optional add.
What about human approval gates?
Human approval gates are the load-bearing control for any tool that can cause irreversible action. The taxonomy that has settled out is straightforward. Read-only tools generally do not require approval. Reversible mutating tools, creating a draft, posting an internal-only message, querying a non-production system, can proceed autonomously but should be logged with sufficient context for after-the-fact review. Irreversible or externally visible mutating tools, sending an email, executing a financial transaction, modifying production infrastructure, running arbitrary code, deleting data, should require explicit human confirmation in the loop. The friction is the point. Agent vendors have made it tempting to skip approval gates in pursuit of latency improvements, and several of the most damaging agent incidents this year would have been prevented by an approval gate the team disabled to speed up demos. The baseline is to default these gates on and require deliberate exception management to turn them off.
How are MCP servers changing the picture?
The Model Context Protocol has become the de facto integration layer for agent tools in 2026, and the security implications are mostly positive. MCP server boundaries map naturally to capability boundaries, and the protocol provides a clean place to enforce authentication, authorization, and audit policies that previously had to be re-implemented per agent. The risk MCP introduces is the opposite of the one it solves: it makes it very easy to wire an agent to a new tool, and the resulting capability sprawl is hard to track without dedicated tooling. The baseline practice is to maintain an inventory of MCP servers your agents can call, classify each by risk tier, and treat new MCP server additions as a change-management event with security review. Several of the more mature platforms now enforce this at the gateway layer, blocking agent-to-MCP traffic that has not been explicitly registered.
How Safeguard Helps
Safeguard maintains the inventory and policy layer that turns this baseline into enforceable controls. Griffin AI ingests your agent infrastructure SBOM, maps tool capabilities to MITRE ATLAS techniques, and surfaces capability drift between releases. Policy gates in CI block new tool integrations that have not gone through threat model review, and our MCP server registry tracks the security posture of every server in your environment. TPRM scores third-party MCP publishers on their auth design, audit logging, and breach history, so onboarding new tools comes with a defensible risk assessment. Reachability analysis identifies which agent CVEs in LangChain, AutoGen, and the MCP SDKs actually affect deployed code paths, keeping prioritization tight.