随着AI Agent在企业中的规模化部署，安全问题正成为悬在AI创业头上的一把利剑。VentureBeat最新调研显示，69%的企业仍在让AI Agent共享凭证，这种做法直接导致安全事件频发。在近期举办的VB Transform大会上，NTT DATA AIVista首席技术官Mukesh Karki与Snowflake首席安全与信任官Mayank Upadhyay共同指出，身份认证只是AI Agent安全治理的起点，真正决定企业能否在AI赛道中行稳致远的关键，在于构建从身份到行动、再到审计的全链路防护体系。对于每一家投身AI创业的公司而言，这不仅是技术问题，更是能否获得监管机构信任的“运营许可证”。
共享凭证：AI Agent安全的第一道裂缝
当你把API密钥塞进一个AI Agent，它就能以任意身份调用各种SaaS服务——这听起来高效，却是安全噩梦的开始。Upadhyay直言，传统软件时代遗留的假设正在制造系统性风险。在传统世界里，软件按确定性路径执行，开发者清楚地知道每个API调用会触发什么结果。但AI Agent拥有“自主大脑”，它会不断重新规划行动路径。如果赋予它超出目标所需的权限，Agent天生的探索性就会让它尝试各种操作，从而产生意想不到的副作用。
更糟糕的是，共享静态API密钥让问题雪上加霜。Upadhyay指出，单一密钥意味着Agent可以“合并所有人的需求”，一旦被盗用或在内部被滥用，根本无法追溯。当安全事件发生时，企业甚至无法确定是哪个Agent触发了违规操作。这种“暗箱”状态在AI创业早期或许还能忍受，但一旦进入银行、保险、医疗等强监管行业，高概率成为致命短板。
对于正在AI投资中寻找机会的创业者来说，这一洞察值得警惕：许多AI创业公司为了快速验证产品，往往采用最低成本的凭证管理方式，却忽视了后期合规成本可能数倍于初期开发成本。AI工具导航上大量开源的Agent框架默认使用静态密钥，这相当于给系统埋下了一颗定时炸弹。
作用域凭证：只够“入场”，远非“通关”
Karki的客户集中在保险、医疗和金融领域，这些行业对合规的要求近乎苛刻。在他看来，作用域凭证（scoped credentials）只是“入场券”。“在监管环境中，一个没有经过严格作用域约束的Agent根本不可能运行。”但这仅仅是起点，企业还需要两层叠加约束：第一层是Agent运行所在的司法管辖区，第二层是企业自身的内部规则。
举例来说，一个处理华盛顿州理赔的AI Agent，与处理加州理赔的Agent所遵循的法规截然不同。而且每笔理赔的细节千差万别，静态的作用域凭证根本无法动态匹配。Karki强调，授权必须基于具体行动（action-based）和具体规则（rules-based），在Agent执行操作的那一刻实时判断是否允许。这意味着传统的“先授权、再执行”模型需要被颠覆——授权应当与行动同步发生，而非提前绑定。
这一观点对AI创业公司的产品架构设计影响深远。许多AI Agent技术平台仍在使用粗粒度的权限控制，将“是否允许访问数据库”视为一个开关。但在实际场景中，Agent可能只需要读取特定客户的特定字段，而不是整张表。大模型训练和推理的分离也加剧了这种复杂度——模型层、工具层、数据层的权限需要协同管理，任何一层的漏洞都可能被Agent利用。
员工类比失灵：AI Agent不是“新员工”
很多人喜欢把AI Agent比作新入职的员工，认为它们需要时间学习公司流程、建立信任。Karki认为这个类比在数量级上完全失效。“如果每个员工都有100个Agent，你不可能给每个Agent做背景调查，更不可能像带新人一样逐一带教。”信任是逐渐建立的，但企业无法用管理人类的方式管理数千个AI Agent。
Upadhyay提出了一个更务实的比喻：把AI Agent当成实习生。它们有好意，但并不知道自己在做什么，需要持续监控，逐步建立信任。在Snowflake平台，管理员可以设置全局护栏（比如只读操作），开发者在启动每个会话时进一步缩小Agent的权限范围。这种“层级收紧”的策略，既保证了Agent的灵活性，又防止了权限失控。
对于AI创业团队而言，这个比喻揭示了产品设计的核心矛盾：Agent的“能力”与“约束”之间需要动态平衡。如果约束过紧，Agent无法完成任务，用户体验差；如果约束过松，安全风险高。在AI赛道中，那些能够提供精细化、可配置的Agent权限控制方案的公司，将获得更大的竞争优势。这也是为什么AI投资机构开始将“安全治理能力”作为评估AI创业项目的重要指标。
三层治理架构：从Agent到数据层的全面防护
Karki明确指出，治理必须发生在每一次Agent行动中，并且必须独立于Agent之外。“只有这样才能在未来证明，Agent执行的操作是在其权限范围内的。”Upadhyay将治理分解为三个层面：
- Agent层：覆盖身份、工具权限和MCP（模型上下文协议）治理。这是第一道防线，确保Agent只能使用被授权的工具，并且每个工具调用都经过身份验证。 - 模型层：处理间接提示注入攻击，并允许模型在客户VPC内运行，从而让提示词对模型提供商不可见。这对于金融、医疗等对数据隐私要求极高的行业尤为重要。 - 数据层：涵盖最小权限访问、零拷贝架构和基于角色的访问控制。数据是AI Agent的“燃料”，也是最容易被窃取的部分。
三个层面缺一不可。Upadhyay强调，即使Agent层和模型层做得再好，如果数据层存在漏洞，攻击者仍然可以通过Agent间接获取敏感数据。这种三层架构为AI创业公司提供了一套可落地的安全框架——无论你是在开发AI画图工具还是企业级决策Agent，都需要从第一天起考虑这三个维度的防护。
值得注意的是，许多创业公司倾向于使用现成的AI工具箱来快速搭建Agent，却忽略了这些工具默认的安全配置通常只适用于原型环境。文生图等轻量级应用或许可以容忍一些安全盲区，但涉及金融交易、医疗诊断等严肃场景时，任何一个层级的缺失都可能造成灾难性后果。
审计先行：企业AI Agent治理的当务之急
对于正在盘点现有AI Agent安全状况的企业，Upadhyay建议从两个地方入手。第一，审计静态密钥的权限——这是最大的可修复攻击面。很多团队仍在代码中硬编码API密钥，一旦密钥泄露，整个系统都会暴露。第二，通过MCP网关解决“影子AI”问题。许多开发者为了快速迭代，私下运行盗版的开源MCP服务器，导致IT部门完全失去对系统可视性的控制。
Karki则给出了更严厉的警告：安全治理必须在Agent系统设计之初就内置，不能等到系统跑起来之后再打补丁。“如果你已经有一套运行中的Agent系统，再想向审计师证明每一个Agent行为的原因，几乎是不可能的。”可证明性（provability）必须从系统设计阶段就扎根，就像建筑的地基，一旦建成后再加固，成本高且效果差。
这一观点对AI创业公司的研发流程有直接指导意义。产品经理和工程师应该将“可审计性”作为功能需求的一部分，而非事后添加的合规负担。例如，在抠图或背景去除这类看起来无伤大雅的工具中，如果Agent需要访问用户上传的图片，同样需要记录每一次图片处理操作的上下文，以便在用户投诉或数据泄露时能够追溯。
约束与能力之间的权衡，可以通过任务级置信度评分来缓解：对高风险操作保留自主执行，用沙箱环境作为中间路径。但Karki强调，这些策略的有效性完全取决于是否在系统设计阶段就考虑到了。
结语：AI创业的“安全护城河”是设计出来的
从共享凭证到三层治理，从员工类比到审计先行，NTT DATA与Snowflake专家给出的建议清晰地勾勒出一条AI Agent安全治理的路径。对于AI创业公司而言，这不仅是技术挑战，更是商业机遇。在AI赛道中，能够率先建立起可证明、可审计、可扩展的安全体系的企业，将在客户信任、监管合规和资本市场上占据先机。AI投资者的目光正在从单纯的模型能力转向系统化安全能力，因为没有人愿意为不可控的“黑箱”付费。
AI创业的本质不是“跑得更快”，而是“跑得稳”。当你的Agent开始处理真实的业务数据时，每一次身份验证、每一次权限检查、每一次审计日志记录，都是在为你的商业模式铺设安全护城河。记住：可证明性，就是你的运营许可证。