AWS Security Blog 把出站控制重新摆到台面上，原因不难理解。很多云上环境把入口管得很紧，WAF、IAM、堡垒机、审计日志都堆上了，出口却默认放行。普通工作负载被打穿后会往外连，Agent 被诱导后也会往外连，差别只在触发路径。
出口默认放行会掩盖事故
AWS 的文章提到一个常见路径，应用被远程执行代码后，攻击者会建立命令通道，再把数据传到外部端点。Agent 场景里，OWASP 把目标劫持和意外代码执行列成风险项。Agent 拿着工具权限、API 密钥和代码解释器时，出口就是它离开边界的路。
这个问题在企业系统里很现实。运维为了不影响业务，常常让 NAT 网关直接出网，域名访问靠应用自己约束。业务上线没出故障，安全账却欠下了。一旦某个任务流被提示词注入带偏，或者某个服务账号权限过宽，日志里只能看到一串正常 HTTPS 请求。
网络层要先有一条主干
AWS 给出的参考做法是 hub and spoke。业务 VPC 通过 Transit Gateway 汇入中心出口，互联网访问经过 Network Firewall，AWS 服务访问尽量走 VPC Endpoint。这样做的好处很土，但管用，出口路径收束后，规则和日志才有统一落点。
对后端团队来说，别急着把所有 Agent 都接进外网。先列出每个 Agent 正常需要访问的域名、协议、端口和调用频率。支付、工单、知识库、代码仓库、邮件系统，每个外部工具都应该有明确允许项。没有业务理由的目的地，默认挡住。
DNS 是容易被忽略的侧门
AWS 特别把 Route 53 Resolver DNS Firewall 单独拎出来。原因很简单，DNS 查询不一定经过你以为的那条出站检查链路。攻击者可以把数据编码进 DNS 查询，Agent 也可能被诱导执行类似脚本。只看 HTTP 代理日志，容易漏掉这一段。
实际落地时，DNS 策略不要只拦恶意域名列表。生产环境里可以做两层，基础层使用托管威胁情报，业务层维护允许域名。Agent 工作负载更适合窄名单。它要访问几个工具，就只给几个工具，别把开发机的便利带到生产运行时。
数据边界要补上第二道锁
网络出口挡住的是路径，数据边界管的是 API 访问范围。AWS 文章里提到 SCP、RCP、VPC Endpoint policy 和 IAM Access Analyzer，这些东西放在一起看，目标是防止工作负载把数据复制到组织外的资源。S3 这类服务尤其要管。
我建议把 Agent 当成一个新的服务身份，而不是一段聪明脚本。它能读哪些桶，能写哪些队列，能不能调用外部模型，能不能把结果发邮件，都要被身份策略约束。提示词里的安全声明不能替代 IAM 条件和资源边界。
优易云的落地建议
可以从一条业务链路做样板。把 Agent、后台服务、任务队列、对象存储、外部 API 全部画出来，然后给每条出站路径标三个字段，用途、允许目的地、日志位置。标不出来的路径先关掉，业务真需要再走变更。
再做一次演练。让测试同事模拟一个被污染的输入，诱导 Agent 访问未登记域名、读取超范围数据、尝试把结果发到外部地址。Network Firewall、DNS Firewall、数据边界和 GuardDuty 至少要有一层能拦住，另一层能报警。跑完这轮，工程团队心里会踏实很多。
