VPC-Native Agent Frameworks That Never Route Execution Traffic Outside Your Network

Sensitive agent workloads need private execution paths beyond a runtime with “VPC” in its settings. VPC-native architecture is the baseline for keeping invocations, tool calls, and service requests off the public internet. It is hard to know which paths a configuration protects, which are still public, and where identity controls must take over.

Why AI agent execution traffic is now a primary attack surface

A 2026 scan of publicly reachable MCP infrastructure found that roughly 40% of exposed services had no authentication at all, leaving agent tools open to access. Those tools connect agents to downstream resources, so leaving them exposed puts more than the endpoint itself at risk. For teams handling sensitive data, public reachability and optional authentication are not a defensible starting point.

The threats include interception of agent-to-gateway traffic, unauthorized tool access, token leakage, privilege escalation, and lateral movement from a compromised agent. Private networking addresses the routes through which some of those attacks can happen. It does not replace access control. Begin the architecture with the data plane, where execution traffic flows, rather than the control plane used to create and configure the system.

What "VPC-native" actually means for agent traffic, and what it does not cover

VPC-native execution means the significant runtime flows stay on private network paths. That includes inbound invocations, outbound tool calls, and calls to AWS services. A VPC setting alone does not deliver that. Each flow needs a private route, and the routes differ depending on the caller and destination.

Amazon Bedrock AgentCore Runtime uses Elastic Network Interfaces, or ENIs, to give the runtime a presence inside a VPC. In VPC mode, it places those interfaces in the specified subnets, assigns private IP addresses from the VPC’s CIDR range, and attaches the chosen security groups. These network interfaces give the runtime the network identity of a workload in that VPC.

The flow distinctions are concrete. Agent-to-AgentCore Gateway traffic is public by default but can use a VPC interface endpoint, while Gateway-to-Lambda traffic already stays on the AWS backbone. Control-plane traffic is the exception that cannot be configured away. Interface endpoint support covers data-plane endpoints only, so creating gateways, managing tools, and configuring security still use the standard public endpoint at bedrock-agentcore-control.<region>.amazonaws.com. A private data plane is therefore not a completely air-gapped service.

The four network connectivity patterns, from public default to full isolation

AWS defines four networking patterns for AgentCore Runtime, each with a different boundary. Pattern 1 is the public default, configured with networkMode=PUBLIC. Inbound invocations and outbound AWS service calls traverse the public internet, with OAuth JWT or IAM SigV4 providing authentication. This pattern fits development and non-sensitive workloads.

Pattern 2 uses ENIs to add VPC connectivity so the agent can reach private resources such as RDS databases and on-premises systems. The inbound endpoint still remains publicly reachable. For most production teams moving off a public-only deployment, this is a good place to start because it protects backend resources without the need for full isolation right away. External inference calls, such as calls to OpenAI, still need a NAT Gateway in a public subnet. VPC endpoints for Parameter Store, Secrets Manager, and AgentCore services let those AWS API calls avoid the NAT path.

Pattern 3 closes the public inbound route. A resource-based policy blocks inbound access from the public internet, while callers inside the VPC invoke the agent through an AWS PrivateLink interface endpoint. VPC connectivity remains available for outbound calls. This fits workloads that require private invocation but still need outbound internet access for an external inference API.

Pattern 4 removes the internet route altogether. Inbound calls use PrivateLink, private resource access uses ENIs, and AWS service calls use VPC endpoints. The required endpoints include ECR’s Docker and API endpoints, an S3 gateway endpoint, and CloudWatch Logs. Every additional AWS API call needs a corresponding endpoint or it fails. This is the pattern for highly sensitive workloads, including protected health information and regulated financial data, when the workload’s requirements rule out any internet route.

How VPC Lattice private egress closes the outbound tool-call gap

Private invocation leaves a second question unanswered. How does the gateway reach the tools? A private agent that calls a publicly exposed MCP server still relies on a backend that is exposed. The MCP authentication gap makes this especially important because public endpoints are part of the ecosystem’s default posture.

AgentCore Gateway supports private egress through Amazon VPC Lattice to MCP servers, internal APIs, and other resources inside a VPC. Those backends do not need public endpoints. The agent authenticates to Gateway through an interface endpoint, and Gateway manages OAuth authorization before translating MCP requests into API calls or Lambda invocations. Gateway also injects credentials for each tool call, keeping tool tokens outside the agent.

Some target paths are private without additional configuration. Gateway calls to Lambda and AgentCore Runtime already travel on the AWS backbone. VPC Lattice addresses the private outbound path to other VPC-hosted tools, changing the architecture rather than merely tightening a public endpoint’s settings. Gateway auditing makes tool invocations traceable, while optional VPC Flow Logs capture IP-level traffic without requiring agents to hold log credentials.

A reference architecture that keeps the entire backend off the internet

AWS’s reference architecture shows how these paths fit together in Example Corp’s contract-review agent. A partner uploads an agreement, and the agent checks it against internal standard operating procedures. Findings stream back while the review is still running. That streaming lets the reviewer start reading before the whole result is ready, and the product needs a private backend because it handles sensitive commercial terms.

