{"slug": "mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-ai", "title": "MCP Tool Exposure is a Privilege Grant: A Two-Gate Authorization Model for Agentic AI", "summary": "Security practitioner Badal Bhushan proposed a two-gate authorization model for Model Context Protocol (MCP) tool use, published October 20, 2026, separating \"Capability Admission\" (whether a capability should be exposed to an agent at all) from \"Execution Authorization\" (whether a specific use against a specific resource should be allowed). Bhushan argues that exposing a tool to an agent expands its operational privilege surface, and that MCP's tools/list discovery mechanism is useful for shrinking that surface but is not an authorization boundary, since a tool absent from the list must not be executable via a direct request. He recommends applying \"least capability before relying on least privilege,\" favoring narrow functions such as restartApprovedService(serviceId) over generic primitives like executeCommand(command).", "body_md": "# MCP Tool Exposure is a Privilege Grant: A Two-Gate Authorization Model for Agentic AI\n\nPublished 10/20/2026\n\n**Written by**\n\n**Badal Bhushan**\n\n**.**\n\nModel Context Protocol is quickly becoming a common way for AI agents to connect to the systems around them. Through MCP, an agent can search a repository, query a database, create a ticket, send a message, update a record, invoke an API, or trigger a workflow.\n\nThat makes interoperability much easier. It also changes the security significance of something that can look fairly harmless: the tool catalog.\n\nConsider an agent that can see four tools:\n\n`searchDocuments()`\n\n`sendEmail()`\n\n`createUser()`\n\n`deleteEnvironment()`\n\nThese are not equivalent pieces of application functionality. They represent very different levels of authority.\n\nOnce a tool is exposed to an agent, we have given the model the ability to consider that capability as part of its plan. That is not the same as granting backend authorization, but it does expand the agent's operational privilege surface.\n\nThis is where I think MCP security needs to keep two decisions clearly separated.\n\n**Gate 1: Capability Admission.** Should this capability be available to this agent in the first place?\n\n**Gate 2: Execution Authorization.** Given the current identity and context, should this particular use of the capability be allowed against this particular resource?\n\nAuthentication to the MCP server is a prerequisite. These two gates come after identity has been established.\n\nThe distinction matters because discovering a capability and being authorized to exercise it are not the same thing.\n\n## Gate 1: Control What Enters the Agent's Capability Surface\n\nWe already apply least privilege to users, service accounts, applications, and workloads. The same principle needs to start one step earlier for agents, with the capabilities placed in front of the model.\n\nOWASP's work on excessive agency makes this point from another direction: risk grows when an AI system is given more functionality, permission, or autonomy than it needs.\n\nThe shape of the tool itself matters.\n\nCompare:\n\n`executeCommand(command)`\n\nwith:\n\n`restartApprovedService(serviceId)`\n\nBoth could ultimately restart a service, but they create very different security boundaries. In the first case, the model controls a generic execution primitive. In the second, sensitive execution logic remains inside deterministic application code.\n\nThe same principle applies to `writeFile(path, content)` versus `writeGeneratedReport(reportId, content)`, or a generic `sendEmail()` capability versus a constrained function for sending an approved workflow notification.\n\nThis suggests an extension to least privilege that is particularly relevant to agents:\n\n**Apply least capability before relying on least privilege.**\n\nDo not give a probabilistic decision-maker a general-purpose function when a narrower capability can satisfy the task.\n\nThis is not only about malicious agents. An agent may choose the wrong tool because of prompt injection, poisoned content, ambiguous instructions, bad context, or ordinary model error. Reducing the available capability surface limits what any of those failures can turn into.\n\n## `tools/list` Is Useful, but It Is Not an Authorization Boundary\n\nMCP's tool discovery model gives us an opportunity to reduce that surface.\n\nIf a research agent has no legitimate reason to administer cloud infrastructure, there is little value in showing it `deleteCluster`. A customer-support agent should not discover payroll administration tools simply because the same MCP environment happens to expose them.\n\nFiltering or constructing the tool list according to the agent's purpose can reduce accidental selection and shrink the capability surface available to an attacker who succeeds in manipulating the model.\n\nBut this control has an important limit.\n\nA tool that is absent from `tools/list` must not become executable simply because a caller constructs a direct request for it.\n\nDiscovery filtering is risk reduction. It is not authorization.\n\nThat is why a second gate is necessary.\n\n## Gate 2: Treat the Tool Call as a Request, Not a Command\n\nWhen the model chooses a tool, what it has really done is express intent.\n\n\"I want to invoke this capability.\"\n\nThe security architecture should not translate that automatically into:\n\n\"Execute it.\"\n\nFor consequential operations, a trusted enforcement point outside the model should decide whether the request is authorized.\n\nThis is consistent with the direction CSA has been taking in its work on the Agentic AI Runtime Security Model and its research on agentic tool misuse: once AI systems can act, security has to move closer to the action itself.\n\nThe authorization decision also needs more information than \"Does the caller have a valid access token?\"\n\nFor an agentic transaction, we may need to know who initiated the activity, which application is involved, which agent selected the action, which workload is executing it, how authority reached that agent, which tool is being requested, what operation it will perform, which resource it will affect, and what the current risk or transaction context looks like.\n\nThe useful question is no longer simply:\n\n**Can this agent call this tool?**\n\nIt becomes:\n\n**Can this agent, acting under this authority, use this tool to perform this action against this resource now?**\n\nThat is a much stronger authorization boundary.\n\n## MCP Server Access Should Not Collapse Into Tool Access\n\nImagine an MCP server that exposes:\n\n`getDeploymentStatus`\n\n`restartDeployment`\n\n`rotateCredential`\n\n`modifyFirewall`\n\n`deleteDeployment`\n\nAn agent might have a perfectly legitimate reason to call `getDeploymentStatus`.\n\nThat does not mean successful authentication to the MCP server should grant equivalent authority over every other tool.\n\nThere are separate decisions hiding behind that connection.\n\nCan the client reach the MCP server?\n\nWhich capabilities should the agent discover?\n\nWhich capabilities may it invoke?\n\nAnd if an invocation is allowed, which target resources may it affect?\n\nOAuth is an important part of this architecture. Scopes, resource indicators, token exchange, and sender-constrained credentials can all help establish and protect an authorization envelope.\n\nBut an OAuth scope does not necessarily express the complete transaction.\n\nA scope such as `payments.write` may tell us something important about the kind of access being requested. It does not, by itself, answer which payment, from which account, for what amount, under whose delegated authority, or whether the current circumstances make the transaction acceptable.\n\nThe closer an agent gets to a consequential action, the closer authorization needs to get to the actual resource and transaction.\n\n## Keep the Final Security Decision Outside the Model\n\nThere is another reason the second gate matters.\n\nThe model cannot be the component responsible for deciding whether its own requested action is authorized.\n\nA system prompt that says, \"Never call this tool unless the user is authorized,\" may be useful behavioral guidance. It is not an access-control mechanism.\n\nAgentic systems consume untrusted inputs. They retrieve external data. They reason over changing context. Their plans can be influenced by prompt injection, tool output, memory, or other agents.\n\nSecurity architecture should therefore assume that an agent will eventually request an action that should not be allowed.\n\nThe objective is not to make unauthorized intent impossible.\n\nThe objective is to stop unauthorized intent from becoming execution.\n\nPut differently:\n\n**The model can propose the action. A deterministic security control should decide whether that action is allowed to run.**\n\nThat control might be implemented directly in the application, at the MCP server, through an authorization service, or through an externalized Policy Enforcement Point and Policy Decision Point model such as the one standardized by OpenID AuthZEN.\n\nThe implementation can vary. The separation of responsibility should not.\n\n## Do Not Stop at the Tool Name\n\nEven authorizing the tool may still be too coarse.\n\nSuppose an agent may invoke `updateCustomerRecord`.\n\nWhich customer's record?\n\nIf the tool is `deployApplication`, does the authorization cover development, production, or both?\n\nIf the tool is `transferFunds`, which account and what transaction limit?\n\nThe target resource is part of the authorization decision.\n\nThis is particularly important when an MCP server itself holds credentials to downstream systems. A tool invocation can appear perfectly authenticated while still causing the server to exercise authority the caller should never have been able to trigger.\n\nThe tool name tells us what capability is being requested.\n\nThe resource tells us where the consequence lands.\n\nSecurity needs both.\n\n## Five Rules I Would Apply to MCP Tool Authorization\n\nOrganizations adopting MCP do not need a new identity protocol to start applying this model. They can begin with five rules:\n\n- **Treat adding a tool as a privilege change.** A new agent-callable tool changes what the autonomous system can potentially do, especially when the tool can write, delete, execute, administer, communicate externally, or initiate transactions.\n- **Prefer narrow capabilities over generic primitives.** Keep security-sensitive choices in trusted code wherever possible instead of exposing them as model-controlled parameters.\n- **Reduce unnecessary discovery, but never depend on it.** Use tools/list to minimize capability exposure while still enforcing authorization independently at invocation time.\n- **Authorize the action against the target resource.** \"Agent A can use Tool B\" is often too broad. The decision should include what the tool is trying to do and what it is trying to affect.\n- **Keep enforcement outside the reasoning layer.** The agent can decide what action it wants to request. A trusted security component decides whether it is permitted.\n\n## From Tool Governance to Action Governance\n\nMCP is helping AI systems make the transition from generating information to taking action.\n\nThat changes what security teams need to govern.\n\nWhen an agent can send a message, modify infrastructure, change a customer record, deploy code, or initiate a transaction, the tools placed in front of that agent are part of the privilege model.\n\nControlling which capabilities become available is the first gate.\n\nControlling whether a requested capability may actually be exercised against a particular resource is the second.\n\nThe distinction can be summarized simply:\n\n**tools/list** **describes the capabilities an agent may be able to discover.** **tools/call** **expresses an action the agent wants to take. Neither, on its own, proves that the action is authorized.**\n\nAs agentic systems become more capable, identity security cannot stop at authenticating the actor or issuing a token.\n\nIt also has to govern what capabilities enter the agent's reach and what happens when the agent decides to use them.\n\nAn MCP tool is part of that privilege surface.\n\nWe should treat it like one.\n\n#### About the Author\n\nBadal Bhushan is a Distinguished Engineer and cybersecurity leader specializing in identity and access management, Zero Trust, workload identity, authorization, and agentic AI security. He has more than two decades of experience designing large-scale authentication, authorization, and security architectures and researches identity, delegation, and runtime authorization models for autonomous AI systems.\n\n###### Unlock Cloud Security Insights\n\n*Subscribe to our newsletter for the latest expert trends and updates*\n\n###### Related Articles:\n\n###### [PQC is a Stress Test for Enterprise DNS](https://cloudsecurityalliance.org/articles/pqc-is-a-stress-test-for-enterprise-dns)\n\n**Published:** 10/19/2026\n\n###### [The Agent Kill Switch is No Longer Optional](https://cloudsecurityalliance.org/articles/the-agent-kill-switch-is-no-longer-optional)\n\n**Published:** 10/16/2026\n\n###### [AI Agents - You Can’t Govern What You Can’t Discover](https://cloudsecurityalliance.org/articles/ai-agents-you-can-t-govern-what-you-can-t-discover)\n\n**Published:** 10/16/2026\n\n###### [Why You Need a Zero Trust Program Management Office](https://cloudsecurityalliance.org/articles/why-you-need-a-zero-trust-program-management-office)\n\n**Published:** 10/15/2026", "url": "https://wpnews.pro/news/mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-ai", "canonical_source": "https://cloudsecurityalliance.org/articles/mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-agentic-ai", "published_at": "2026-10-15 16:45:41+00:00", "updated_at": "2026-10-20 16:20:25.549234+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-safety", "ai-tools"], "entities": ["Model Context Protocol", "Badal Bhushan", "OWASP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-ai", "markdown": "https://wpnews.pro/news/mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-ai.md", "text": "https://wpnews.pro/news/mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-ai.txt", "jsonld": "https://wpnews.pro/news/mcp-tool-exposure-is-a-privilege-grant-a-two-gate-authorization-model-for-ai.jsonld"}}