Tamnoon在AWS博客文章中介绍了Tami，这是一个基于Amazon Bedrock构建的智能体式云修复编排系统，用于调查、排序和修复AWS、Azure、Google Cloud及其他平台上的安全发现。文章描述的核心流程，是先收集证据并评估变更的安全性，再决定能否推进修复。只读调查与实际变更分开，修复方案起草前还要经过独立的安全评估。

把不同来源的发现整理为可评估的输入

Tami通过API集成接收来自CNAPP、CSPM提供商和云原生工具的安全发现，将它们转换为统一的数据结构，并补充资产及暴露情况的上下文，然后确定处理优先级。因此，所描述的输入流程包括接入、标准化和上下文补充，而不是仅把原始告警直接交给修复环节。

文章列出的发现来源包括Wiz、CrowdStrike、Palo Alto Cortex、Upwind、SentinelOne、Orca、Cyera、AWS Security Hub和GuardDuty。客户可以连接云账户和安全工具，也可以把处理结果传递到Slack、Jira、ServiceNow和GitHub。这里的多云发现来源与运行Tami自身服务的AWS基础设施，是文章分别描述的两个部分。

四类智能体分工，安全评分决定下一步

Tami将修复工作分配给四类专门的智能体。调查智能体生成只读调查步骤和完整计划，并使用由大语言模型担任评审者的验证层检查输出。安全评分智能体则把自动验证结果与分析人员的发现结合起来，为每项资产建立证据链，以偏保守的方式给出SAFE、RISKY或AWAITING DATA状态。

这一修复置信度指标用于区分哪些工作可以自动化，哪些需要人工审核。按照文章的说明，SAFE操作可以自动执行；对于RISKY或AWAITING DATA操作，Tamnoon嵌入式云工程师会参与处理。因此，系统所描述的自动化范围受安全判断约束，并不涵盖所有发现的无条件自动修复。

修复智能体只针对被判定为安全的发现启动，安排执行顺序、依赖关系和条件。每一步都遵循备份、修复、验证的结构，并提供回滚指导。代码生成智能体再把计划步骤转换为可执行的修复内容，前提是输入控制先检查任务相关性与提示注入。每个产物都必须进入自动生成和审查循环，并得到独立审查智能体的批准。

文章还描述了反思与重新生成环节：输出会与自动化结果、用户反馈以及来自实际已解决告警的训练数据核对，必要时引入人工参与。AI能力在提供给客户之前接受内部测试。这些措施构成文章所述的检查流程，但不能被理解为生产故障或提示注入绝不可能发生的保证。

Bedrock提供模型入口，部署限定在美国区域

Tamnoon表示，选择Amazon Bedrock的原因之一，是能够通过同一个API访问不同模型。这样可以按照推理、验证和审查任务各自的质量及成本要求选择模型，也能在不重建集成的情况下更换模型。按IAM限定权限，以及把敏感数据保留在AWS信任边界内，也是其列出的选择因素。

对于文章实际描述的工作负载，每项Tami任务均通过ChatBedrockConverse调用Anthropic Claude。推理在Tamnoon自己的AWS账户内、美国商业区域中进行，Bedrock跨区域推理负责区域间请求路由，所述部署的路由范围保持在美国境内。文章称，Bedrock不保留提示或生成结果，也不使用它们进行训练。

私有网络中的平台和并行处理

Tamnoon在自己的AWS账户中运行平台，并按环境隔离。API Gateway提供入口，AWS Certificate Manager管理加密，Cognito负责登录。平台核心部署在跨多个可用区的私有网络中。EKS承载仪表板服务，Lambda负责收集和分析安全发现，也承担修复执行。

EventBridge、SQS和Step Functions协调并行处理，使单条错误记录不至于阻塞其余记录。托管数据库与缓存保存状态，S3存放操作手册和产物，Secrets Manager保存凭据。文章进一步说明，相关Lambda服务位于私有VPC子网，没有公共入站访问，出站通信受到控制。

智能体治理与凭据隔离

Bedrock AgentCore治理智能体的操作，Bedrock Guardrails检查请求和生成的代码。按文章描述，防护覆盖每次请求和响应，会遮蔽个人身份信息及类似秘密的内容，过滤提示注入和禁止内容，并记录干预。这里既有输入和输出检查，也有对智能体行为的治理，两者都是所述架构的一部分。

AI智能体本身不持有云凭据。实际执行在隔离环境中完成，使用短期、限定到具体租户的凭据，相关信任由客户控制。修复还要经过带有审计记录的审批工作流。由此，生成修复内容、获得执行凭据以及通过审批，是描述中分别受到约束的环节。

每项服务拥有专用IAM执行角色。Bedrock权限限定为对指定推理配置文件和基础模型ARN执行bedrock:InvokeModel，不包含模型管理、训练或导出权限。每个函数访问Secrets Manager时仅限两个秘密，SQS权限限定于其输入队列，CloudWatch写入按命名空间限制。文章列出的托管策略是AWSLambdaBasicExecutionRole和AWSLambdaVPCAccessExecutionRole。

服务之间通过Cognito使用应用范围的OAuth2客户端凭据进行认证。每次调用只处理一条带租户上下文的SQS消息，也只接触一个租户的数据。这些规定与短期租户凭据、专用服务角色共同组成文章描述的访问边界，而不是让智能体获得不受限制的云账户权限。

模型变更、审计与故障处理

IAM策略、网络位置、模型标识和告警配置都定义在有版本记录的CloudFormation与SAM模板中。模型固定到带日期的标识，因此更换模型属于需要明确审查的代码变更。文章称，每次推理调用都会记录在CloudTrail中，并可归属到发起调用的角色；解码温度设为零，用于支持评分和规划的一致性。

在故障处理方面，每项服务配有支持重新投递的输入队列、错误处理函数和死信队列。CloudWatch针对超时及死信队列深度设置告警，并连接值班响应人员。这些配置说明了系统如何记录调用和呈现处理故障，与前述生成内容审查及修复审批分别承担不同的监督职责。

成效来自企业报告，验证范围需要区分

文章称，Tami已经分析超过一千四百万条云告警，这一数字由Tamnoon的《2026年云修复状况》报告跟踪。文章还报告，在九十天内关键云暴露减少超过百分之九十，且没有出现生产问题，并将相关成效归于Tamnoon自身的研究。这些是文章转述的企业结果，不能作为已获独立确认的结论。

所提供证据没有建立这些结果的独立验证，也没有给出样本规模或测量方法。文章同时提到人工工作减少，以及在不增加人员的情况下每位分析人员关闭更多暴露问题，但没有量化这两项改善。因此，读者能够从材料中了解其分工、控制和报告的成果，却不能据此计算明确的人工节省幅度，或把这些结果推广为每个客户都能获得的保证。

从完整流程看，Tami把发现接入、只读调查、安全评估、修复规划、代码审查和受控执行连接起来。决定自动执行还是交由工程师参与的关键，仍是SAFE、RISKY和AWAITING DATA的分类。文章展示的是带有审批和人工介入路径的修复编排方案，其已报告的成效与尚未提供的独立测量依据，应当分别理解。