Securing MCP tool calls in agentic AI workflows

In July 2025, nine days into a 12-day experiment with Replit’s AI coding agent, SaaStr founder Jason Lemkin discovered the agent deleted his live production database during a code freeze, despite repeated instructions not to make changes without permission. The database contained records for 1,206 executives and more than 1,196 companies.

The agent incorrectly claimed that rollback was impossible, but Lemkin restored the data using Replit’s rollback feature. Replit subsequently introduced automatic separation between development and production databases to prevent development activity from directly modifying production data.

The freeze existed only as an instruction inside the agent’s context, with nothing outside the Agent to enforce it. The incident highlights a broader risk in agentic AI that also applies to MCP-enabled workflows: instructions alone cannot reliably prevent unauthorized actions. Addressing this risk requires three layers of control: guardrails that check each tool call before it runs, and permissions and audit trails that limit what a tool can do and record what it did.

Layer 1: MCP security guardrails for every tool call

The Model Context Protocol specification is direct about the risk. It describes tools as arbitrary code execution and states that hosts must obtain explicit user consent before invoking any tool. It also acknowledges that MCP cannot enforce these principles at the protocol level, leaving MCP security in the hands of the teams building the host, client, and server. Four guardrails do most of that work.

Treat tool descriptions from MCP servers as untrusted

The server supplies tool names, descriptions, and annotations. The specification says clients must consider annotations untrusted unless they come from trusted servers. A tool that labels itself read-only is making a claim, so the team should classify risk based on an allowlist it controls. Servers can also change their tool list mid-session via a listChanged notification, so any updated definition should trigger a recheck before the agent uses it again.

Validate inputs and outputs on both sides

The specification splits responsibilities between server and client:

Control	Owner	What it guards against
Validate all tool inputs	Server (MUST)	Malformed or malicious arguments
Rate limit tool invocations	Server (MUST)	Runaway loops and abuse
Sanitize tool outputs	Server (MUST)	Injected content returned to the model
Show tool inputs before the call	Client (SHOULD)	Accidental or malicious data exfiltration
Validate results before passing to the LLM	Client (SHOULD)	Poisoned tool responses
Timeouts on tool calls	Client (SHOULD)	Hung or stalled operations
Implement proper access controls	Server (MUST)	Unauthorized access to tools and resources

Require human approval for destructive tool calls

The specification recommends a human in the loop who can deny tool invocations, plus confirmation prompts for sensitive operations. OWASP gives a concrete version in its guidance on excessive agency: an email agent that drafts messages but needs a person to review and press send on each one.

The Replit case shows why placement matters. A rule written into a prompt can be ignored. A confirmation step enforced by the host, before a delete, drop, or deploy call reaches the server, can’t be ignored.

Run local MCP servers in a sandbox

The MCP security best practices note that local servers run with the same privileges as the client. Before a one-click server install, the client must show the exact command, without truncation, and get explicit approval. The guidance also recommends running servers in a sandbox with minimal default privileges and restricted file system and network access, with any extra access granted deliberately.

Include a Infographic for quick read both Layer 1 & 2

Layer 2: permissions and audit trails for MCP security

Guardrails decide whether a call should run. Code checks confirm a tool does only what it claims, permissions decide how much damage a call can do if a guardrail fails, and audit trails let the team reconstruct what happened. Four practices cover this layer.

Scan MCP tool code before it reaches production

A tool’s name and description tell the agent what the tool claims to do. Its code decides what it actually does, and call-time guardrails never inspect that code. An email tool can describe itself as a way to write well-formatted messages while its source quietly adds a threat actor’s personal address as Bcc on every outgoing email. The arguments look clean, the approval prompt shows a normal draft, and the data leaves through the server.

This has already happened. In September 2025, security researchers found a counterfeit npm package posing as an email provider’s official MCP server. Its first 15 versions were exact copies of the legitimate code. Version 1.0.16 added a single line that blind-copied every outgoing email to an external address, and the package was seeing around 1,500 downloads a week when it was caught.

