NanoClaw Cloud：如何让 AI Agent 在企业环境安全运行？

你想在公司里用 Claude Code 吗？

如果是个人项目：太简单了，直接开用。

如果是企业环境：问题马上来了。

Q1：多个团队用同一个 Claude Code，数据会不会混乱？
Q2：Agent 执行代码，会不会看到其他团队的 API Key？
Q3：一个恶意 prompt，能不能让 AI 跨越租户边界？
Q4：怎样才能审计 Agent 执行了什么操作？

这些都不是小问题。

AWS 官方的答案叫：NanoClaw Cloud。

🎯 问题的本质

Claude Code 天然是个人工具。

要把它变成企业级服务，需要解决三个核心问题：

数据隔离 — 多租户环境下，数据不能混乱
凭证安全 — Agent 看不到 API Key（即使被 prompt 注入）
可审计性 — 每个 Agent 操作都能追踪

大多数产品只解决了问题 1。

NanoClaw Cloud 把三个问题都解决了。最硬核的是六层安全纵深架构。

🔒 六层安全纵深架构

这是整个方案的核心创新。让我逐层解释。

第 1 层：用户认证（JWT + Cognito）

用户登录 → Cognito User Pool
        → 签发 JWT
        → API 调用强制验证 JWT
        → 拒绝非认证请求

这是基础，每个系统都有。

但 NanoClaw 的巧妙之处在于，这只是第一层。

第 2 层：资源隔离（查询层强制条件）

User A 查询 Bot 列表：
SELECT * FROM bots WHERE user_id = 'user-a'

User B 查询 Bot 列表：
SELECT * FROM bots WHERE user_id = 'user-b'

系统设计保证：即使 User A 知道 User B 的 Bot ID，
查询时也会被 user_id 条件过滤掉。

效果：用户只能看到自己的资源。

但如果 Agent 代码有 bug 呢？

第 3 层：ABAC 数据隔离（IAM 级别）

这是 NanoClaw 的第一个重大创新。

正常的做法：

