The MCP Server Trust Boundary: Why Imported Tools Inherit Your Agent's Authority

TL;DR

When your agent connects to an MCP server, that server inherits your agent's authority. The tools it exposes can call back into your agent's context with the agent's credentials, the agent's identity, and the agent's blast radius. One compromised MCP server is one compromised agent. This post lays out the boundary patterns that contain the blast radius: scoped credentials per server, a capability mediation layer, runtime audit, and a Trust Boundary Spec that any team can implement. The framework introduced here is the Authority Inheritance Map: a one-page diagram of which authorities flow from the agent to which connected servers, with explicit chokepoints where the inheritance can be interrupted.

A Story That Should Worry You

We were called in to triage an incident at a company that had recently rolled out a fleet of internal agents to its operations team. The agents handled routine knowledge work: summarizing tickets, drafting status reports, searching across internal documentation. The agents were connected to about twelve different MCP servers, most of them well-known, well-maintained projects from the open ecosystem. The team was conservative about what credentials the agents had, scoping them carefully to read-only access on most systems and to a single specific project on the systems where write access was required. They thought they had done a careful job.

The incident was discovered when the security team noticed a sustained pattern of outbound traffic from one of the agent runtime hosts to an unfamiliar address. The traffic was small, encrypted, and easily missed in normal monitoring, but a routine review caught it. Investigation revealed that one of the twelve MCP servers had been updated three weeks earlier to a version that included a tool the team had not noticed. The tool, when invoked by the agent in the course of its normal work, made an outbound HTTPS call carrying the contents of the agent's recent context, including transcripts of conversations the agent had with operators about internal projects, customer issues, and pending plans.

The team had done everything right at the credential level. The credentials the agent held were narrowly scoped. The agent could not, with its credentials alone, have caused the leak. But the agent's authority was not just its credentials. It was also the contents of its context window: every conversation, every file the agent had read, every system prompt, every secret that had passed through. The MCP server, by virtue of being connected, had access to all of it whenever the agent invoked any of the server's tools. The credential scoping was real. The authority scoping was nonexistent.

This is the failure mode this post addresses. The credentials your agent holds are only one component of the agent's authority. The other components, less visible and rarely scoped, are the agent's context, its identity in downstream systems, its action capability through other tools, and its position in the broader trust graph of your organization. Every MCP server you connect inherits some or all of these authorities by default. The default is wrong. The boundary patterns that fix the default are the subject of this post.

The Authority Inheritance Map

The framework we use to think about this is the Authority Inheritance Map. The map is a diagram, fitting on one page, that shows which authorities flow from the agent to which connected MCP servers, with explicit annotation of the chokepoints where the inheritance can be interrupted. Drawing the map for an existing agent fleet is the most useful single security exercise we know of in this space, because it forces the team to confront how much authority their agents actually delegate, often unintentionally, to third-party servers.

The map has five rows, one for each authority class. Credential Authority is the set of API keys, OAuth tokens, and other credentials the agent holds. Context Authority is the contents of the agent's context window, including conversation history, file contents, and system prompts. Action Authority is the set of state-changing operations the agent can perform through any of its connected tools. Identity Authority is the set of identities the agent can present in downstream systems, where identity confusion attacks become possible. Network Authority is the set of network destinations the agent can reach, including any servers reachable through tunneled connections.

The columns of the map are the connected MCP servers. Each cell records, for that server and that authority class, whether the inheritance is full, partial, mediated, or none. Full inheritance means the server has unrestricted access to the authority. Partial means the server has access to a defined subset, enforced by the agent. Mediated means the server's access is brokered through a layer that makes specific decisions per request. None means the server has no access to that authority class. In current default agent setups, the entire map tends to be Full across all rows and columns, which is an extraordinary delegation of authority and the root cause of the incident described above.

The utility of the map is in the changes it surfaces. When you draw the map and see twelve servers all marked Full across all five rows, the question becomes obvious: do you actually want that, or have you just inherited it? Almost always the answer is the latter. The boundary patterns we will walk through next are the techniques for moving cells from Full toward Partial, Mediated, or None. Each pattern targets specific authority classes for specific server types, and the cumulative effect over the whole map is to bring the agent's actual authority delegation in line with the agent's actual operational needs.

Scoped Credentials Per Server

The first and most fundamental pattern is scoped credentials per server. The principle is that no two MCP servers should ever share a credential, and no credential should be broader than the specific narrow operations that one server needs. This sounds obvious. It is not what most current systems do.

The failure mode in current systems is credential pooling. The agent holds a small number of broad credentials: a cloud provider key, a company-wide OAuth token, a database admin password. When the agent invokes a tool on any connected MCP server, the runtime makes the necessary credentials available to that server. The credentials are not specifically scoped to the server invoking them; they are simply the credentials the agent has, made available to whatever tool needs them. The result is that compromising any single MCP server gives the attacker the full credential set, which is far broader than that single server should ever have needed.

The fix has three components. First, every MCP server should have its own dedicated credential identity in every downstream system the agent integrates with. The cloud provider integration should produce a separate IAM role for each connected MCP server, scoped to exactly the operations that server's tools require. The database integration should produce a separate connection user for each connected server, with row-level permissions matching the server's actual data needs. The OAuth integration should produce a separate refresh token for each server, with the smallest possible scope set. This is more identities to manage, but the management is mostly automatable.

Second, the credentials should be brokered, never shared. The agent runtime should never load the credentials into the MCP server's address space. Instead, when the server needs to make a downstream call, it asks the runtime to make the call on its behalf. The runtime makes the call using the appropriate scoped credential, returns the response to the server, and the server never sees the credential material. This is the same pattern that conventional secrets managers have implemented for a decade for application code; it has not yet propagated into the agent ecosystem, where the default is still that the application owns the credentials directly.

Third, the credentials should be short-lived. Even with scoping and brokering, a credential that lives forever is a credential that becomes valuable to attack. Every credential issued to or used on behalf of an MCP server should have a TTL measured in hours, not days. The runtime renews credentials on demand, the renewal is logged, and any anomaly in the renewal pattern (an MCP server suddenly renewing far more often than usual, for example) becomes a signal in the monitoring system. Short lifetimes also limit the damage from any single key compromise: if you find out about a compromise within the credential's TTL, the credential expires before the attacker can use it widely.

The combined effect of these three components is to convert the credential surface from one large attack surface into many small ones, each of which can only do narrowly bounded harm if compromised. The cost is real but bounded: the identity management overhead, the brokering layer, the renewal infrastructure. The benefit is that the credential authority cell on every server's row in the Authority Inheritance Map moves from Full to Partial or Mediated.

The Capability Mediation Layer

The second pattern is the capability mediation layer. Where scoped credentials limit the credential authority, capability mediation limits the action authority. The layer sits between the agent and its connected MCP servers, intercepts every tool invocation, and applies a policy decision before the invocation is allowed to proceed. The policy can be as simple as an allowlist or as complex as a contextual evaluation involving the agent's recent history, the user's current intent, and the broader operational state of the system.

The key architectural property of the layer is that it is in the runtime, not in the MCP server. An MCP server cannot be trusted to enforce policies on its own behavior; if it could, we would not need the layer. The layer has to be operated by the agent runtime, with policies controlled by the agent's owner, not by anyone who controls the MCP server. This is a structural separation that current MCP implementations mostly do not provide, and adding it is the most important architectural investment in this whole post.

The policies the layer enforces fall into three categories. Static policies are evaluated against the tool invocation alone: tool name, parameter values, target resources. A static policy might say that the file_write tool can only be invoked with paths inside a specific allowlisted directory, or that the http_request tool can only target specific allowlisted hosts. Static policies are easy to implement and easy to reason about, and they catch the largest fraction of obvious misuse.

Contextual policies are evaluated against the broader state at the time of invocation. A contextual policy might say that the email_send tool can only be invoked if the current user's intent, as parsed from the conversation, mentions sending email. Or that the database_write tool can only be invoked if the agent is currently within a specific authorized session. Contextual policies are harder to implement well, because they require a coherent representation of agent state that the policy can query, but they catch a class of misuse that static policies cannot: the malicious tool that is structurally legal but contextually inappropriate.

Rate and budget policies are evaluated against patterns over time. A rate policy might say that the api_call tool cannot be invoked more than ten times per minute. A budget policy might say that the payment tool cannot move more than 100 dollars per day in aggregate. These are the policies that catch the malicious or buggy tool that is doing one thing legally but at unusual frequency or magnitude. They are the last line of defense against misuse that has slipped past the static and contextual checks.

The layer's decisions are logged in a tamper-evident store, with every invocation, every parameter value, every policy decision, and every outcome captured for later audit. The log is the basis of the runtime audit pattern in the next section, and it is also the artifact you reach for when something goes wrong in production. A capability mediation layer without rich logging is a lock without a record of who tried to open it.

Runtime Audit As A First-Class Discipline

The third pattern is runtime audit. Where the capability mediation layer enforces policies in real time, runtime audit reviews the layer's decisions periodically and looks for the patterns that policies cannot catch. Runtime audit is not a substitute for mediation; it is the second line of defense, catching the cases where the policies were wrong, where new misuse patterns emerged that no policy anticipated, and where the slow accumulation of marginal decisions added up to a serious problem.

The practical shape of runtime audit is a continuous review process that consumes the mediation layer's logs and produces signals back into the runtime. The signals can be alerts to operators, automated tightening of policies, immediate suspension of specific tools or servers, or formal incident escalations. The audit can be run by humans on a schedule, by automated systems on every event, or by LLM-based reviewers that can spot patterns too complex for rule-based systems. In our practice, the most effective audit programs combine all three, with each layer covering the cases that the others miss.

The specific patterns that runtime audit looks for fall into three categories. Behavioral drift is the slow change in a server's invocation patterns that suggests the server is being used differently than it was when policies were written. A server that historically invoked five tools per session and now invokes fifty is exhibiting drift, and the drift is worth investigating even if no individual invocation is policy-violating. Anomalous parameter values are the cases where the tool is being invoked legally but with parameters that deviate sharply from historical norms. A file_read tool that has always read files of a few hundred kilobytes and is now reading multi-gigabyte files is anomalous, and worth investigating. Identity confusion attempts are the cases where one server appears to be invoking tools or making decisions on behalf of an identity it does not normally claim. These are the early signals of confused deputy attacks and they are visible only to systems that maintain identity propagation through their logs.

The key operational property of the audit is that its outputs are actionable. An audit that produces a wall of alerts that nobody reads is not useful. An audit that produces, on average, one or two alerts per week that genuinely require human attention is. Tuning the audit to that level of signal-to-noise is the work of the security team, not the platform vendor, and it is real work that takes months to do well. The investment is worth it because the audit is the place where the unknown unknowns get caught, and the unknown unknowns are exactly what attackers count on.

A second-order benefit of runtime audit is that it produces a body of evidence that can be used to refine the static and contextual policies in the mediation layer. The audit catches a pattern of misuse, the pattern is generalized into a policy, the policy joins the mediation layer, and the next instance of that pattern is caught at runtime. The audit and the mediation layer form a feedback loop, with the audit being the slow learning system and the mediation being the fast enforcement system. This loop is the operational engine that makes the trust boundary maintainable over time, as the threat surface and the agent's use cases evolve.

Identity Propagation Across The Boundary

The fourth pattern, often overlooked, is identity propagation. When the agent invokes a tool on an MCP server, what identity does the server see? When the server's tool invokes another tool, what identity does that downstream tool see? The default in most current systems is identity collapse: somewhere along the path, the original caller's identity is lost, and downstream systems see only the identity of the most proximate caller. This collapse is the structural enabler of confused deputy attacks, and addressing it requires deliberate identity propagation through every layer of the call chain.

The pattern is to propagate three identity components through every call. The originator is the human or agent that triggered the original action. The actor is the agent that is currently performing the action. The proximate caller is the immediate caller of the current operation. Each downstream call carries all three, and each downstream system can make policy decisions based on any of the three. The originator gives you accountability: when something goes wrong, you can trace back to the human responsible. The actor gives you capability scoping: the agent's capabilities, not the proximate caller's, govern what is allowed. The proximate caller gives you debugging context: when an error occurs, you know which intermediate component made the call.

Implementing identity propagation requires changes at every layer of the stack. The agent runtime has to attach identity claims to every tool invocation. The MCP server has to receive the claims and pass them through to its downstream calls. The downstream systems have to accept the claims and use them in policy decisions. None of this is technically hard, but it requires consistent discipline across many components, and it has to be enforced in a way that the components cannot bypass. The standard mechanism is signed identity tokens, similar to JWTs, with a short TTL and a public key infrastructure that lets each layer verify the claims it receives without trusting the layer that delivered them.

The specific identity claim format we use includes the originator identity, the actor identity, the proximate caller identity, the call depth, the originating session ID, the originating timestamp, and a chain of signatures showing how the identity was propagated through intermediate layers. Each layer adds its own signature to the chain, so the final downstream system can verify the entire propagation path. This sounds heavy. The marginal cost per call is low; the engineering investment is one-time; the audit value is enormous, because every operation that makes it to a downstream system carries with it a verifiable chain of who initiated it and how it got there.

The payoff for identity propagation is that the confused deputy attacks described in earlier posts become structurally impossible. A malicious server cannot impersonate the agent's identity to a downstream system, because the downstream system requires a signature chain, and the malicious server does not have access to the agent's signing key. The agent's authority cannot be borrowed; it can only be exercised, transparently and under audit. This is the property we want, and it is achievable with current tooling if the team is willing to invest in the foundation.

Network Egress Control

The fifth pattern is network egress control. Most current MCP server implementations run inside the agent runtime with full outbound network access. The server can reach any host on the internet, on any port, through any protocol. This is the primary enabler of data exfiltration attacks, because the server has somewhere to send the data it scrapes.

The fix is per-server egress allowlisting. Every MCP server should have a declared set of network destinations it is allowed to reach, expressed as a list of hostnames and protocols. The runtime enforces the allowlist at a layer that the server cannot bypass: typically a network namespace or a sidecar proxy that intercepts all outbound traffic. Connections to destinations not on the allowlist fail. Successful connections are logged with the destination, the protocol, and the volume of data transferred.

The allowlist is part of the server's manifest, declared at registration and verified against the runtime's policy. Changes to the allowlist require a new manifest version, with all the provenance attestations described in the previous post. This makes egress changes a deliberate, auditable event rather than a silent runtime adjustment. A server that has been running for months with a small allowlist suddenly trying to expand its allowlist is the kind of signal that should produce an immediate operator alert, because legitimate expansions are rare and adversarial expansions are exactly what an attacker would attempt after compromising a server.

The operational reality of network egress control is that it requires up-front work to discover what destinations each server actually needs. The discovery process is not glamorous: deploy the server in a test environment with an open monitor, exercise its tools through realistic workflows, capture the actual destinations used, and codify them into the manifest. The work is one-time per server version and pays dividends every day after, because the egress policy stops being a guess and starts being a verified record of necessary destinations.

