AML.T0049Exploit Public-Facing Applicationview on ATLAS ↗Adversary exploits a vulnerability in an internet-facing service to gain initial access. For AI systems this often means the inference API or its surrounding web application.
T43 · Helmwart ID · OWASP MAS Guide source
Network Exposure of MCP Server
A Model Context Protocol (MCP) server is deployed without adequate network controls, so any party who can reach its port can invoke its tools and read its resources.
ExtendsT3: Privilege Compromise · base threat in OWASP v1.1 catalog
Definition
An MCP server is deployed without adequate network security controls (firewalls, access control lists, network segmentation), making it reachable by unauthorised clients or attackers. The MCP server itself may be correctly implemented; the vulnerability is in its deployment: any party that can reach the server’s network port can invoke its tools and access the resources it exposes.
What it looks like in practice
An MCP server providing access to a company’s internal knowledge base is initially deployed on a developer’s local machine for testing. When the developer moves the server to a cloud environment to support remote team members, the deployment script binds the server to all network interfaces and no firewall rule restricts inbound access. The server is effectively public. An attacker scanning for open ports discovers it, connects without authentication (if authentication was not separately configured), and retrieves the full knowledge base content, reproducing the T28 (RAG Data Exfiltration) path via network-level exposure rather than database-level access control failure.
Why it’s dangerous in multi-agent context
MCP servers expose organisational data sources and tool capabilities to AI agents. A server providing access to internal company data, a code repository, or a database represents a significant data access surface. Exposing that surface to an unauthorised network, whether public internet or an insufficiently segmented internal network, means any attacker who can reach the server port can invoke its tools and access its resources, bypassing all agent-layer and application-layer access controls that assume network-level trust. T45 (Insufficient Isolation of MCP Server Permissions) compounds the risk: a network-exposed server running with excessive OS-level permissions grants the attacker not just MCP resource access but broader host access on compromise.
Detection signals
An exposed MCP server is observable from the network layer before any data is exfiltrated. Network scanning, connection logs, and cloud security tooling will surface it if instrumented correctly.
- A cloud security posture management (CSPM) tool or AWS Config rule reporting an inbound rule on the MCP server’s security group that permits traffic from
0.0.0.0/0or::/0on the MCP server’s listening port. Schedule this check to run on every security group change event. - The MCP server’s access log recording a successful TCP connection from an IP address outside the known client IP allowlist. The server should log source IP on every accepted connection, and an alert should fire on any first-seen external address.
- An internet-wide scan tool (e.g., Shodan or Censys) indexing the MCP server’s port and returning the server’s banner or JSON-RPC method list. Subscribe to scan-result notifications for the organisation’s IP ranges.
- A
netstatorss -lntpsnapshot from the server host showing the MCP process bound to0.0.0.0rather than127.0.0.1or a private interface address. Include this check in the deployment pipeline’s pre-promotion audit step. - An authentication failure log entry on the MCP server from an IP with no prior connection history, followed closely by a successful connection from the same IP. This pattern is consistent with a probe-then-connect technique used by attackers testing for open access.
Mitigations
- Bind MCP servers to the minimum required network interfaces (loopback or private network only) and enforce firewall rules that restrict inbound access to known client IP ranges.
- Place MCP servers behind a private network boundary (VPN, private subnet, or service mesh) rather than exposing them directly to public networks.
- Apply network security hardening as a mandatory step in the deployment pipeline before any server is promoted from local to remote; block deployment promotion if the network exposure audit fails.
- Require client authentication even on private networks: network-level access controls are a defence-in-depth layer, not a substitute for application-level authentication.
Relation to base threat (T1–T17)
T43 extends T3 Privilege Compromise. Where T3 addresses overly broad agent roles, T43 addresses the network-level deployment misconfiguration that bypasses all access controls by making the MCP server reachable to unauthorised parties before they even present credentials. T45 (Insufficient Isolation of MCP Server Permissions) is the OS-level analogue: excessive permissions on the server process compound the damage once network-level exposure grants initial access.
OWASP Top 10 for Agentic Applications 2026
The Agentic Top 10 (ASI01 through ASI10) is a separate practitioner-facing publication that maps onto the master Threats & Mitigations threat numbering. T43 is covered by the following Top 10 entries:
ASI03Identity & Privilege Abusecontributing When an agent acts on a user's behalf it inherits that user's credentials and permissions for the duration of the task. Attackers exploit this by manipulating delegation chains, role inheritance, or agent-to-agent trust, turning a narrowly scoped instruction into a credential that can chain every permission the principal holds, concurrently, in a single agent turn.
ASI07Insecure Inter-Agent Communicationcontributing Agents in a multi-agent system pass instructions, results, and context to one another across APIs, message buses, and shared state. Without per-message authentication and integrity controls, a single compromised peripheral agent becomes an injection source for every peer it can reach. One hop becomes n-hop, and the orchestrator is reachable from the outside.
Source: OWASP Top 10 for Agentic Applications 2026 (Dec 2025) · the Top 10 is a compass into the master Threats & Mitigations taxonomy, not a replacement for it.
Design principles at stake
When T43 is present, these security design principles are the ones being violated or tested. Each links to the full principle; the mitigations below are how you restore them.
- Defence-in-DepthNetwork-level exposure strips away all application-layer and agent-layer access controls before an attacker has even presented credentials: any party that can reach the port can invoke the server's tools. Depth here means the network boundary is a distinct layer that must hold independently of authentication: firewall rules restricting inbound access to known client IP ranges, and placement behind a private subnet or VPN, mean an attacker who defeats application-layer authentication still cannot reach the port. Requiring client authentication even on private networks adds a third layer so that network-level access alone is never sufficient to invoke a tool.
Recommended mitigations
Auto-generated from the mitigation catalog: every mitigation whose coverage map includes T43, sorted by maturity tier (Tier 1 production-canonical first, then Tier 2, then Tier 3 research-stage).
- Tier 1SPIFFE(SPIFFE / SPIRE workload identity — cryptographic identities for every agent and service)
In most deployments, agents authenticate to one another with long-lived bearer tokens or shared secrets. If any one of those credentials is stolen, the attacker has persistent, platform-wide access until someone manually rotates it. SPIFFE replaces that model: each workload is issued a short-lived, cryptographically verifiable identity document, and every connection requires both sides to present one. No long-lived secrets traverse the network, and a compromised credential is worthless within its TTL.
why it helps Network-exposed MCP servers are reachable by any caller that can route to the endpoint unless the connection requires mutual authentication. SPIFFE mTLS at the MCP server transport layer forces every client to present a valid SVID before the connection is accepted, closing the unauthenticated network-access path that T43 depends on.
- Tier 2Cross-client isolation(Cross-client isolation — request-scope tenant boundaries in shared MCP server deployments)
A shared MCP server that accepts connections from multiple clients is a concentration point where one client's session state, credentials, and resource budget are physically co-located with every other client's. Without enforced isolation, a malicious or compromised client can read another session's cached credentials, consume shared resources to the point of denying service to other clients, or exploit aggregate server permissions that exceed its own declared scope. Cross-client isolation is the set of structural controls that close those paths: per-session state scoping, per-client permission evaluation, and per-client resource quotas enforced at the server layer.
why it helps Network exposure of the MCP server is a precondition for T43; network exposure combined with insufficient isolation is what makes it exploitable. Per-client network policy, implemented as mutual TLS with per-client certificates and per-client egress rules, limits the network-level blast radius of any single client's access being abused by another.
Role-Based Access Control (RBAC) assigns every agent identity a named role that sets the outer limit on what it can reach. Attribute-Based Access Control (ABAC) narrows individual decisions inside that role by evaluating contextual attributes at request time. Used together, they enforce least privilege for non-human identities: the agent can only do what its role permits, and only when the request attributes satisfy the policy.
why it helps A network-exposed MCP server without per-client authorisation grants any reachable caller access to every tool it exposes. RBAC at the MCP server entry point ties every tool invocation to the caller's role, so network reachability alone does not confer access: a caller must also present a valid, authorised role.
Red-team pivot: MITRE ATLAS techniques
MITRE ATLAS catalogues adversary techniques against AI systems. Where this OWASP threat has an attacker-perspective counterpart, the ATLAS technique is shown below. That is what a red team would actually be doing on the wire. Use this for detection-signal anchoring, threat-hunting hypotheses, and IR runbooks. Source: mitre-atlas/atlas-data v5.6.0.
© 2026 The MITRE Corporation. ATLAS content is reproduced and distributed with the permission of The MITRE Corporation.
AML.T0012Valid Accountsview on ATLAS ↗Adversary obtains and abuses legitimate user or service credentials for initial access, persistence, privilege escalation, or defence evasion.
Agentic angle: Agents often run under long-lived service accounts whose blast radius exceeds the original task scope.
References
- OWASP MAS Threat Modelling Guide v1.0 (April 2025) §5 Anthropic MCP — Layer 4 Deployment Infrastructure.
Sources
- OWASP-MAS-Guide ↗ · 1.0 (Apr 2025) · §5 Anthropic MCP — Layer 4 Deployment Infrastructure
Adapted by Helmwart from the OWASP source(s) above underCC BY-SA 4.0(changes: normalized IDs, added MAESTRO-layer, agentic-factor, and mitigation mappings). This entry is licensed CC BY-SA 4.0.