shishirsharma963/agenticsecuritydemo

# Agentic Security 演示 购买工具并不等于拥有了控制措施。AWS Security Hub 汇总了数百个发现结果，却无人负责。工程师们将密钥和受监管数据粘贴到 AI 工具中，因为没有任何防护措施拦截。SOC 2 季节变成了一场截图寻宝游戏。控制措施，应当是每一次都能对风险进行分类、分配责任人、执行决策并留下证据的机制。 当前最棘手的问题成为了重点：对 AI 和自主代理处理受监管数据进行治理。一道护栏位于模型前端。它对提示词进行分类，对敏感部分进行 token 化处理，检查每一跳（per-hop）签名的代理身份，只有在此之后，才将请求路由至受 DPA（数据处理协议）保护的端点（Anthropic、OpenAI、Amazon Bedrock）。其他所有环节都遵循 AWS 上的相同模式：发现结果分类筛选、威胁检测、事件响应以及 SOC 2 证据收集。  观看演示：**[DEMO.md](DEMO.md)**。  ## 快速开始 ``` git clone https://github.com/shishirsharma963/agenticsecuritydemo.git cd agenticsecuritydemo python3 demo.py # one command, no install, no network ``` ``` pip install -r requirements.txt && pytest -q # 49 tests ``` 可选的可视化控制台： ``` pip install -r dashboard/requirements.txt streamlit run dashboard/app.py ``` ## 核心：AI 与代理安全 ### AI 提示词/数据治理 (`agentic_security/governance.py`) 该模块位于开发者（或代理）与 AI 工具之间。它会读取提示词并标记其中的内容：密钥、PII（通过真实的 Luhn 校验检测支付卡、SSN）、敏感记录、客户/账户上下文、生产日志、源代码。随后，它会针对每一项发现采取相应行动。拦截密钥；对 PII 进行 token 化；路由离开未经批准的端点；记录决策；开启轮换工单。Token 消耗被记入相应的成本中心，且运行过程会生成一份审计记录。如果关闭该护栏，相同的提示词就会以原始形式直接发送给模型。目标端点是真实工具的清单（[Anthropic](https://www.anthropic.com/)、[OpenAI](https://openai.com/)、[Amazon Bedrock](https://docs.aws.amazon.com/bedrock/)、Cursor）；受监管数据仅会被发送至受数据处理协议约束的端点。 ### 可验证的代理身份 (`agentic_security/identity.py`) 参与者链条不仅仅是一串字符串。`user -> agent -> agent` 链路中的每一跳都携带一个短期签名 token，其作用域限定于下一跳。护栏在信任并将其写入审计记录的来源之前，会验证整个链条，伪造或过期的链条将被拦截。生产级别的实现（即通过 STS 生成 RS256 JWT，并由仅持有公钥的网关进行验证）位于同源的 [agentidentity](https://github.com/shishirsharma963/agentidentity) 代码库中。 ### 外发消息同意机制 (`agentic_security/consent.py`) 向客户发送短信会使您受到 TCPA 的约束：必须事先获得明确同意，提供需立即遵从的退订选项，并且只能在接收人当地时间的早上 8 点至晚上 9 点之间进行联系。在营销活动发出之前，每条消息都会根据同意状态、STOP 列表和当地时间进行检查，随后被允许发送或拦截，同时生成一份携带 token 化联系人 ID（绝不包含原始值）的证据记录。这是一种适用于受监管行业的控制措施，而非局限于某一垂直领域：相同模式同样适用于电子邮件（CAN-SPAM、GDPR/CCPA）。 ## 相同模式的应用（AWS 原生） - **云发现结果分类筛选** (`agentic_security/triage.py`)：数百个合成的 [Security Hub](https://docs.aws.amazon.com/securityhub/) 发现结果（来自 [GuardDuty](https://docs.aws.amazon.com/guardduty/)、[Inspector](https://docs.aws.amazon.com/inspector/)、[Config](https://docs.aws.amazon.com/config/)）。如果仅按严重程度排序，危险项会被淹没；而通过“毒性组合”（面向公网的 EC2 + 敏感 S3 数据 + 可利用的 CVE + 宽泛的 IAM 权限）进行评分，则能凸显出少数构成真实攻击路径的风险，并将每一条路由给相应的责任人。 - **事件响应** (`agentic_security/incident.py`)：GuardDuty 标记的 IAM 密钥泄露场景，将其声明为包含严重程度、角色以及带有时间戳的遏制时间线（禁用密钥、隔离 EC2、轮换 [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/) 密钥、在 [CloudTrail](https://docs.aws.amazon.com/cloudtrail/) 中追踪持久化后门）的结构化事件。 - **SOC 2 证据** (`agentic_security/soc2.py`)：将每项控制措施映射到责任人、已经发出相应证据的 AWS 服务（[KMS](https://docs.aws.amazon.com/kms/)、Config、Security Hub、GuardDuty、[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/) + [Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)），旨在实现持续的证据收集，而非在审计时才去截图。 - **自扫描实验室与 CI** (`lab/` + `agentic_security/scanner.py`)：一个故意设计为存在漏洞的 Flask 应用及其安全加固后的孪生版本。扫描器能捕捉到存在漏洞应用中的密钥泄露、SQL 注入、未经身份验证的端点和调试模式，并报告加固后的应用是安全的。测试套件在 CI 中对此进行断言，因此该控制措施在保持构建通过的同时证明了自身的有效性。 ## AppSec、检测与云基线 相同的操作模型，应用于衡量安全主管工作绩效的核心环节：预测、预防、发现和修复。 - **威胁建模** ([THREAT_MODEL.md](THREAT_MODEL.md) + `agentic_security/threatmodel.py`)：作为数据维护的 STRIDE 模型，映射至 OWASP-LLM 和 MITRE ATLAS。每个威胁都明确指出了能缓解该威胁的控制措施，如果该控制措施不存在，测试就会失败，从而确保模型不会演变成纸上谈兵。`gaps()` 是待办事项列表。 - **渗透测试修复追踪器** (`agentic_security/appsec/pentest.py`)：将报告转化为有专人负责的工作。每个发现结果都会根据严重程度设定 SLA；追踪器会显示哪些事项已逾期以及相应的责任人。修复本身才是交付物。 - **DAST** (`agentic_security/appsec/dast.py`)：“CI 中的 DAST 和 SAST”中的动态部分。针对目标进行身份验证、安全标头和堆栈跟踪泄露的运行时检查；加固后的目标是安全的，并作为 CI 的准入门禁。 - **GuardDuty 自动响应** (`agentic_security/detection/autoresponse.py`)：检测即代码。发现结果会生成响应计划（禁用密钥、隔离实例、开启事件）。破坏性操作仅会在已知类型且严重程度高的情况下触发；对于未知信号，仅发出警报，绝不进行自动的破坏性操作。 - **IaC 安全基线** (`agentic_security/cloud/baseline.py`)：预防层。服务控制策略（Service Control Policies）使得不安全的操作无法实现（无法停止 CloudTrail、无法禁用 GuardDuty、无法在不使用 IMDSv2 的情况下启动实例、无法离开已批准的区域），再加上用于捕获偏移的 AWS Config 规则。最终渲染为真实的 SCP 策略文档和 Terraform 代码；每个 SCP 都注明了其预防的威胁（通过测试进行检查）。 ## 适用场景 这些机制是与领域无关的；它们在受监管行业中的价值体现在其保护的数据层上： - **医疗保健 (HIPAA)：**提示词和 S3 中的 PHI；同意控制可映射到患者外联服务。 - **金融科技 / 零售 (PCI DSS)：**持卡人数据（Luhn 校验）、token 化、密钥管理。 - **任何场景 (GDPR / CCPA / TCPA)：**PII 处理、数据处理协议、外发消息同意机制。 ## 状态与局限性 这是一个原型。各项机制均可运行且已经过测试；但覆盖范围仅为演示级别。各组件的生产级路径如下： | 领域 | 当前实现 | 生产级实现 | |---|---|---| | 提示词分类 | 确定性正则表达式 + Luhn | 具备上下文模型的商用 DLP 引擎 | | Token 化 | 截断哈希存入内存保险库 | 通过 AWS KMS 进行信封加密 + 在独立服务中保留格式的 token | | 代理身份 | 每跳 HMAC 签名 token，进程内验证 | 通过 STS 获取的 RS256 JWT，并由网关验证（见 agentidentity） | | 云分类筛选 | 加权求和，合成发现结果 | Security Hub 攻击路径 / 图可达性，结合 EPSS 和数据敏感度分级 | | 扫描器 | 行正则表达式 + 装饰器检查 | CI 中真实的 SAST/DAST 工具（例如 Amazon Inspector / CodeGuru） | 相关的选择与权衡已记录在 **[DECISIONS.md](DECISIONS.md)** 中。 ## 布局 ``` demo.py one-command CLI: every domain, bad vs good agentic_security/ governance.py AI prompt/data guardrail identity.py per-hop signed agent identity (verifies the chain) consent.py TCPA outbound-message consent guardrail triage.py AWS finding risk scoring + generator incident.py incident lifecycle + evidence soc2.py control -> owner -> AWS service -> evidence map scanner.py secret + SAST static scanner threatmodel.py STRIDE threat model as data appsec/ pentest remediation tracker + DAST detection/ GuardDuty auto-response (detection-as-code) cloud/ IaC secure baseline (SCP guardrails + Config rules) lab/ app_bad.py / app_good.py insecure vs hardened target for the scanner data/ seeded synthetic findings, consent + pentest records dashboard/ optional 5-tab Streamlit console tests/ 49 tests (also the CI gate) .github/workflows/ CI: tests + SAST + DAST THREAT_MODEL.md narrative threat model ``` ## 为什么这很重要：核心理念 处于该阶段的团队通常拥有工具，而非控制措施。工具界面上布满了发现结果，却无人负责；AI 被采用的速度远超任何人的治理能力；事件在聊天对话流中发生；SOC 2 变成了一年一度的手忙脚乱。作为公司的首位安全招聘人员，你的工作不是去购买更多的工具，而是要建立一套操作模型，并让其在现有的平台上运转起来： 这个代码库就是该模型的具体实现，且足够精简，能够实现端到端的运行。它从当前最困难的部分（对 AI 和自主代理处理受监管数据进行治理）入手，坦诚地说明了哪些部分是占位符、哪些部分可以扩展，并且它将证据视为控制措施的副产品，而非为了应付审计员的交付物。这就是拥有工具与拥有控制措施之间的本质区别。 ## 许可证 MIT，详见 [LICENSE](LICENSE)。

标签：AI安全, AWS, Chat Copilot, DevSecOps, DPI, Kubernetes, Python, 上游代理, 合规与审计, 数据安全与隐私, 无后门, 逆向工具