Connecting an AI Agent to an MCP Server ≠ Full Tool Access
A successful MCP connection doesn't mean tools are callable—the Gateway must authenticate and authorize each call.
Using Doordash's practice as a starting point, the article points out that an agent being able to connect to an MCP server does not mean it can call all of its tools; the real security boundary lies in the Gateway's validation of every tool call. The Gateway splits the problem into two layers: Authentication confirms who the caller is (a user, a service, or an agent acting on behalf of a user), and Authorization determines which operations it may perform. Policy decisions combine four layers of context—agent, user, tool, and environment—and distinguish read from write permissions; the caller's identity travels with the request from routing and usage logging to the final action, ensuring traceability. A centralized gateway also brings three benefits: permission changes only need to be made in one place, developers don't need to write security rules into prompts, and tool owners don't have to reimplement authorization logic. The article concludes by recommending that teams audit their agents' current permissions and start with three steps: authenticating down to the person, scoping authorization to individual tools, and propagating identity with requests.
Many teams assume that as long as an AI agent can connect to an MCP server, it can call every tool exposed on it. Doordash's practice gives the opposite answer: the Gateway validates permissions on every single request—being able to enter the server does not mean being able to touch every tool.
The Gateway's Two Core Questions: Authentication and Authorization
According to an analysis by the YouTube channel lalaschool, the Gateway must answer two questions on every tool call.
Authentication answers "who is calling." The caller could be an ordinary user, a backend service, or an agent acting on behalf of a user. Different identities lead to completely different things being allowed.
Authorization answers "what is this caller allowed to do." The same server may host both read-only query tools and highly destructive admin tools—being able to search a repo does not mean being able to drop a database.
Keeping these two questions separate is key. Authentication only confirms identity; authorization defines the boundary. Mixing them together easily leads to the vulnerability of "once connected, everything is allowed."
MCP (Model Context Protocol) is an open protocol proposed by Anthropic that lets AI models or agents connect to external tools and data sources in a standardized way. An MCP server is a service endpoint that exposes tool interfaces according to this protocol; agents initiate connections through an MCP client and invoke specific tools. The protocol itself solves the interoperability problem of "how to discover and call tools," but it does not specify fine-grained access control—establishing a connection only means the communication channel is available. Whether a specific tool can be executed by a given call still needs to be determined by the upper-layer infrastructure. This is exactly the point of the Gateway described in this article: adding authentication and authorization logic on top of the protocol layer.
The Policy Engine Looks at Four Layers of Context
The Gateway's policy decisions don't just look at who the caller is; they combine multiple dimensions: which agent it is, which user it represents, which tool is being called, and what environment the request is in.
Permission granularity also extends down to the read/write distinction. An agent can read issue details on behalf of a user, but admin write operations will be blocked. This distinction keeps agents efficient in read-only scenarios while preventing data damage from a single mistaken call.
Some workflows run under a team identity—such automated processes have stable permission boundaries. A specific individual's action, by contrast, requires that person's explicit authorization. Identity is not a static label; it is context that travels with the request.
A policy engine is the decision-making component in a permission system, responsible for outputting an allow-or-deny verdict for each request based on a set of rules. It is usually separated from the enforcement point: the enforcement point intercepts requests and queries the engine, while the engine only makes judgments and does not directly operate on resources. This separation allows policies to be maintained centrally and to evolve independently of business code. The Gateway's policy engine described here takes context such as agent identity, represented user, target tool, and runtime environment as input, and combines attributes like read/write level to reach a decision—a typical context-aware authorization pattern.
Identity Must Follow the Request All the Way Through
According to lalaschool's breakdown, the caller's identity travels with the request through the entire chain: from routing and forwarding, to usage logging, all the way to the final executed action.
The value of this lies in traceability—after the fact, you can determine who initiated a given action and which agent did it on behalf of which user. For enterprise scenarios that require auditing, this is a prerequisite for any permission system to be viable.
Identity propagation means that the caller's identity information is carried intact across the service call chain, rather than being dropped or replaced with the service's own identity at some hop. Common implementations include attaching user and agent identifiers to request headers or tokens, using delegable short-lived credentials, and recording identity fields in logging and tracing systems. If identity is lost midway, downstream can only see "some service is calling," making it impossible to answer "who initiated this" during an audit and impossible to perform permission re-checks based on the original caller. Therefore, identity propagation is an infrastructural prerequisite for achieving traceability and the principle of least privilege.
Three Practical Benefits of a Centralized Gateway
Converging permission decisions into the Gateway brings three benefits, all mentioned in the video.
Changing or revoking permissions requires modifying only one place. Permission logic scattered everywhere is the hardest to maintain; when personnel or policies change, it's easy to miss a spot.
Dev agents don't need to stuff security rules into prompts. Constraining agent behavior through prompts is both fragile and unverifiable; delegating security to the infrastructure layer is far more reliable.
Tool owners don't need to rewrite authorization logic. Having every tool implement its own permission checks is redundant work and prone to inconsistency; with a unified Gateway, tool owners only need to focus on functionality itself.
Implications for Agent Development
The question posed at the end of the video is worth every agent-building team asking itself: what permissions does your agent currently hold?
You can start with at least three points: authenticate down to the level of a person (or service, or agent); push authorization down to individual tools rather than the whole server; and propagate identity with requests to ensure actions are attributable.
MCP makes tool integration easy, but integration is only the starting point. The real security boundary lies in the Gateway's per-call validation, not in the moment "connection succeeded."
(This article is based on an analysis of content from the YouTube channel lalaschool.)
Related articles
world2vec: Building Mechanistic World Models with Latent Dynamics Learning
world2vec proposes a reward-free method for learning mechanistic world models via latent dynamics, faithfully reproducing systems over long horizons with at least an order of magnitude fewer parameters than DreamerV3, TD-MPC2, and LeWM, and achieving accurate system identification on 71 attractor benchmarks.
A New KL-DRO Paradigm: Adaptive Scenario Generation Around a Learned Density Model
KL-DRO research proposes centering the KL ball on a learned density model instead of the empirical distribution, with adaptive scenario generation guiding sampling toward the worst case. Experiments show lower cost under distribution shift when records are scarce and the model can extrapolate, with comparable in-distribution cost.
ODE Samplers for Discrete Diffusion Models: Exponential Residual Flows Accelerate Generation
Discrete diffusion models lack deterministic ODE sampling? This article introduces Exponential Residual Flows (ERFs), which introduce continuous residual variables per token to construct piecewise ODEs for deterministic sampling and support consistency distillation acceleration. Superior to prior methods on code and text generation tasks.