Cynative Security Research Agent

我们有过一场辩论：是只文档化如何正确限定凭证范围然后交给你去处理，还是强制只读——即便你用管理员凭证运行也强制只读？我们选择了强制，尽管代价是需要持续跟上各提供商发布的新API。从每个提供商拉取权限定义（几MB大小，默认每日更新）而不是用静态映射，这样能自动保持覆盖范围是最新的。每个API调用都会解析出所需的IAM操作，并在绑定凭证之前根据提供商自身的策略定义进行授权，无法分类的请求则默认拒绝。允许集来自提供商本身（AWS IAM操作模拟、GCP角色权限评估、Azure RBAC角色定义、K8s集群自身的实时RBAC角色视图），因此覆盖范围会随着API的增长而跟踪。在AWS上，假设角色凭证还会额外通过STS AssumeRole重新发放，范围限定为SecurityAudit。每个请求的主机都被固定到其映射的服务和区域，并且在连接前验证解析出的IP，这样智能体只能访问你自己的基础设施。代码执行没有主机访问权限，每个调用都会被强制通过只读操作门控，否则失败。

这个只读强制设计确实比大多数只文档化最佳实践并指望你遵守的工具要彻底得多。不过在将其指向真实环境之前，我想先搞清楚一件事——这个工具产生的结果基本上是一份暴露了什么以及如何访问的完整地图。这些输出生成后存放在哪里？审计历史本身是否有访问控制？因为那套历史本身就会成为一个非常有价值的目标。

针对我们的AWS环境跑了几项检查，只读防护确实是强制执行的，不是空话。每轮沙箱化脚本这种方式感觉是对的，比指望一个MCP工具表现良好要靠谱。

说实话，我很喜欢把IAM限定的只读层作为默认设置，而不是需要你记得开启的选项。大多数安全工具把最小权限原则当成家庭作业，你们基本上把它融入到了调用路径里。这种克制需要真正的思考。

调查云基础设施而不冒生产风险，这个承诺很吸引人。你们如何强制执行只读边界？每个发现结果是否都包含了用于得出该结论的证据和所使用的云资源？

分类上默认 fail-closed 是正确的做法，但这引出一个时间问题——你每天拉取权限定义，那么当某天某个 provider 发布了一个全新的 API action，而当天拉取还没包含它时，会发生什么？是直接拒绝分类并阻塞该调用直到下一次同步获取，还是针对这个空档期有某种回退机制？