What a code-level review should flag

• Recipients, headers or parameters the code adds that the tool’s arguments never supplied
• Outbound calls to domains the tool has no stated reason to contact
• Reads of environment variables, credential files, SSH keys or tokens outside the tool’s purpose
• Obfuscated or dynamically loaded code, such as eval calls, encoded payloads or scripts fetched at runtime
• Dependencies with known vulnerabilities or recent maintainer changes, caught through software composition analysis

Re-scan on every version change

The malicious line arrived as an update to a package that had been clean for weeks, so a one-time review at install is too early to catch it. Pin each MCP server to an exact version and verified hash, install only from the vendor’s official source or a vetted internal registry, and run the scan again before any new version is promoted.

Give each tool only the access it needs

Least privilege limits the blast radius when a guardrail fails. In an MCP security design, it applies at two layers: the identity a tool connects with, and the OAuth scopes it is granted.

Limit database permissions for agent identities

OWASP’s LLM06:2025 entry traces excessive agency to three root causes: excessive functionality, excessive permissions and excessive autonomy. Its example is an extension meant only to read data that connects with an identity with UPDATE, INSERT, DELETE, and SELECT rights. The fix belongs in the database permissions of the identity the extension uses.

Least-privilege OAuth scopes

MCP’s best practices apply the same thinking to OAuth scopes:

• Start with a minimal scope set covering low-risk read and discovery operations
• Elevate incrementally through targeted scope challenges when a privileged operation is first attempted
• Avoid wildcard or omnibus scopes such as *, all or full-access
• Keep authorization logic on the server instead of trusting scopes claimed in a token

A coding agent working in development has no reason to hold a credential that also reaches production.

Block token passthrough to downstream APIs

The MCP authorization specification explicitly forbids token passthrough. MCP servers must not accept tokens that were not issued for that server. When tokens are forwarded unchecked, downstream rate limits and validation can be bypassed, and the resource server’s logs record requests under a different identity from the one actually making them. Investigation becomes guesswork.

Keep an audit trail of every tool call

The specification advises clients to log tool usage for audit purposes, and MCP security best practices add logging of scope-elevation events with correlation IDs.

What to record for each tool call

A useful record for each call includes:

• The agent, the user it acted for, and the session
• The MCP server and tool invoked, with input arguments
• The scope or permission the call ran under
• Whether approval was required, and who gave it
• The result status and any error returned
• A correlation ID linking the call to the wider workflow (an OpenTelemetry trace ID works well here)

OpenTelemetry’s GenAI semantic conventions give these records a standard shape. Each tool call maps to an execute_tool span with attributes such as gen_ai.tool.name and gen_ai.tool.call.id, and the MCP conventions add fields like mcp.method.name and mcp.session.id. Any OTel-compatible backend can then query calls by tool, session or trace. Arguments and results are opt-in attributes because they can carry sensitive data, so decide what to capture and redact before switching them on.

Why the audit trail must sit outside the agent

The host or gateway must write these logs, independent of the agent. In the Replit incident, the agent’s own account of recovery options turned out to be wrong. An audit trail generated outside the model is the version of events a team can trust.

Where to start with MCP security

Teams can make measurable progress in three steps:

• Inventory: Catalog every MCP server and tool in use across development and production environments.
• Classify and restrict: Rank each tool by the damage it can cause, and enforce approval gates and least-privilege scopes on the highest-risk tier first.
• Log from day one: Record every tool call centrally, which makes each later control easier to verify. Prefer OTEL compatible logging which can be analysed easily while giving you the ability to deep dive into each call/workflow.

How Opcito helps secure agentic AI tool calls

Opcito works with ISVs and product teams building agentic AI across agent development, agent quality assurance, AI observability and security product engineering. That includes designing tool-call guardrails, scoping agent permissions, testing agent behaviour before release and building the logging that makes every tool call traceable.

To build MCP security into an agentic AI product, talk to Opcito’s engineering team.