The core rule
A model may request a tool call, but trusted backend code must decide whether it can execute.
Tool calling becomes risky when the model output is treated as permission. A model can propose useful actions, but the system still needs to check identity, scope, input shape, source boundaries, and policy before execution.
This is especially important when tools touch customer data, databases, payments, internal systems, support workflows, or operational APIs.
Threat model
Tool calling creates risk because the model can request actions that affect systems outside the chat.
| Risk | What it looks like | Control |
|---|---|---|
| Prompt injection | User or retrieved content tries to steer the model into calling a sensitive tool. | Keep policy outside the prompt and validate every tool call server-side. |
| Excessive agency | A tool can perform too many actions or touches too much data. | Publish narrow tools with scoped permissions and clear action boundaries. |
| Sensitive data exposure | Tool results or logs include secrets, tokens, connection strings, or private records. | Redact logs, limit result fields, and keep credentials server-side. |
| Unsafe database access | Generated SQL reads tables or columns outside the approved scope. | Use metadata-only schema tools and validated executor tools. |
| Unbounded usage | An agent repeatedly calls tools and burns quota or stresses upstream systems. | Apply rate limits, quotas, timeouts, and cancellation controls. |
Security checkpoints
The validation layer should run before the upstream API or database sees the request.
- Authenticate the client or user.
- Check source ownership and publication state.
- Validate structured arguments against the tool schema.
- Enforce table, column, relationship, and read-only rules for database tools.
- Keep upstream credentials and connection strings server-side.
- Apply rate limits and quotas.
- Redact sensitive values before logging.
- Return clear errors without exposing internal secrets.
Example validation policy
A useful policy is concrete enough for backend code to enforce before execution.
The exact format can differ by product, but the policy should express the caller, tool, source scope, allowed operations, allowed fields, and result limits. If the server cannot validate the request against policy, it should reject the call before touching the upstream system.
Example server-side tool policy
json{
"tool": "search_orders",
"caller": {
"type": "user",
"plan": "team"
},
"sourceScope": {
"integrationId": "int_123",
"allowedOperations": ["GET /orders"],
"allowedFields": ["id", "status", "createdAt", "total"]
},
"limits": {
"maxRows": 50,
"timeoutMs": 8000,
"rateLimitKey": "team:acme"
},
"logging": {
"redact": ["authorization", "email", "phone", "connectionString"]
}
}Common mistakes
Most tool calling incidents start with too much trust in the wrong layer.
| Mistake | Better approach |
|---|---|
| Put credentials in prompts or local config. | Store credentials server-side and issue scoped client tokens. |
| Expose one broad tool for many actions. | Publish narrow tools with clear descriptions and schemas. |
| Let SQL text run because the model wrote it. | Validate SQL or use structured QueryPlan mode before execution. |
| Log full payloads by default. | Redact sensitive values before persistence. |
| Treat tool descriptions as security rules. | Descriptions help model selection, but enforcement must live in trusted backend code. |
| Return full upstream errors to the client. | Return useful errors without leaking headers, tokens, stack traces, or database details. |
API tool validation
For API-backed tools, the server should validate the operation before forwarding the request.
- Confirm the tool is published and belongs to the current owner or workspace.
- Map the tool to a known upstream operation instead of trusting a client-supplied URL.
- Validate path, query, header, and body arguments against the stored schema.
- Strip or override headers that the client is not allowed to set.
- Apply plan limits, upstream credential policy, timeout, and retry rules.
Database tool validation
For database-backed tools, schema visibility and data execution should be separate concerns.
A safe database tool design does not let the model browse the whole database or run arbitrary SQL. Schema tools should return metadata only. Executor tools should validate table, column, relationship, filter, aggregation, and row-limit rules before any query runs.
A structured QueryPlan is easier to validate conservatively than free-form SQL because the system can inspect tables, columns, joins, filters, and limits before generating or executing a database query.
Trusted boundary
Tool calling needs a trusted execution boundary outside the model.
A practical boundary keeps credentials, validation, limits, and audit behavior outside the model. MCP clients and agents can request tool calls, but trusted backend code decides what reaches the upstream system.
This boundary should be testable. A team should be able to prove that an unpublished tool cannot run, a caller cannot cross workspace ownership, a database query cannot read hidden columns, and sensitive values do not land in persistent logs.
Sources and further reading
Common questions
Can prompts enforce tool security?
Prompts can guide behavior, but they are not a security boundary. Enforcement should live in trusted backend code.
Should tool calls be logged?
Yes, but logs should be redacted. Teams need observability without storing secrets, connection strings, or sensitive payload values.
Is MCP itself a security boundary?
No. MCP defines how clients and servers exchange capabilities and tool calls. The security boundary is the trusted server-side implementation that validates identity, scope, arguments, and execution policy.
What is the safest database tool pattern?
Use metadata-only schema tools and validated executor tools. QueryPlan mode is easier to validate conservatively than free-form SQL.
Should high-risk tools require confirmation?
Often yes. Actions that write data, trigger payments, modify permissions, or affect production systems should use stronger controls such as explicit confirmation, smaller scopes, or approval workflows.