AI/LLM Generated

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.

2026 threat context

The threat picture this guidance describes is now the documented baseline. Pillar Security’s investigation of exposed LLM infrastructure between December 2025 and January 2026 Operation Bizarre Bazaar found that by late January 2026, 60% of the total attack traffic had shifted to MCP-focused reconnaissance: a separate threat actor mapping entry points into self-hosted AI stacks. Exposed MCP servers are now the primary attack surface of self-hosted AI, not a hypothetical one.

CVE-2026-59822 is the concrete instance of the failure mode this post describes. It is an authentication bypass in LiteLLM, the open-source AI gateway, affecting all versions before 1.84.0. In the MCP Streamable HTTP endpoint, a fabricated Authorization header triggered an OAuth2 passthrough fallback that replaced the failed LiteLLM key validation with an empty UserAPIKeyAuth() object. The empty object was treated as a successful authentication, so unauthenticated requests could list and invoke the configured MCP tools and everything those tools reach. CVSS 4.0 score: 8.8. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2026-09-02, and vendors have reported exploitation attempts against honeypots probing model enumeration endpoints. A gateway sitting between untrusted traffic and privileged tooling, where an authorization check that appears to run does not actually run, is the worst possible place to trust a fallback path.

The exposure numbers behind that failure mode have grown. Censys counted 12,520 internet-accessible MCP services on 2026-04-28, across 8,758 unique IPs in 56 countries and 425 ASNs, and over 21,000 MCP servers in its dataset by 2026-05-06. OX Security reported a systemic flaw in the MCP STDIO transport in April 2026, with over 150 million package downloads across the official SDKs, 7,000 publicly accessible servers, up to 200,000 vulnerable instances, and 9 of 11 MCP marketplaces accepting malicious servers. Astrix audited 5,200 MCP servers and found that only 8.5% use OAuth. Knostic mapped 1,862 MCP servers exposed to the internet and found that all 119 sampled servers granted internal tool listings without authentication. OpenClaw deployments were scanned in January 2026, with over 42,000 instances exposed.

The vulnerability list has grown alongside the exposure. CVE-2026-30861 (WeKnora): unauthenticated RCE in MCP stdio config validation, where the npx and uvx whitelist was bypassed via npx -p node; affected versions 0.2.5 through below 0.2.10, patched in 0.2.10. CVE-2026-45018 (Chainlit): unauthenticated RCE via POST /mcp, where validate_mcp_command() checked the executable name only and npx -y -c bypassed the check; CVSS 9.8, affected 2.4.0rc0 through below 2.12.0 with features.mcp.enabled=true, patched in 2.12.0, and MCP is disabled by default since 2.7.0. CVE-2026-15583 (Grafana MCP Server): a confused-deputy flaw where an unauthenticated attacker exfiltrates the environment-configured service-account token via a crafted X-Grafana-URL header, with credentialed SSRF including cloud metadata access; CVSS 8.6, affected through 0.17.0, patched in 0.17.1. CVE-2026-45805 (Penpot): the MCP ReplServer binds 0.0.0.0:4403 with an unauthenticated /execute endpoint allowing arbitrary JavaScript execution; CVSS 8.8, fixed in 2.15.0. CVE-2026-23744 (MCPJam Inspector): unauthenticated RCE via the MCP server installation endpoint, where missing authentication and an insecure default network binding let an attacker execute arbitrary commands; affected versions 1.4.2 and below. CVE-2026-30623 (LiteLLM): RCE in MCP server creation, where a JSON config with an arbitrary command and arguments was executed without validation; fixed in 1.83.7. CVE-2026-82456 (argocd-mcp): version 0.8.0 bound the HTTP transport to every interface and accepted MCP sessions without caller credentials when ARGOCD_API_TOKEN was configured, forwarding the stored operator token to Argo CD for any caller; CVSS 10.0, fixed in 0.9.0 with a loopback default, MCP_AUTH_TOKEN, and origin/host validation. CVE-2026-97662 (AWS security-agent-mcp-server): a tool-chain argument-injection case study where a crafted reference value was interpreted as a command-line option, allowing arbitrary host file creation, overwrite, or truncation outside the workspace and bypassing workspace confinement; affected 0.1.1 through below 0.2.0, fixed in 0.2.0. These are the same failure mode as CVE-2026-59822: a trust boundary that appears to run but does not, now seen across the ecosystem.

Related coverage on this blog: Detection Guidance: Auditing Your Homelab for Exposed MCP Servers walks the practical audit for exposed MCP endpoints, and The Gateway in the Middle: Why Your AI Proxy Is a Perimeter Device covers the perimeter role of the AI proxy itself (that post is still a draft in Ghost and may 404 until it is published). A dedicated Malwlab write-up of the LiteLLM MCP auth bypass is in progress. See the related LiteLLM MCP advisory on this blog.

Hardening checklist for self-hosted MCP and tool-using agents

Never bind an MCP or gateway endpoint to 0.0.0.0 without authentication. If it must be reachable on the LAN, put it behind the same perimeter and authentication as everything else on the network.
Treat the AI gateway as a perimeter device, not an internal convenience: the same firewall, reverse proxy, and auth controls you would apply to any other service that is reachable by untrusted traffic.
Least-privilege tool grants: every MCP tool scoped to the minimum resources and actions its workflow needs, read-only by default, with write capability added only when a workflow proves it requires one.
Egress and secret least privilege: agents and gateways should not hold cloud credentials, and the gateway must never pass client or upstream tokens through to other services. The unverified passthrough fallback is exactly what CVE-2026-59822 exploited.
Network-segment agent runtimes from the rest of the lab so a compromised agent cannot reach the hypervisor, the lab network, or credential stores.

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.

Sources

Updated 2026-09-04: added a 2026 threat-context section. CVE-2026-59822 (LiteLLM MCP authentication bypass, CISA KEV-listed) as the concrete worked example, the Pillar Security finding that 60% of documented attack traffic had shifted to MCP endpoint reconnaissance by late January 2026, a hardening checklist for self-hosted MCP and tool-using agents, and internal links to related coverage. The core least-privilege principles are unchanged.

Updated 2026-10-30: added exposure statistics (Censys, OX Security, Astrix, Knostic, OpenClaw) and the 2026 CVE list (WeKnora, Chainlit, Grafana MCP Server, Penpot, MCPJam Inspector, LiteLLM, argocd-mcp, AWS security-agent-mcp-server) to the 2026 threat context section. Added the corresponding primary sources to the source list. The hardening checklist and least-privilege guidance are unchanged.

Topics: