The Model Context Protocol gives AI agents a standard way to invoke external tools — search, file access, database queries, API calls — through a single, composable interface. That generality is also the risk: a blanket "this agent can use this MCP server" grant is effectively an all-or-nothing decision across every capability the server exposes. Least-privilege design means breaking that grant down to the tool level and being deliberate about what each agent can call, when, and how often. Getting this right is one of the most concrete steps you can take toward safe, policy-governed MCP server deployments. For a primer on what MCP is and how it works, see what is the Model Context Protocol?.
Why a server-level grant is not enough
When you connect an agent to an MCP server, the server may expose dozens of tools: read operations, write operations, destructive operations, and administrative functions all sitting behind the same endpoint. A server-level access grant treats them all as equivalent. An agent authorized to query a database with db.read gains the same standing as if db.drop_table were on the menu — unless you explicitly enforce a boundary at the tool level.
This is the same problem that motivated per-scope OAuth grants over blanket API key access. The blast radius of a misconfigured or compromised agent is bounded by the narrowest permission it holds, not the broadest. If a tool list is not explicitly scoped, that narrowest permission is "everything the server offers." This dynamic is explored in depth in Threat Model: Over-Broad MCP Tool Scope.
The anatomy of a tool permission
At minimum, a tool permission should express three things:
Identity: which agent or set of agents can invoke the tool. This is usually tied to the agent's registered identity, not just the connection it arrives on.
Capability boundary: which specific tool names are permitted. A well-defined allow-list means new tools added to the server in the future are denied by default rather than silently inherited.
Rate and cost limits: how frequently the tool can be called, and what the maximum per-call or aggregate cost budget is. Rate limits prevent a looping agent from hammering a downstream service; cost caps prevent runaway spend from unbounded tool chains.
Optional but valuable additions include read-only vs. write-only splits (for servers that expose both), time-of-day or environment restrictions, and a require-approval flag for irreversible actions.
Allow-lists over deny-lists
When defining which tools an agent can access, prefer an allow-list approach: name the tools that are permitted, and deny everything else implicitly. Deny-lists have a structural weakness — they need to be updated every time the server adds a new tool, and an oversight means the new tool is silently permitted.
Allow-lists invert the default. A new tool the server author adds is not available to any existing agent until someone explicitly extends the grant. That friction is valuable; it creates a moment to decide whether the new capability is appropriate for each consumer.
In practice, building allow-lists requires knowing what tools a server exposes. The MCP discovery step — connecting to the server and enumerating its capabilities — is therefore a prerequisite to defining meaningful permissions, not just a convenience for documentation.
Governance beyond the allow-list
An allow-list tells you which tools an agent is permitted to call. Governance asks the question at call time: given everything we know right now, should this specific invocation proceed?
A governance policy gate evaluates each tool call against a set of rules and returns one of several decisions:
- Allow: the call proceeds normally.
- Deny: the call is blocked and an error is returned to the agent.
- Step-up: the call is held pending a human approval or an elevated-authentication check.
- Observe: the call proceeds, but is flagged for review — useful for new tool grants you want to audit before deciding whether to tighten.
Policy decisions are contextual rather than static: beyond the tool name, the gate evaluates a combination of runtime signals including content, behavioral, and resource signals to determine the appropriate response. Combining these signals gives you adaptive control rather than a static list.
Per-tool rate limits and cost controls
Rate limits on tool access serve two distinct purposes that are easy to conflate.
The first is protecting downstream systems. Many MCP servers wrap external APIs that have their own rate limits or usage costs. Letting a single agent consume those without constraint can affect other tenants, exhaust quotas, or run up invoices the agent operator never anticipated.
The second is anomaly detection. A sudden spike in calls to a particular tool — especially a write or delete tool — is a signal worth investigating. Per-tool rate limits make that spike visible as a rate-limit event rather than something you only notice when the downstream API complains or a bill arrives.
Cost controls at the tool level work similarly. Each tool call can carry an estimated cost — either a token cost if the tool invokes a model, or a monetary cost if it calls a priced external API. Tracking that cost per call, per session, and per agent gives you the attribution data you need to manage spend proactively. A hard cap that blocks invocations once a threshold is reached is the backstop when monitoring and alerts are not enough.
Forensic logging of tool calls
When an agent invokes a tool, the arguments it supplies and the result it receives are the record of what actually happened. Logging them creates an audit trail that answers the questions that matter most after an incident: what data did the agent send to this tool, what did the tool return, and did the call succeed? For a broader view of what a forensic-grade audit trail requires, see How to Monitor MCP Tool Calls.
A high-integrity forensic record captures the tool name, the policy decision that was applied, call latency, success or failure, and the full input/output. Ideally, records are tamper-evident — signed or hash-chained so that the log entry cannot be silently modified after the fact. This matters both for internal incident response and for compliance obligations that require evidence of what AI systems did with sensitive data.
The trade-off is storage: arguments and results can be large, and some may contain sensitive information. A sensible approach is to capture the full record at call time and apply retention policies and data subject rights handling through a defined erasure path, rather than avoiding the capture entirely and losing observability.
Least privilege in practice: a decision framework
Designing least-privilege MCP tool access does not need to be a one-off exercise. The following sequence applied when onboarding a new server or granting a new agent access keeps the approach systematic:
- Enumerate: run capability discovery to get the full tool list from the server.
- Classify: group tools by sensitivity — read-only vs. write, reversible vs. destructive, personal data vs. system data.
- Match to use case: determine which tools the agent actually needs for the workflows it will run. Start from the minimal set.
- Set rate and cost limits: for each permitted tool, define a per-minute or per-hour call limit and a per-call cost ceiling where applicable.
- Choose an enforcement mode: allow, observe, or require step-up for sensitive tools. Irreversible operations (deletes, sends, publishes) are candidates for step-up.
- Review the forensic log: after the agent runs in production for a week, review what it actually called. Revoke permissions for tools it never used.
The last step is the one most teams skip. Tool grants accumulate quietly. Regular review against actual usage is the mechanism that keeps permissions genuinely minimal rather than just theoretically minimal.
How Praesidia approaches tool-level governance
Praesidia is designed to enforce tool permissions at the call layer, not just at the connection layer. When an agent issues a tool call through a registered MCP server, the governance policy gate evaluates it before the invocation proceeds. The decision — allow, deny, step-up, or observe — is recorded alongside the tool name, arguments, and result in a tamper-evident forensic log.
Per-tool rate limits are configurable per server, and cost tracking at the tool level feeds into the broader credit and budget system, so a tool-heavy agent run shows up in the same spend view as a token-heavy inference run. The allow-list model means that when a server adds new tools, existing agents do not inherit access to them automatically.
For more on how Praesidia governs MCP connections and tool access end-to-end, see registering and governing MCP servers for how the full governance surface — capability discovery, health monitoring, and forensic logging — applies without additional configuration.
Common questions
Does every tool need its own rate limit, or can I set a server-level limit?
A server-level limit is a useful baseline and easier to set up, but it does not distinguish between a cheap read tool that gets called hundreds of times legitimately and a destructive write tool that should be called rarely. Per-tool limits let you be precise: high limits for idempotent reads, low limits or step-up enforcement for writes and deletes. Start with server-level limits and move to per-tool controls for the tools that carry the most risk.
What happens when a policy decision blocks a tool call?
The agent receives an error response indicating the call was denied. The denial is logged in the forensic record with the policy decision that caused it. Depending on how the agent is designed, it may surface the error to a human operator, attempt an alternative path, or halt the current task. Well-designed agents treat denied tool calls as signals to escalate rather than errors to retry indefinitely.
How do I handle tools that interact with personal data?
Flag those tools as sensitive during classification and apply the observe or step-up mode initially. Log the full argument and result payload, and ensure your retention and erasure policies cover those records — if a data subject requests erasure, tool call logs containing their data need to be included in the scope. Keeping that data in a queryable forensic store rather than mixed into application logs makes that process tractable. For how PII flows through AI pipelines more broadly, see PII detection and redaction in AI pipelines.
How does tool-level scoping interact with prompt injection? Strict tool scoping is the most effective blast-radius limiter for prompt injection attacks. An agent that can only call a named read tool cannot be weaponized by an injected instruction to write, exfiltrate, or delete — regardless of what the injected text says. This is why defining the minimal allow-list before an agent goes to production is a security control, not just an operational preference. For a full treatment of prompt injection defenses, see prompt injection threats and defenses.