CloudFront is the only internet-facing component in this design. The browser opens a secure WebSocket connection to CloudFront, which terminates the connection at the nearest edge location. A VPC origin then forwards traffic to an internal load balancer with no internet-routable address. The load balancer routes to a thin proxy running on ECS Fargate in private subnets. The proxy invokes AgentCore Runtime through a PrivateLink interface endpoint for the data plane.

The runtime uses VPC egress mode with AWS-managed network interfaces in the same private subnets. Bedrock inference and OpenSearch Serverless retrieval use VPC endpoints, as does Amazon Cognito login. Document uploads use an S3 gateway endpoint. There are no NAT gateways or internet routes from those subnets. The user-facing connection reaches the edge, but the backend does not become publicly addressable.

A public load balancer restricted to CloudFront IP ranges would leave a different exposure. Its public address could still be scanned and targeted directly, even if most connections were refused, and the allowlist would need maintenance as AWS expands its network. A VPC origin removes that addressable surface. AWS made WebSocket support for VPC origins and the next generation of OpenSearch Serverless available in May 2026, enabling the streaming and retrieval pieces used here.

What compliance actually requires from your network architecture, and what it does not

For regulated workloads, the network must follow the rules for handling the data, even when other endpoints would be easier to use. Where those requirements demand private routing or prohibit internet egress, the matching architecture is a precondition for deployment. It is not an optional hardening phase. Private network boundaries help meet obligations under frameworks such as GDPR, but a VPC label alone does not establish compliance.

Private routing keeps execution traffic off the public internet, and service endpoints remove NAT gateway exposure from AWS API calls. VPC Flow Logs provide IP-level records, while Gateway auditing records tool activity. Runtime session isolation keeps users from sharing execution state. These controls meet different requirements, so one cannot do the job of another.

Identity and policy complete the network boundary. The platform needs company-linked identity, CloudTrail invocation records, mediated tool access, and credentials that stay off disk inside an LLM-controlled environment. A managed runtime does not settle all of that. The public control-plane endpoint is still part of the design even when execution is fully private, so the compliance assessment must cover it instead of assuming that managed hosting removes every public surface.

Identity and credential handling inside the private perimeter

A coding agent that shares the developer’s shell can reach ~/.aws/credentials, ~/.ssh/id_ed25519, .env files, and private registry tokens in ~/.npmrc. Moving the agent to a managed runtime with an IAM execution role removes that laptop credential surface, but the new environment still needs deliberate permission boundaries.

AgentCore Identity’s OAuth On-Behalf-Of token exchange lets the agent act with the triggering user’s identity and permissions. That limits the reach of a compromised session. The runtime’s IAM execution role separately controls which AWS APIs the agent can call. Token leakage and privilege escalation need these identity controls because private routes alone do not prevent either.

The logistics-agent reference separates secrets from ordinary configuration. Database credentials and the OpenAI key live in AWS Secrets Manager, while endpoints, database names, and secret ARNs live in AWS SSM Parameter Store. The agent reads them at runtime through VPC endpoints. The credential fetch itself therefore stays private. This pattern avoids baking secrets into environment variables or a container image, though it differs from keeping tool tokens outside the agent entirely.

Gateway provides that stronger separation for tool credentials. It holds the real tokens for services such as GitHub, Jira, Slack, and internal tools, then injects them for individual calls. The agent never holds those tokens directly.

Multi-cloud agent deployments and where the private perimeter becomes a gap

A private deployment in one cloud does not create a private path into another. Each cloud has its own networking and identity boundaries. AgentCore offers OAuth or OpenID Connect inbound authentication and IAM SigV4 as parallel options, with OIDC independent of IAM. Microsoft Foundry Agent Service uses Entra Agent ID and offers bring-your-own VNet networking with no public egress. Google service accounts have another identity model that must work with the others.

These models do not compose into one shared perimeter. An AWS-hosted agent that needs a GCP resource or an Azure service does not get a native private path between those environments just because each side supports private networking. OIDC federation does not provide that missing route. Cross-cloud access still needs its own networking and governance work because the agent runtime does not provide it.

One container image passes through shared build and evaluation gates, then a deploy job fans out across a cloud matrix. Each leg uses its own OIDC login without long-lived keys. A failed evaluation gate blocks deployment to all three clouds, but that common gate does not join their private networks or unify their permissions.

What small engineering teams can realistically configure without a dedicated platform team

AWS presents the four patterns through CLI commands, making the progression incremental. Teams that start with Pattern 2 must move to stricter patterns when the workload requires them. A regulated workload that prohibits internet routes cannot stop there simply because the intermediate step is easier.

The managed runtime handles session isolation, authentication, scaling, lifecycle management, and ENI creation and placement after the initial VPC configuration. The team still owns the consequential choices. Those include the network pattern, the list of services needed before full isolation, least-privilege execution roles, and whether the public control-plane exception fits the threat model.

A platform-as-a-service layer can also handle cluster management, VPC wiring, and compliance automation inside a team’s own AWS, GCP, or Azure account. For a two- or three-person team, the realistic goal is to use managed mechanisms for the routine work while keeping the execution paths and permissions explicit. “Never outside the network” must describe the actual routes.