AI时代的非人类身份安全
随着AI在企业中的崛起，攻击面也在不断扩展。了解如何保护非人类身份（Non-Human Identities, NHIs）并防止未经授权的访问。
非人类身份（NHIs）近期成为焦点并非偶然——随着AI工具和自主代理的快速普及，企业的NHI数量正呈爆炸式增长。这一趋势也引发了关于机器身份与治理的大量研究和讨论。
与系统的普通用户类似，NHI（如AI代理、机器人、脚本和云工作负载）通过密钥（secrets）进行操作。这些凭证赋予其访问敏感系统和数据的权限，可能以多种形式存在，且必须从创建到销毁全程受控。然而，机器无法使用多因素认证或通行密钥（passkeys），而开发者在部署应用时可能生成数百个此类凭证。
AI加速NHI的扩张与风险
企业AI的采用速度惊人，迫使开发者以前所未有的速度推出NHI。AI虽能提升效率，但也带来隐私泄露、密钥暴露和不安全代码等风险。大型语言模型（LLMs）的应用场景令人兴奋，但需谨记：技术引入越多，攻击面越大——尤其是当AI代理被赋予自主权时。
AI代理带来的NHI风险
1. AI代理与密钥泛滥（Secrets Sprawl）
“AI代理”是基于LLM的系统，可自主决策如何完成任务。它们不同于传统的确定性机器人（仅按开发者预设的步骤执行），而是能访问内部数据源、搜索互联网，并代表用户与其他应用交互。
例如，一个AI采购代理可以分析需求、通过电商平台比价、与AI聊天机器人议价，甚至自主下单。每个安全通信都需要凭证，而这类代理需通过DevOps流程部署，导致更多跨环节的身份验证需求。密钥往往在系统、日志和仓库中意外散落。
企业常为AI代理赋予比传统机器人更广泛的读写、甚至创建和删除权限。由于AI代理的自主性，若权限限制过严，其任务可能受阻；但宽松权限又易导致过度授权。
风险点：任一密钥泄露都可能引发数据泄露或未经授权的交易。需通过最小权限访问、API密钥保护和审计日志来强化NHI治理，并关注密钥存储之外的暴露风险。
2. 孤立的API密钥（Orphaned API Keys）
孤立API密钥指不再与用户账户关联的密钥（如员工离职后未被删除的密钥）。在NHI场景中，密钥的“归属权”模糊（开发者？运维团队？），导致其极易被遗忘却仍有效。
关键问题：谁应对这些密钥引发的安全漏洞负责？
3. 基于提示的架构与敏感数据暴露
AI助手（如ChatGPT、Gemini、GitHub Copilot）依赖提示（prompt）架构，通过上下文、命令和数据与LLM交互。这种模式虽简化了开发，但也可能导致敏感信息（如API密钥）被写入提示或日志。
案例：财务团队用AI聊天机器人处理发票时，若提示中包含API key ABC123，该密钥可能被明文记录。若日志未加密，攻击者可借此入侵发票系统。
防护措施：需阻止开发者及用户将敏感数据嵌入提示或日志，并扫描LLM输出中的异常信息。
4. AI代理与数据收集风险
AI代理常从以下来源收集数据：
- 云存储（如AWS S3、Google Drive）
- 企业应用（如Jira、Confluence、Salesforce）
- 通信系统（如Slack、Microsoft Teams）
风险：若AI代理可访问这些系统中的任何数据，攻击者亦可滥用其NHI权限。需定期轮换所有内部系统的密钥，并清理日志。
5. AI生成代码与嵌入式密钥
GitHub Copilot、Amazon CodeWhisperer等AI编码工具已被超50%的开发者使用。然而，AI生成的代码可能诱导开发者硬编码密钥（如API密钥、数据库凭证）。
案例：开发者要求Copilot生成调用云服务的代码时，可能得到：
import requests
API_KEY = "sk_live_ABC123XYZ"
response = requests.get("https://api.example.com/data", headers={"Authorization": f"Bearer {API_KEY}"}) 若匆忙中替换为真实密钥并提交至代码仓库，凭证可能被泄露。
防护：通过预提交钩子（pre-commit hooks）等工具扫描代码，防止密钥泄露。
未来方向：如何保护非人类身份
- 发现密钥：自动识别企业环境中的所有AI代理凭证（包括存储库内外）。
- 评估风险：明确密钥的用途、访问范围及关联的关键系统。
- 动态防护：实时监控提示和日志，防止敏感数据嵌入。
让NHI治理跟上AI速度
AI代理的部署速度与复杂性并存，既带来效率提升，也伴随风险。随着AI普及，保护机器身份已非可选，而是必需。唯有通过系统化的密钥管理、权限控制和持续监测，才能在AI时代实现安全与创新的平衡。
