@akshay_pachaar: AI安全远不止AI本身。在产品中加入LLM调用，安全关注点主要集中在提示过滤、输出…

X AI KOLs Timeline 新闻
ai-security infrastructure aws llm prompt-filtering data-governance cloud-security

摘要

本帖子解释了为什么AI安全需要基础设施层控制（IAM、VPC、加密、日志记录），而不仅仅是应用层的提示过滤，并以AWS服务为例。

AI安全远不止AI本身。 在产品中加入LLM调用，安全关注点主要集中在提示过滤、输出防护和输入验证。 这至关重要，但它只覆盖了应用层，同样重要的基础设施层也需要自己的控制措施。 为了理解这一点，追踪一次模型调用。 提示离开应用，到达提供商端点，根据其保留策略，它会留在外部日志中数天。 如果提示包含任何受监管或私有数据，它就会超出应用的边界。 这不是提示过滤的失败，因为它只控制进入模型的内容，而不强制执行数据可以流向何处或谁可以存储它。 除了应用层控制之外，两个基础设施层面的问题需要单独处理： 1) 首先是每个请求。 每次模型调用都会将数据移出应用边界。谁可以在传输中访问它？它是否限于正确的租户？ 2) 其次是状态漂移。 提供商是否保留数据？保留多久？一个租户的提示是否可能通过无意泄露进入另一个租户的上下文？AI输出是否保持在企业协议要求的合规边界内？ 团队通常在应用代码中解决这两个问题，每个新的AI功能都有自己的： - 自己的作用域逻辑 - 自己的加密 - 自己的日志记录 十个功能意味着同一控制措施的十种独立实现。 将两者移至基础设施层可以简化这一点。 - 如果IAM策略控制哪些服务可以调用哪些端点，那么每次新的模型调用都会自动继承该边界。 - VPC隔离在网络层面保持租户流量分离。 - 加密默认覆盖所有数据流。每次API调用，包括模型调用，都会被记录，而无需功能代码处理任何这些。 @awscloud 将其构建为托管基础设施，他们今天与我合作解释其工作原理。 通过Bedrock或SageMaker的模型调用继承与其他任何服务相同的IAM、VPC、加密和CloudTrail边界。 例如，IDEMIA在生产中运行此模式。该公司为45家以上的美国政府机构处理身份数据。 在迁移到AWS GovCloud中Amazon EKS上的容器后，他们削减了30%的成本，并将交付速度提升了4倍，安全性来自基础设施而非应用代码。 您可以了解更多关于AWS如何支持ISV以这种方式构建的信息 → https://fandf.co/4d23iNH 此外，我写了一篇关于生产级代理框架中11个组件的详细分解，即包裹LLM的完整软件层。这篇文章涵盖了底层内容。框架的安全性取决于其运行层的安全性。 请阅读下文。
查看原文
查看缓存全文

缓存时间: 2026/06/25 13:21

AI安全远不止AI本身。

在产品中引入大语言模型调用时，安全重心往往会放在提示过滤、输出护栏和输入验证上。

这固然关键，但仅覆盖了应用层，而同样重要的基础设施层也需要自己的控制措施。

要理解这一点，可以跟踪一次模型调用的完整路径：

提示信息离开应用、到达提供商端点，根据其数据保留策略，会在外部日志中留存数天。
如果该提示携带任何受监管/隐私数据，它就已经越过了应用的边界。

这不是提示过滤的失败——它只控制什么数据进入模型，并不能强制规定数据可以流向何处、谁可以存储它。

除了应用层控制之外，两个基础设施层面的问题同样需要单独覆盖：

1）第一个问题涉及每次请求。
每次模型调用都会将数据移出应用边界。传输过程中谁能访问它？是否限定在正确的租户范围内？

2）第二个问题是态势漂移。
提供商会保留数据吗？保留多久？一个租户的提示是否会通过非自主泄露进入另一个租户的上下文？AI输出是否始终处企业协议所要求的合规边界内？

团队通常会在应用代码中解决这两个问题——每个新AI功能都配有：

  • 自己的作用域逻辑
  • 自己的加密方案
  • 自己的日志记录

十个功能就意味着十套相同控制机制的独立实现。

将两者迁移到基础设施层可以简化这一点：

  • 如果IAM策略控制哪些服务可以调用哪些端点，那么每个新模型调用都会自动继承该边界。
  • VPC隔离在网络层面将租户流量分隔开。
  • 加密默认覆盖所有数据流。每一次API调用（包括模型调用）都会被记录，而无需功能代码处理其中任何工作。

@awscloud 将这一点构建为托管基础设施，他们今天与我合作，解释了其工作原理。

通过Bedrock或SageMaker进行的模型调用会继承与其他服务相同的IAM、VPC、加密和CloudTrail边界。

例如，IDEMIA在生产中运行了这种模式。该公司为45个以上美国政府机构处理身份数据。

在迁移到AWS GovCloud的Amazon EKS容器后，他们成本降低了30%，交付速度提升了4倍——安全来自基础设施，而非应用代码。

欲了解更多关于AWS如何支持ISV以这种方式构建的信息，请访问 → https://fandf.co/4d23iNH

此外，我还撰写了一篇详细的分析文章，介绍生产级AI代理框架中的11个组件——即包裹LLM的完整软件层。本文涵盖了它之下的内容。该框架的安全性只取决于它运行的那一层。

阅读下文。

相似文章

通往AGI之路中的安全保护

OpenAI Blog

OpenAI 概述了在通往 AGI 过程中的全面安全措施，包括由 AI 驱动的网络防御、与 SpecterOps 的持续对抗性红队测试，以及为 Operator 等新兴 AI 代理设计的安全框架。该公司强调主动威胁检测、业界合作，以及安全措施与基础设施和模型的深度集成。

每个AI代理在上线前所需的7层安全防护

Reddit r/artificial

一份实用指南，概述了AI代理在上线前应具备的七个优先安全层，包括强化系统提示、对抗性测试、输入/输出扫描以及多轮会话跟踪。基于调查结果，73%的生产级AI部署存在提示注入暴露风险。