MCP Tool Security Checklist
Review provenance, authorization, credentials, schemas, transport, isolation, approvals, monitoring, and rejection rules.
Open guideOperational risk
Treat security and cost as one system design problem
The same decisions that make an agent expensive—long loops, broad context, many tools, repeated retries—often increase its security exposure. Plan both before deployment and measure them per accepted outcome.
Model Routing and Cost Controls
Optimize cost per accepted outcome with evaluated tiers, caching, batch, bounded retries, fallbacks, and budgets.
Open guidePrompt Injection Risks for Browser Agents
Map untrusted web content to dangerous capabilities and apply isolation, tool policy, approval, egress, and safe evaluation controls.
Open guideAI Agent Security Checklist
Map identity, data, tool, output, dependency, and monitoring controls before an agent reaches production.
Open guideAI Automation Cost Model
Estimate cost per accepted outcome using model calls, retries, tools, infrastructure, review, and failure handling.
Open guideWhere risk and cost reinforce each other
More autonomy
More tool choices and longer loops increase both attack surface and variable cost.
More retries
Retries may improve completion but can duplicate side effects and hide unstable behavior.
More context
Larger prompts can increase cost while exposing additional sensitive data to the model path.
More review
Human review adds cost but may be mandatory when errors are expensive or irreversible.
Start with the workflow readiness checklist to determine whether the process is stable enough. Then use the security guide to constrain access and the cost model to set budgets, retry caps, and review thresholds.
Review the full action path
A production review should follow one task from authenticated request to accepted result. Record the source data, model and workflow versions, proposed tools, policy decisions, approvals, executed side effects, retries, validation, and full cost. This reveals risks that are invisible when security and budget are reviewed in separate documents.
Before execution
Verify identity, data classification, task scope, allowed destinations, credential scopes, and the exact conditions that require approval.
During execution
Enforce typed tool contracts, network policy, step and spend ceilings, idempotency, and trace correlation across model, browser, connector, and human actions.
After execution
Validate the external result, measure acceptance and correction, preserve an audit record, revoke temporary access, and turn meaningful failures into regression cases.
For browser-connected systems, apply the prompt-injection threat model. For every agent, use the observability contract so security events and cost changes share the same task identifier.
Document residual risk in plain language: what could still happen, who would notice, how quickly access can be stopped, and which user or business outcome absorbs the consequence. Include both ordinary mistakes and deliberate abuse. If that consequence is unacceptable, narrow the task or remove the capability.
Turn each risk decision into a control and a budget line
Security controls are not free, but omitting them does not make risk free. The cost moves into corrections, support, unauthorized access, duplicate side effects, or emergency response. A useful design review records both the preventive control and the operating resources needed to keep that control effective.
| Risk area | Control decision | Cost to include |
|---|---|---|
| Identity and authorization | Narrow service identities, short-lived credentials, per-tool policy, and approval for higher-impact actions. | Credential brokerage, policy checks, approval handling, access review, and incident response. |
| Data exposure | Classify inputs, minimize context, redact secrets, constrain retention, and restrict destinations. | Redaction, private storage, egress controls, data review, and larger prompts when raw context is not minimized. |
| Untrusted instructions | Separate data from authority, isolate browsing, validate tool arguments, and treat retrieved content as untrusted. | Sandboxing, allowlists, policy evaluation, security tests, and manual handling for blocked cases. |
| Retries and recovery | Use idempotency keys, typed failure classes, checkpoints, compensation, and hard attempt ceilings. | State storage, duplicate detection, recovery engineering, and the expected cost of failed or repeated actions. |
| Monitoring and response | Correlate decisions with side effects, alert on meaningful policy or cost events, and maintain a stop mechanism. | Telemetry, retention, on-call time, investigation, regression tests, and emergency access revocation. |
This pairing helps resolve false tradeoffs. For example, human approval may appear expensive, but approval can be limited to novel destinations or amounts above a threshold. Sandboxing may add infrastructure cost, but it can permit safer automated handling of low-impact browser tasks. The question is not whether a control costs money; it is whether the reduced expected loss and increased confidence justify that cost for this action.
Calculate by accepted outcome, then stress the assumptions
Start with a unit of work users recognize, such as an accepted research brief, correctly updated record, or resolved support case. For a period, add model usage, search and browser fees, workflow infrastructure, storage, monitoring, human review, corrections, failed attempts, and allocated support effort. Divide by accepted outcomes after validation—not by initiated or nominally completed runs.
Then test the variables most likely to move together. A lower-quality model may increase retries and review. More context can increase both token cost and data exposure. Longer autonomous loops may improve completion on difficult cases while increasing tail latency and the number of tool actions requiring investigation. Scenario analysis should change these linked assumptions together rather than reducing model price in isolation.
Set two ceilings: a per-run stop limit and a period-level operating threshold. The first contains runaway loops; the second catches gradual drift caused by harder traffic, a model change, higher intervention, or an integration becoming unreliable. When a ceiling is reached, preserve the state and failure class so an operator can decide whether to resume, simplify, or abandon the task.
Common security and cost blind spots
Pricing only successful model calls
Include failed attempts, tool fees, infrastructure, review, correction, and incident work. The denominator should be accepted outcomes, not API requests.
Granting one broad credential for convenience
A shared powerful identity makes attribution and containment difficult. Scope access by task, environment, destination, and duration.
Logging everything for future debugging
Unbounded traces can become a sensitive-data store. Define fields, redaction, access, retention, and deletion before production.
Approving an entire run at the beginning
The risky action may not be known yet. Put approval next to the concrete destination, arguments, amount, and expected effect.
Treating blocked work as zero cost
A safe denial may still consume model calls and operator time. Track it separately so policy tuning does not silently raise operating cost.
Release decision
Proceed only when the action path has an owner, least-privilege access, enforceable limits, tested recovery, outcome validation, measurable unit economics, and a residual risk the business explicitly accepts. If the expected consequence remains too high, reduce the data, tools, destinations, or autonomy rather than relying on a stronger prompt.