低代码与高代码智能体开发的网络安全策略

随着各组织开始在业务系统中部署人工智能智能体，开发速度与安全监督之间的联系日益紧密。制定低代码和高代码智能体开发的网络安全策略时，必须考虑两种开发方式分别如何授予信息访问权限，以及如何赋予智能体执行操作的能力。针对性的防护措施可以应对这些差异，而统一的治理机制则能确保随着部署范围扩大，智能体的活动仍与获准执行的任务保持一致。

低代码与高代码 AI 智能体开发有何不同

低代码平台让开发者能够通过可视化界面和预置连接器组装智能体，并将其连接到各类业务服务。高代码开发则赋予程序员更大的灵活性，让他们能够通过自定义代码、工具集成和执行环境来定义智能体的行为。无论采用哪种方式，都必须监督智能体能够访问的信息以及能够执行的操作。

由于控制权所在的位置不同，两种开发方式所承担的安全责任也不一样。低代码开发者在平台设置范围内开展工作，而这些设置决定了共享方式和连接器访问权限，因此配置决策尤为重要。高代码团队则要对运行智能体指令的软件和环境承担更多责任，包括为文件和凭据设置访问边界。

美国网络安全和基础设施安全局 指出了智能体 AI 的多项风险，这些风险为两种开发方式都提供了有用的分析框架。攻击面扩大是指新增了更多入口点，而权限蔓延则是指访问权限不断累积。行为偏离是指智能体的行为偏离预定任务；事件记录不清则会增加调查难度。广泛使用的连接器和不受限制的命令行工具，可能以不同形式引发同类问题。

低代码 AI 智能体的安全风险与应对措施

低代码降低了使用门槛，让传统开发团队之外的员工也能创建智能体。安全监督也应覆盖这些开发者，确保便捷的连接方式符合获准的业务用途。

低代码环境在安全方面的不足

公民开发者可能会将智能体连接到共享文件或业务应用，却未能充分了解智能体拥有的权限。这些连接所授予的访问权限可能会暴露敏感信息，或使智能体能够执行超出预定工作流程的操作。过于宽泛的共享权限和不明确的所有权关系还会加剧这种风险。

低代码的普及规模意味着，各部门都需要一致的监督机制。在 2024 年的一项市场分析中，Forrester 报告称 87% 的企业开发者会在部分开发工作中使用低代码平台。这一发现针对的是一般开发工作，因此说明了这些平台的普及范围，但并未专门衡量 AI 智能体的采用情况。

加强低代码智能体安全的实用方法

团队应根据每个智能体所承担的任务审查连接器权限，并落实最小权限原则。应建立集中式清单，记录每项部署的负责人和已连接的服务，并为敏感操作设定审批要求。这样，安全团队就能据此识别未登记的智能体，并调查不当访问行为。

Microsoft 的数据治理方法强调对业务信息实施受控访问。Microsoft Digital 首席架构师 Naveen Jangir 建议各组织“通过适当的访问限制来治理和保护数据”。这些控制措施能让获授权的用户和 AI 功能在既定权限边界内 使用数据，同时避免不必要的信息暴露。将连接器策略与明确的责任归属结合起来，有助于把这些限制落实到日常开发中。

高代码 AI 智能体的安全风险与应对措施

团队使用 AI 编码智能体构建定制系统时，生成的代码变更可能会快于人工审查的速度。因此，高代码开发的安全保障既需要覆盖开发流程，也需要覆盖智能体执行任务的环境。

高代码开发面临的独特安全挑战

编码智能体在读取包含攻击者提供的指令的外部代码库时，可能遭遇间接提示注入。如果智能体在拥有开发工具访问权限的情况下遵循这些指令，就可能运行不安全的命令或暴露凭据。潜在后果在一定程度上取决于其执行环境允许它访问哪些文件、工具和外部目标。

NVIDIA 的沙箱指南针对执行边界内的凭据暴露问题提出了应对方法。指南指出，“沙箱环境应依赖显式注入密钥”，以限制对凭据的访问。因此，当任务只需要有限访问权限时，智能体 不应继承完整的环境凭据。团队应按具体任务配置凭据，并确保智能体无法访问无关密钥。

强化高代码智能体流水线的策略

受限执行环境应根据任务限制文件访问和出站连接。团队还应对生成的代码进行静态应用安全测试。独立审查人员应检查自动化检查可能遗漏的授权决策或业务逻辑。这些措施旨在应对执行边界方面的问题以及生成软件中的弱点。

Amazon Web Services 在其编码智能体控制框架中建议将代码生成与评估分开。该公司指出：“使用单独的会话有助于避免自我确认偏差。”然而，使用同一模型的两个会话在审查过程中可能会存在相同的根本盲点。在可行的情况下，采用不同的模型进行审查，并由人工评估对安全敏感的更改，可以进一步加强审查。

构建兼顾两种开发方式的安全策略

无论是低代码还是高代码智能体开发，只要智能体之间会交换信息，就需要从整体上掌握其活动情况。例如，低代码工作流可能会将内容发送给定制开发的智能体，而该智能体随后会调用另一项业务服务。若分别审查各个组件，安全团队可能就无法获得理解整个流程所需的上下文。

Darktrace 的 AI 安全专家认为，各组织 必须检查提示和会话，同时审查企业级生成式 AI 工具以及这两种开发方式中的响应。其观点还涵盖软件即服务和安全访问服务边缘环境。具备这种可见性后，各组织便能获得所需的上下文，从而“检测巧妙的对话式提示攻击和恶意链式攻击”。

Darktrace 的观点支持制定更全面的低代码和高代码智能体开发 AI 安全策略，因为提示可见性、会话监控和身份监督有助于团队了解智能体如何在互联工具之间交互。安全团队应检查指令在关联会话中的变化情况，以及后续操作是否仍符合最初的授权。他们还应考虑为调查而保留的任何信息具有何种敏感性。

智能体长期安全的治理与监控

每个智能体都应有明确的责任人，并且应明确定义其获准执行的工作范围，无论采用何种开发方式。治理机制还应明确谁有权批准对该范围的更改，以及当智能体出现异常行为时谁有权暂停其活动。

有关智能体治理的研究指出，为了落实问责，智能体需要拥有 可验证身份且可审计的权限。这种做法将授予权限的人与智能体可以执行的任务关联起来。这样，各组织就能根据相应授权核查操作。

团队应维护活动记录，将委派的权限与工具使用情况及其结果关联起来。随着能力发生变化，团队应定期重新审查这些权限，移除已完成工作遗留的访问权限，并确认责任人信息仍然有效。开发团队和安全团队可以通过这些审查，确保运营控制措施与智能体获批的用途保持一致。

及时应对智能体安全风险

低代码开发需要谨慎管理平台权限和连接器治理，而高代码开发则要求密切关注定制执行环境和代码审查。集中监控和一致的问责机制为监督智能体如何访问信息、如何在互联业务系统中采取行动奠定了共同基础。随着智能体能力不断扩展，开发人员应根据智能体工具和职责的变化重新评估安全措施，并在每次部署的整个生命周期内明确其获准开展的活动。