Prerequisites
- Aviatrix Controller 8.1 or later (for subnet-type SmartGroups and FQDN SmartGroups)
- Controller 9.0 or later required if you enable selective TLS decryption for URL-path enforcement
- CoPilot 4.31 or later
- DCF for Spoke Gateways enabled with Log Enrichment turned on
- A cloud account onboarded in CoPilot for the AWS account hosting the AgentCore workload
- AgentCore configured in VPC mode (PUBLIC mode has no enforcement point and must not be used in production)
How it works
AgentCore VPC mode drops Elastic Network Interfaces (ENIs) into your designated agent subnet. All outbound traffic (tool calls, model provider requests, MCP server connections, code interpreter egress) leaves the VPC through that subnet’s route table. Pointing the route table’s default route at the Aviatrix spoke gateway puts all agent egress in-path for DCF enforcement before it reaches the internet gateway. An Aviatrix spoke gateway attached to your enterprise Transit provides both the enforcement point and the East-West containment boundary. DCF evaluates every egress connection against declared policy: AWS service endpoints are permitted without decryption, sanctioned tool destinations are permitted with selective TLS decryption scoped only to the hosts where URL-path inspection is needed, and everything else is denied and logged. Supply-chain enforcement uses a two-rule pattern. A DENY rule at priority 29 decrypts traffic to GitHub hosts and blocks connections whose URL paths match known indicators of compromise. A PERMIT rule at priority 31 then allows legitimate traffic to those same hosts to proceed. Decryption is scoped to a GitHub-specific FQDN SmartGroup so AWS service traffic (ECR, Bedrock, STS) is never decrypted, preserving certificate-chain behavior for those endpoints. The IAM guardrail uses three separate policy statements because the IAM condition operator behaves differently depending on whether the subnets key is present in the request. ANull condition catches PUBLIC-mode creates, where no
subnet key is sent at all. Two ForAnyValue:StringNotEquals conditions then
catch VPC-mode creates with foreign subnets or security groups.
Procedure
- CoPilot UI
- Terraform
1
Deploy an Aviatrix spoke gateway in the cluster VPC
An Aviatrix spoke gateway in the same VPC as your Kubernetes cluster is the
enforcement point where the Aviatrix controller applies containment policy to
MCP server egress traffic.
- In CoPilot, navigate to Cloud Fabric > Gateways > Spoke Gateways and click + Spoke Gateway.
-
Provide the following details:
- In the Instances section, select a subnet in the cluster VPC for the gateway instance.
- Click Save.
2
Configure the agent subnet route table
In the AWS Console, locate the route table associated with the AgentCore agent
subnet and add a default route pointing to the Aviatrix spoke gateway.
- In the AWS Console, navigate to VPC > Route Tables and select the route table associated with the AgentCore agent subnet.
-
Select Edit routes and add the following entry:
- Click Save changes.
Do not apply this route to subnets hosting interface VPC endpoints for Bedrock
AgentCore data plane and control plane. Those subnets route directly to their
endpoints and must not traverse the spoke gateway.
3
Deploy the IAM guardrail
The IAM guardrail requires three separate Deny statements because IAM condition
operators behave differently when a request key is absent versus present. A
single Replace
ForAllValues statement cannot catch PUBLIC-mode creates, because
ForAllValues on a missing key evaluates to false.In the AWS Console, create a managed policy with the following document and
attach it to all IAM principals that can create AgentCore resources:<approved-subnet-id> and <approved-security-group-id> with the
subnet and security group from your AgentCore landing zone.4
Create SmartGroups
SmartGroups identify the agent workload as a policy source and scope TLS
decryption to specific destination hosts.
- Navigate to Security > Distributed Cloud Firewall > Groups and select the SmartGroups tab.
-
Create the following SmartGroups:
agentcore-runtime-subnet: the agent workload source- Match type: Subnet
- Select the AgentCore runtime subnet from your VPC
github-hosts: destination scope for selective TLS decryption- Match type: FQDN
- Add three entries:
api.github.com,raw.githubusercontent.com,github.com - This scopes decryption to only these hosts so AWS service traffic (ECR, Bedrock, STS) is never decrypted
any: catch-all destination for deny rules- Match type: CIDR
- CIDR:
0.0.0.0/0
adjacent-spokes: other workload VPCs in the transit fabric (for East-West containment)- Match type: CIDR
- Add a CIDR entry for each adjacent spoke VPC CIDR that the agent must not reach
5
Create WebGroups
WebGroups define the FQDN allow-lists for permitted egress destinations and the
URL-path deny patterns for supply-chain enforcement.
- Navigate to Security > Distributed Cloud Firewall > Groups and select the WebGroups tab.
-
Create the following WebGroups:
allowed-models: sanctioned model provider endpoints- Filter type: SNI Filter
bedrock-runtime.*.amazonaws.combedrock.*.amazonaws.com- Add FQDNs for any additional model providers your governance policy approves
aws-control-domains: AWS service control-plane endpoints required by the AgentCore runtime- Filter type: SNI Filter
sts.*.amazonaws.comlogs.*.amazonaws.commonitoring.*.amazonaws.comxray.*.amazonaws.comsecretsmanager.*.amazonaws.com*.ecr.*.amazonaws.comapi.ecr.*.amazonaws.com
allowed-tools: sanctioned tool-call destinations- Filter type: SNI Filter
- Add the FQDN of each external API or tool endpoint the agent is permitted to reach
- Include GitHub hosts here if your agent uses GitHub as a tool source; rule 29 will still block known-bad paths before rule 31 permits legitimate traffic
allowed-mcp-servers: sanctioned remote MCP server endpoints- Filter type: SNI Filter
- Add the FQDN of each approved remote MCP server
supply-chain-ioc-github: URL-path deny patterns for known indicators of compromise- Filter type: URL Filter
api.github.com/repos/*/*shai-hulud*raw.githubusercontent.com/*/*shai-hulud*github.com/shai-hulud*- Append additional IoC path patterns from threat intelligence feeds as they are identified
The
supply-chain-ioc-github WebGroup uses URL Filter entries, not SNI Filter
entries. URL filters match the full request path after decryption and require
a DCF policy with DECRYPT_ALLOWED to function. SNI filters match only the
TLS server name at handshake time and do not require decryption.6
Create DCF policies
DCF policies are evaluated top-down; the first matching rule applies. The
supply-chain enforcement pattern uses two rules: a DENY at priority 29 blocks
known-bad URL paths on GitHub hosts, and a PERMIT at priority 31 allows
legitimate GitHub traffic after decryption. Both rules decrypt only flows
destined for the
github-hosts SmartGroup so AWS service traffic is unaffected.Navigate to Security > Distributed Cloud Firewall > Policy and create the
following rules in priority order:For rule 50, set the protocol to UDP and port 53. The agent’s legitimate
DNS to the VPC resolver (
169.254.169.253) is intra-VPC and does not traverse
the spoke gateway, so this rule does not block normal SDK operation.Rules 29 and 31 both target the
github-hosts SmartGroup as the destination.
This is intentional: decryption is scoped to that SmartGroup so only
GitHub-bound flows are inspected. Rule 29 fires first and denies connections
whose URL paths match the IoC patterns. Rule 31 then permits legitimate GitHub
traffic that did not match any IoC pattern.7
Verify containment
- In CoPilot, navigate to Security > Distributed Cloud Firewall > Policy and confirm all rules are present and active.
-
Invoke an AgentCore Runtime session and confirm it completes successfully.
The model provider endpoints and declared tool destinations should appear as
PERMIT events in CoPilot FlowIQ filtered by source SmartGroup
agentcore-runtime-subnet. -
To verify egress blocking, attempt a connection from an agent to a
destination not in any WebGroup and confirm it is denied. The denied attempt
appears in CoPilot per-connection logs with the rule name
default-deny. -
To verify DNS exfiltration blocking, attempt an external DNS query over
UDP/53 and confirm it is denied by rule
deny-dns-exfil. -
To verify the IAM guardrail, attempt to create an AgentCore Runtime without
subnet parameters (PUBLIC mode) and confirm the AWS API returns an explicit
deny on the
DenyPublicModeCreatestatement. -
To verify East-West blocking, attempt a connection from the agent subnet to
an adjacent spoke VPC CIDR and confirm it is denied by rule
deny-east-west.