The second operational reality is that some servers legitimately need broad network access, particularly servers whose purpose is to interact with arbitrary internet content (web search tools, web scraping tools, link summarizers). For these servers, the allowlist cannot be narrow. The mitigation is to combine egress logging with stronger isolation: run the broad-access servers in their own isolation boundary, with no access to credentials or context that other servers can see, so that even if the broad access is abused, the blast radius is constrained to that one server's narrow data.

The MCP Trust Boundary Spec

The artifact this post promised is an MCP Trust Boundary Spec, the implementable document that turns the patterns above into a checklist any team can adopt. The spec has five sections corresponding to the five patterns, with concrete requirements that can be verified at registration, deployment, and runtime.

The Credential Section requires every MCP server to declare every credential class it needs, with the specific scope it requires within each class. The runtime issues server-specific credentials matching the declared scopes, with TTLs not exceeding 24 hours. Credentials are brokered through the runtime, never loaded into the server's address space. Credential renewals are logged. Manifests that fail to declare credentials at sufficient specificity, or that request scopes broader than the declared use case, are rejected at registration.

The Capability Section requires every MCP server to declare every tool it exposes, with the parameter types, the side effects, and the resources accessed. The runtime evaluates every invocation against static, contextual, and rate policies. Policies are stored separately from server manifests so they can be updated without re-registering the server. All invocations and policy decisions are logged in a tamper-evident store.

The Audit Section requires every MCP server to be subject to continuous review of its invocation logs, with named operators responsible for responding to alerts, and with a defined feedback loop from audit findings back to policy refinements. The audit pipeline is separate from the runtime, with its own signing keys, so that compromising the runtime does not compromise the audit trail.

The Identity Section requires every MCP server to receive and propagate the three-component identity (originator, actor, proximate caller) on every tool invocation and every downstream call. The propagation uses signed tokens with short TTLs. Downstream systems verify the signature chain. Identity collapse, defined as any operation reaching a downstream system without a verifiable identity chain, is treated as a critical incident.

The Network Section requires every MCP server to declare its network egress destinations. The runtime enforces the declarations at the network namespace or sidecar proxy layer. Egress logs include destination, protocol, and data volume. Changes to declared destinations require a new manifest version with full provenance.

The full spec is longer in practice than this summary suggests, with implementation guidance, common pitfalls, and example manifests. The summary gives you the structure. Adopting even a partial version of the spec, applied incrementally over a quarter, produces a meaningful reduction in blast radius for any team that takes it seriously.

Counter-Argument: Doesn't This Defeat The Point Of MCP?

The most serious counter-argument is that all of this scoping and mediation defeats the point of the MCP standard, which was to enable easy, low-friction integration of tools into agents. If every MCP server has to be wrapped in scoped credentials and mediated capabilities and propagated identity and audited egress, then the cost of integration goes up, and the developer experience that made MCP attractive in the first place is lost.

We think this argument is partly right and entirely beside the point. It is right that the work we describe adds friction. It is beside the point because the alternative is exactly the situation we just spent three thousand words describing: every MCP server inheriting full agent authority by default, with no mediation, no audit, and no scoping. That alternative is not sustainable. It will produce incidents that will produce regulations that will produce mandatory frameworks much heavier than anything in this post. The choice is not between this work and no work. It is between this work, done deliberately and in our preferred shape, and a much heavier framework imposed externally after a sufficiently embarrassing incident.

The second observation is that the work we describe is mostly platform work, not server-author work. The credential brokering, the mediation layer, the identity propagation, the egress enforcement: these are runtime capabilities that a platform builds once and that all servers benefit from. The server author still gets the easy integration model that MCP promises. They just write servers that work in the context of a runtime that takes the trust boundary seriously, and the runtime does most of the work of maintaining the boundary. This is the same architectural pattern that has made conventional cloud platforms productive: the platform takes responsibility for the security primitives, the application gets to focus on its business logic.

