AI Agent Least Privilege: Securing MCP and Tool-Using Workflows
A practical guide to applying least privilege, scoped identities, approval gates, and observability to MCP and tool-using AI workflows.
Tool-using AI systems should be governed like privileged automation—not like an unusually capable chat window.
A production AI agent does not need to “hack” anything to cause an incident. Give it a broadly privileged cloud token, a shell tool, and access to untrusted text, and a malicious instruction can turn an ordinary workflow into an authorized sequence of API calls.
That is the uncomfortable part: the credentials may be valid, the request may come from an expected runtime, and the resulting action may resemble normal automation. The failure is not necessarily that a model generated an unsafe sentence. The failure is that the surrounding system granted a probabilistic decision layer more authority than the task required.
Security teams already know how to limit the blast radius of compromised automation. The same principles apply here: narrow identities, scoped access, independent authorization, meaningful approval, useful telemetry, and quick revocation.
An agent with tools is an automation identity
A read-only chatbot and an agent that can invoke tools have different risk profiles. The second can query internal systems, create tickets, update infrastructure, send messages, execute scripts, or write files. The model is the decision layer; risk becomes concrete at the point where that decision becomes an authenticated action.
The useful question is therefore not “Can the model be trusted?” It is: what can this identity do when the model is mistaken, manipulated, or working from incomplete context? NIST’s zero-trust model emphasizes least-privilege, per-request access decisions rather than trusting a requester merely because it is inside a familiar environment. That framing translates cleanly to agent tools: authorization for one resource or action should not silently become authority over another.
If an agent summarizes incident tickets, it may need read access to one queue and permission to create a draft ticket. It does not automatically need organization-wide search, user administration, outbound messaging, or repository deletion. If it has those powers anyway, least privilege has already failed—regardless of how polished the system prompt looks.
MCP makes the integration boundary explicit
The Model Context Protocol (MCP) standardizes how clients discover and invoke tools. That is useful infrastructure, but it also means an MCP server should be treated as a production integration boundary—not as a harmless plugin. MCP tools can be model-controlled: a model may discover and invoke them based on its context and prompts. The specification says there should be a human in the loop who can deny tool invocations, and recommends confirmation for sensitive operations, input display, result validation, and audit logging. See the MCP Tools specification.
Model/client, MCP server, and downstream service are separate trust zones. A careful client policy cannot compensate for an MCP server holding a production-admin token. Nor can a well-scoped backend save a workflow that unnecessarily exposes secrets or broad datasets to the model. Design and review each boundary separately.
Start with a capability map, not a broad token
Before configuring IAM, write the workflow as a bounded sequence:
- What starts the run, and which inputs are untrusted?
- Which data is necessary to read?
- Which state may change, and which changes are reversible?
- Which actions affect production, money, identity, secrets, or external communications?
- What should happen when the agent is uncertain?
Use the answers to create discrete capabilities. get_alert, search_runbooks, create_draft_ticket, and request_approval are easier to authorize and observe than one generic security_api(action, payload) wrapper. OWASP identifies excessive functionality, permissions, and autonomy as common causes of “excessive agency”; its guidance is direct: minimize the extensions, permissions, and autonomy an LLM-based application receives. OWASP LLM06:2025.
This map should become a review artifact. If a permission cannot be tied to a documented action, remove it. The default toolset should be read-only; add narrowly designed write tools only when a workflow proves it needs them.
Give each workflow a narrow, revocable identity
Do not run every agent and MCP server with one shared “AI automation” token. A distinct workload identity per environment, agent, and meaningful capability group reduces over-provisioning and makes investigations possible. Separate a development research agent from a production deployment agent; separate a reader from a writer; separate draft creation from publication.
Scope that identity across five dimensions: resource (one repository, queue, bucket prefix, or schema), action (read, create draft, constrained update), time (short-lived rather than static credentials), context (expected runtime or network path), and environment (development, staging, production). Broad read access is not harmless: it can expose code, customer data, incident details, and secrets that may later influence model behavior.
For HTTP-based MCP authorization, the protocol requires servers to accept tokens intended for themselves and prohibits passing the client’s token through to upstream APIs. It also requires clients to identify the target resource when requesting a token. MCP Authorization provides the protocol details; OAuth deployments should also follow current security guidance such as IETF RFC 9700.
Put policy gates between intent and impact
A model can propose an action; it should not unilaterally authorize every action. Low-risk, deterministic work—retrieving an approved runbook or creating a draft ticket—may be automated. Consequential actions should cross a deterministic policy boundary outside the model.
| Risk tier | Example | Control |
|---|---|---|
| 0 | Narrow read-only retrieval | Scoped identity, typed query, audit log |
| 1 | Reversible internal write or draft | Schema validation, allowlisted target, review queue |
| 2 | Configuration or deployment change | Change window, ticket reference, independent policy check |
| 3 | Deletion, credential change, external message, data export | Explicit human approval with action, target, parameters, and expiry |
Approval must be meaningful. “The agent wants to continue” is not a change-control record. Show the exact target, parameters, planned diff or action, invoking identity, reason, and expiry. Downstream services must still enforce authorization themselves; model instructions are not an access-control mechanism.
Treat retrieved content and tool output as untrusted data
Web pages, emails, tickets, pull requests, logs, RAG results, and tool output can carry instructions intended to redirect an agent. OWASP describes indirect prompt injection as a risk when external content alters an LLM’s behavior; MITRE ATLAS classifies it as a demonstrated technique delivered through separate data channels such as websites and databases. OWASP LLM01:2025 and MITRE ATLAS AML.T0051.001 both support treating those inputs as hostile-capable data.
Label content by origin. Keep authorization policy outside retrieved text. Do not let document content expand permissions or alter allowlists. Restrict tool arguments to typed schemas and approved values. Where feasible, separate document processing from action execution and re-check policy before every side effect. No prompt filter is a substitute for an identity that simply lacks the power to exfiltrate data or change production systems.
Make tool use observable and revocable
Agent tool calls are security telemetry. Record the requesting user or workflow, agent identity, model/client version, MCP server, tool name, approved arguments or safe hashes, policy decision, downstream target, result, and approval reference. Avoid indiscriminately retaining sensitive prompts or secrets.
Then look for behavior outside a workflow’s normal profile: sudden enumeration across resources, new egress destinations, repeated denials, malformed arguments, approval-bypass attempts, or high-impact activity outside an approved window. Join this data with cloud, identity, Git, SIEM, and network telemetry so investigators can reconstruct the chain from retrieved context through policy decision to API call.
Finally, build for safe failure. If identity verification, policy evaluation, approval lookup, validation, or logging fails, the action should fail closed. Every deployment needs a kill switch: revoke the workload identity, disable the MCP server, block egress, and stop queued actions. Start with narrowly scoped read-only tools, introduce constrained draft creation, observe behavior, and only then graduate to production actions with explicit approval.
The least-privilege test
Ask one question before connecting an agent to production tools: if an attacker controlled the next 500 tokens entering this agent’s context, what is the worst action it could successfully take? The answer should be limited, explainable, logged, reversible where possible, and quickly revocable. Least privilege will not eliminate agent failure. It does make failures smaller, more detectable, and more recoverable.