Agent Role:
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bot-data/*"
}

问题：任何 Agent 都能访问所有 Bot 的 s3://bot-data/*

NanoClaw 的做法：

Agent 基础 Role（没有 S3 权限！）：
{
  "Effect": "Allow",
  "Action": ["bedrock:InvokeModel", "sts:AssumeRole"],
  "Resource": "*"
}

运行时动态 AssumeRole，通过 STS Session Tags 限制：
AssumeRole(
  RoleArn = "arn:aws:iam::ACCOUNT:role/Agent-Scoped-Role",
  SessionTags = [
    { Key: "BotId", Value: "bot-12345" },
    { Key: "TenantId", Value: "customer-a" }
  ]
)

Scoped Role 的 S3 Policy：
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bot-data/${aws:SessionTag/TenantId}/*"
}

结果：Agent 只能访问 s3://bot-data/customer-a/
即使代码有 bug，IAM 也会返回 403

这意味着什么？

即使 Agent 被 prompt 注入或代码有漏洞，也物理上无法跨越租户边界。IAM 会强制拒绝。

第 3 层已经很强了。但还没完。

第 4 层：Credential Proxy（核心创新 🎯）

这是整个方案最硬核的部分。

问题的症结：

Agent 需要调用 Anthropic API
所以要有 ANTHROPIC_API_KEY

但 Agent 是不可信的（可能被注入）
所以不能直接给明文 Key

大多数产品的做法：

把 Key 存在环境变量里，希望用户"不要看"
或者存在 Secrets Manager 里，Agent 通过 SDK 获取

但都躲不过一个问题：
Agent 进程最终有了明文 Key

NanoClaw 的做法（Credential Proxy）：

1. Agent 环境变量：
   ANTHROPIC_API_KEY=proxy-managed
   （这是假值）

2. Agent 代码：
   client = Anthropic()
   response = client.messages.create(...)

3. 在 Agent 容器里跑一个本地代理：
   127.0.0.1:8888

4. Agent SDK 自动 hook：
   当发送 HTTP 请求到 api.anthropic.com 时
   实际流量经过 127.0.0.1:8888

5. 代理注入真实 Key：
   GET https://api.anthropic.com/v1/messages
   ↓ (代理拦截)
   GET https://api.anthropic.com/v1/messages
   Authorization: Bearer $REAL_KEY
   ↓ (代理发送)

6. 回应返回给 Agent

结果：Agent 进程永远看不到真实 Key
即使被 prompt 注入也没用

这有多厉害？

攻击者尝试：print(os.environ['ANTHROPIC_API_KEY'])
获得：proxy-managed

攻击者尝试：读取进程内存找 Key
找到：都是代理相关的代码，真实 Key 在代理进程内存里

攻击者尝试：绕过代理
行不通：所有 HTTP 流量都被 hook 了

攻击者尝试：直接访问 127.0.0.1:8888
被拒绝：代理只响应来自 localhost 的请求，
        且请求必须来自 authorized 的 Agent 进程

支持多家厂商：

✅ Anthropic API Key（Claude）
✅ OpenAI API Key（GPT-4）
✅ GitHub Token（GitHub API）
✅ Jira Token（Jira API）
✅ Google AI Key（Gemini）
✅ Stripe Key（支付）
✅ 用户自定义（SQL 连接字符串等）

都走这个 Credential Proxy 机制
所有 API Key 都"对 Agent 不可见"

第 4 层是企业级应用的分水岭。

第 5 层：执行隔离（微虚拟机隔离）

每一个 Agent Session 都运行在独立的微虚拟机里：
┌─────────────────────────────┐
│ microVM 1（Session 1）        │
│ ├── /etc/claude-code/...    │
│ ├── /home/node/.claude/...  │
│ └── /workspace/...          │ ← 完全独立的文件系统
└─────────────────────────────┘

┌─────────────────────────────┐
│ microVM 2（Session 2）        │
│ ├── /etc/claude-code/...    │
│ ├── /home/node/.claude/...  │
│ └── /workspace/...          │ ← 另一个完全独立的文件系统
└─────────────────────────────┘

即使 microVM 1 的 Agent 有漏洞，也访问不了 microVM 2 的文件

隔离维度：

进程隔离：每个 Session 独立进程
内存隔离：独立内存空间
文件系统隔离：独立根文件系统
网络隔离：受限的网络访问
时间隔离：空闲 15 分钟自动销毁

这个隔离有多强？

即使一个 Session 的代码被完全攻破，攻击者也只能在这个微虚拟机内活动，无法影响其他 Session 或宿主机。

第 6 层：Webhook 安全（防伪造 + 限流）

外部消息进来（Telegram/Discord/Slack/飞书）：

1. 签名验证
   消息头包含 X-Signature-256
   系统验证签名 = HMAC-SHA256(secret, payload)
   拒绝签名不匹配的请求

2. WAF 规则
   ✅ 允许来自特定 IP 的 Webhook
   ❌ 拒绝 SQL 注入 payload
   ❌ 拒绝大型 payload（防 DoS）
   ❌ 限流

3. 限流
   Per-user: 1000 请求/分钟
   Per-bot: 100 请求/分钟
   防止被滥用成 DDoS 工具

📊 六层安全的防御矩阵

攻击向量	第 1 层	第 2 层	第 3 层	第 4 层	第 5 层	第 6 层
未认证用户	❌ 拦截	-	-	-	-	-
跨租户数据访问	✅	❌ 拦截	❌ 拦截	-	-	-
Agent 越权	✅	✅	❌ 拦截	-	-	-
API Key 泄露	✅	✅	✅	❌ 防护	-	-
进程逃逸	✅	✅	✅	✅	❌ 拦截	-
伪造 Webhook	✅	✅	✅	✅	✅	❌ 拦截

这就是"六层安全纵深"。

每一层都在独立防护，任何单一层被突破也无关紧要。

🏗️ 从单用户到多租户：架构演进

要理解 NanoClaw Cloud 为什么这样设计，需要看它从哪里来。

NanoClaw（原始版本）

单个用户本地运行：
├── Web Console（React）- 本地 localhost:3000
├── Control Plane（Fastify） - 本地 localhost:3001
├── Agent Runtime（Docker） - 本地容器
└── SQLite 数据库 - 本地 /data/nanoclaw.db

设计目标：个人开发工具
安全需求：None（信任本地环境）
多租户：没有

NanoClaw Cloud（企业版）

云端部署，多租户：
┌─────────────────────────────────┐
│ 互联网 - Telegram/Discord/Slack │
└────────────┬────────────────────┘
             │
        ALB（ELB）
             │
    ┌────────┴────────┐
    ▼                 ▼
ECS Fargate 1   ECS Fargate 2   ← Control Plane（可扩展）
    │                 │
    └────────┬────────┘
             │
        SQS FIFO           ← 消息队列
             │
    ┌────────┴────────┐
    ▼                 ▼
microVM 1      microVM 2         ← Agent 执行（按需创建）
    │              │
    └────┬─────────┘
         │
    ┌────┴─────┬──────────┐
    ▼          ▼          ▼
DynamoDB      S3      Secrets Manager ← 数据层

IAM ABAC（所有访问都受 IAM 限制）

架构的演进逻辑：

Control Plane 常驻不销毁 — 因为需要 WebSocket（Discord/飞书 Gateway）和缓存
Agent 按需创建 — 用完立即销毁，节省成本
SQS FIFO — 保证消息顺序（同一个 Bot 的消息不能乱序）
DynamoDB 替代 SQLite — 全托管、可扩展、支持 ABAC
Secrets Manager 替代文件 — 加密存储，Credential Proxy 可审计访问

🌍 全球 vs 中国：两种部署模式

这是 NanoClaw Cloud 很实际的地方。

全球区部署（AWS 官方推荐）

Cognito（认证）→ AgentCore microVM（Agent）→ Bedrock Claude（推理）

特点：官方全家桶，最简单
缺点：中国大陆无法使用（跨境问题）

中国区部署（完整替代方案）

自建 OIDC 服务（认证）→ ECS Fargate（Agent）→ Anthropic API 直连（推理）

说明：
- Cognito → 自建 OIDC 服务
  用 RS256 JWT，DynamoDB 存储用户
  完全兼容认证流程

- AgentCore microVM → ECS Fargate
  一个 Session 一个 Fargate Task
  通过 Warm Pool 缓解冷启动
  通过 ABAC 隔离数据

- Bedrock → Anthropic API 直连
  用户 BYOK（自带 API Key）
  通过 Credential Proxy 保护

结果：中国用户获得完整功能，不是阉割版

这有多重要？

市面上很多云产品对中国区是"阉割"的——功能不完整、性能差、支持差。NanoClaw Cloud 完全相反：中国区是原汁原味的完整产品。

💡 为什么这个架构对企业很重要？

1. 审计追踪（Compliance）

每个 Agent 操作都被记录：
- 谁执行的（User ID）
- 执行了什么（Operation）
- 何时执行的（Timestamp）
- 结果是什么（Output）
- 是否有权限（IAM decision）

需要检查？完整的审计日志在 CloudWatch
需要合规验证？一条 SQL 查询搞定

这对金融、医疗、政府行业很关键。因为监管要求审计。

2. 成本控制

按使用量计费：
- Control Plane：ECS Fargate 常驻 $X/月
- Agent 执行：按 microVM 数量和运行时间计费
- 数据存储：DynamoDB/S3 按量计费

高峰期需要 100 个并发 Agent？秒级扩展
低谷期只需 5 个？自动缩减

结果：成本完全可控，不会有"超出预期"的账单

3. 多租户隔离（SaaS）

一个平台，多个企业：

Company A：1000 Bot，每天 10 万条消息
Company B：50 Bot，每天 1 万条消息
Company C：5000 Bot，每天 50 万条消息

系统不混乱吗？
- 数据隔离：Company A 的数据 Company B 看不到
- 资源隔离：Company C 的 Bot 再多也不会影响 A 和 B
- 计费隔离：各自按使用量单独计费

这就是 SaaS 的本质。NanoClaw Cloud 设计完全针对 SaaS。

4. 代码执行的安全性

在企业环境里，最大的恐惧是"数据泄露"。

如果 AI Agent 有权限看到生产数据库的密码，
然后被 prompt 注入，会怎样？

NanoClaw Cloud 的设计保证：
✅ Agent 进程看不到数据库密码（Credential Proxy）
✅ 即使看到也跨不了租户（ABAC）
✅ 即使跨租户也只能操作被授权的资源
✅ 所有操作都有审计日志

所以即使最坏的情况发生，也有完整的恢复方案。

🔧 一键部署

这不是一个"企业功能"，但值得单独提一下。

# 全球区
ADMIN_EMAIL=[email protected] \
ADMIN_PASSWORD=SecurePassword123! \
./scripts/deploy.sh --region us-east-1

# 中国区
ADMIN_EMAIL=[email protected] \
ADMIN_PASSWORD=SecurePassword123! \
./scripts/deploy.sh --region cn-north-1 --mode ecsonly

# 自动完成 17 步操作：
# 1. 创建 VPC
# 2. 创建 DynamoDB 表
# 3. 创建 S3 桶
# 4. 配置 IAM 角色
# ... 
# 17. 配置告警

# 成功后：
# Web 控制台：https://nanoclaw.yourdomain.com
# API：https://api.nanoclaw.yourdomain.com
# 可以立即使用

这意味着什么？

不需要 DevOps 专家，一条命令就能部署企业级 AI Agent 平台。

📈 应用场景

场景 1：多部门企业 AI 助理

HR 部门：企业内部政策查询 Bot
- 独立 Bot，只能访问 HR 数据
- 其他部门看不到

工程部门：代码审查 Bot
- 独立 Bot，只能访问代码库
- HR 看不到代码

结果：一个平台，多个部门各自独立运营

场景 2：SaaS 提供商的 AI 功能

你的 SaaS 产品要加入"AI 助理"功能

选项 A：用公共的 ChatGPT/Claude
缺点：用户数据上传到第三方，不安全

选项 B：用 NanoClaw Cloud
- 部署在你自己的 AWS 账户
- 多租户隔离，每个用户的数据安全
- 可以集成到你的产品里
- 按你的品牌发布

结果：你的产品现在有 AI 助理功能，又很安全

场景 3：金融/医疗的合规需求

需要部署一个 AI 系统，但有严格的数据合规要求：
- 所有数据必须在特定国家/区域
- 必须完整的审计日志
- 必须能随时切断 AI 权限

NanoClaw Cloud：
✅ 部署在你的 AWS 账户（数据不离开）
✅ 完整的 CloudWatch 审计日志
✅ 秒级撤销权限（IAM 更新）

结果：通过合规审查

🎯 最后的话

AI Agent 看起来很酷，但在企业环境里很危险。

如果不小心设计，一个 prompt 注入就可能导致数据泄露。

NanoClaw Cloud 的六层安全架构说明：

安全不是事后补救，而是设计的核心。

从认证、数据隔离、权限控制、凭证保护、进程隔离到 Webhook 安全——每一层都在独立防护，一层被突破也无关紧要。

这是目前市面上对 Claude Code 企业化最完整的解决方案。

如果你正在考虑在企业里部署 AI Agent，NanoClaw Cloud 值得看看。

🔗 相关资源

GitHub：https://github.com/aws-samples/sample-cloud-native-nanoclaw
文档：See repo /docs 文件夹
部署指南：./scripts/deploy.sh --help
架构图：./docs/architecture.md

想在你的企业里安全地跑 Claude Code？

从 NanoClaw Cloud 开始。

NanoClaw Cloud：如何让 AI Agent 在企业环境安全运行？#

你想在公司里用 Claude Code 吗？#

🎯 问题的本质#

🔒 六层安全纵深架构#

第 1 层：用户认证（JWT + Cognito）#

第 2 层：资源隔离（查询层强制条件）#

第 3 层：ABAC 数据隔离（IAM 级别）#

第 4 层：Credential Proxy（核心创新 🎯）#

第 5 层：执行隔离（微虚拟机隔离）#

第 6 层：Webhook 安全（防伪造 + 限流）#

📊 六层安全的防御矩阵#

🏗️ 从单用户到多租户：架构演进#

NanoClaw（原始版本）#

NanoClaw Cloud（企业版）#

🌍 全球 vs 中国：两种部署模式#

全球区部署（AWS 官方推荐）#

中国区部署（完整替代方案）#

💡 为什么这个架构对企业很重要？#

1. 审计追踪（Compliance）#

2. 成本控制#

3. 多租户隔离（SaaS）#

4. 代码执行的安全性#

🔧 一键部署#

📈 应用场景#

场景 1：多部门企业 AI 助理#

场景 2：SaaS 提供商的 AI 功能#

场景 3：金融/医疗的合规需求#

🎯 最后的话#

🔗 相关资源#