The third observation is that the friction is unevenly distributed. Servers that need to do things that are obviously high-stakes will need to declare more, get more scrutiny, and accept more constraints. Servers that need to do things that are obviously low-stakes will pass through the system with minimal additional work. This matches the reality of the trust gradient that already exists in any agent fleet. The trust boundary spec just makes the gradient visible and enforceable, where today it is implicit and unenforced.

What Armalo Does

Armalo runs every MCP server registered with the platform behind a capability mediation layer with full identity propagation, scoped credential brokering, and per-server egress control. The behavioral pacts that govern server behavior reference the trust boundary spec directly: a pact violation can be linked to a specific failure of credential scoping, capability mediation, identity propagation, or network egress. The composite score that drives certification tier includes trust boundary compliance as a measured dimension, so a server that ships without proper boundary support cannot earn higher tiers regardless of its functional quality. The Trust Oracle at /api/v1/trust/ exposes the current trust boundary configuration for any registered server, so an agent considering whether to import the server can see the boundary properties before connecting. Where most platforms treat MCP integration as a connectivity problem, we treat it as a trust boundary problem, because the connectivity has been solved and the trust boundary has not.

FAQ

Doesn't every server need full network access in practice? No. Many servers have a small, well-defined set of destinations they need. The discovery work to identify those destinations is real, but the resulting allowlist is usually short. The servers that legitimately need broad network access are a minority and should be handled with stronger isolation rather than broad allowlists across the whole fleet.

How do I implement identity propagation across servers I do not control? You wrap them. The agent runtime maintains the identity tokens; when a server makes a downstream call, the call goes through a runtime-controlled proxy that adds the appropriate identity headers. The server does not have to know about identity propagation; it just makes its normal call, and the runtime handles the propagation transparently. Servers that bypass the runtime proxy are servers you should not be running.

What happens when a credential is compromised despite scoping? The blast radius is limited to whatever that scoped credential could do, which is much smaller than what an unscoped credential could do. The compromise is detected through anomalous renewal patterns or unusual usage logged by the brokering layer. The credential is revoked, audit is performed on its usage during the compromise window, and any downstream effects are unwound. The smaller the scope, the smaller the cleanup.

Is the MCP standard going to add these primitives natively? Some of them, slowly. The community is converging on identity propagation and signed manifests. Capability mediation is largely outside the standard's scope and will probably remain in the runtime layer, where it belongs. Egress control will probably stay platform-specific. The right move is to implement the patterns now in your runtime, rather than wait for a standard that may take years to mature.

Do the patterns work for self-hosted MCP servers I wrote myself? Yes, with the same effort. First-party servers do not get a free pass on the trust boundary, because the trust boundary is about limiting blast radius, not about whether you trust the author. A first-party server with a vulnerability is exactly as dangerous as a third-party server with the same vulnerability, and the boundary is what limits the damage.

Can capability mediation policies be written in natural language? Increasingly, yes. We use a combination of declarative rules for the static cases and LLM-evaluated policies for the contextual cases. The LLM policies are slower and less deterministic, so they are reserved for cases where the contextual judgment is genuinely required. The declarative rules cover the bulk of the load with predictable performance.

What is the highest-leverage single change for a team that has none of this? Per-server scoped credentials. If you can do nothing else, give each connected MCP server its own narrowly scoped credential set, brokered through your runtime, with short TTLs. This single change reduces the credential blast radius from full agent authority to per-server-scoped authority, which is the largest single reduction in attack surface available from any one pattern.

Bottom Line

The MCP server you connect today inherits your agent's authority by default. The default is wrong, and it is the structural cause of an incident class that is going to grow rapidly as the agent ecosystem scales. The trust boundary patterns we walked through (scoped credentials, capability mediation, runtime audit, identity propagation, network egress control) are the techniques that bring the actual authority delegation in line with operational need. The Authority Inheritance Map is the diagnostic tool. The Trust Boundary Spec is the implementation artifact. The work is real and the payoff is the difference between a fleet that contains incidents when they happen and a fleet that becomes a single incident waiting to spread.