Skip to content
← Back to blog

AI and agents

MCP agents: useful by design, safe by control

How to expose tools to an agent without turning every integration into an implicit permission.

Published on August 8, 20268 min read
MCPAgentesOAuth

MCP standardizes how an application discovers tools and context, but it does not remove the need for boundaries. A server that can read files, query customers or deploy software should start with least privilege and explicit scopes.

Authorization belongs at the actual resource boundary. The client may request consent, but the server still validates identity, audience, scope and data ownership. Sensitive operations benefit from separate read and write capabilities, confirmation and audit logs.

Editorial visual

Control layers for an MCP tool

Topic illustration
Agent connected to identity, validation, confirmation and audit controls before reaching a protected resource
Security does not depend on one confirmation: every boundary validates identity, intent and scope again.

Tool descriptions and responses are untrusted input. Schema validation, size limits, controlled chaining and a clear preview of effects reduce confusion, redirect and privilege-escalation attacks.

The practical test is simple: when the agent misinterprets an instruction, the system should fail within a small boundary. Good MCP design makes errors visible, reversible and auditable.

Model threats before publishing tools

Start by identifying actors and boundaries: user, AI client, MCP server, identity provider and final system. Each hop changes who controls the data and where a request must be rejected. A valid token is not enough when it was issued for another audience, organization or resource.

Small contracts and explicit effects

A safe tool does one job, uses a closed schema and describes its effect in observable language. Splitting read, prepare and execute is safer than exposing a generic operation. The server resolves identifiers, and repeatable actions use idempotency keys to prevent duplicates.

Approval proportional to risk

Reading public documentation does not need the same control as sending a payment or deploying production. Classify tools by risk and request confirmation only when it adds value. The prompt should show destination, scope and expected change instead of a generic message users accept out of habit.

Operate as if the model can be wrong

Rate limits, size limits, short expiration, secret rotation and a kill switch reduce the blast radius. Logs should connect user, tool, normalized arguments, authorization and result while excluding credentials and sensitive data that are not required for investigation.

Release criterion

The integration is ready when a wrong interpretation produces a bounded, understandable and reversible error. If control depends on the model behaving correctly, there is still no real security boundary.