AI 应用安全：先把租户边界、检索输入和执行面串起来，再谈防护清单

很多关于 AI 应用安全的文章，第一反应都是：

• •防 Prompt 注入
• •防数据泄露
• •做内容过滤

这些都重要，但如果只把安全理解成几条输入输出规则，你很快就会遇到更难的问题：

• •多租户数据到底怎么隔离
• •上传文件、检索结果和网页内容能不能直接进高权限上下文
• •模型调用是否带着超出用户权限的数据
• •secrets、日志和评估数据会不会自己变成新的泄露源

所以 AI 应用安全更适合被理解成“应用边界治理”，而不是一组零散的防护技巧。

对一个真实 AI 应用来说，攻击面通常至少有四层：

• •身份与租户边界
• •不可信输入与检索内容
• •工具和外部执行面
• •输出、日志和运维链路

如果团队只盯着 Prompt 注入，而忽略了租户隔离、工具权限和日志脱敏，最后很可能还是会在别的地方出事故。

1. 身份与租户边界层

这一层至少要回答：

• •请求是谁发起的
• •属于哪个租户、项目或组织
• •当前会话能访问哪些知识和工具
• •用户的权限是否真的传递到了模型调用链

如果没有这一层，后面的所有防护都容易变成“系统实际上在用管理员视角做回答”。

2. 不可信输入与检索层

AI 应用最大的一个现实变化，是很多以前不会被“执行”的文本，现在会进入模型上下文：

• •用户输入
• •上传文档
• •检索结果
• •网页抓取内容
• •外部工具返回文本

这些内容都应该被默认视为不可信。它们可以被阅读、被摘要，但不应该自动升格成系统指令。

3. 工具与执行层

真正危险的不是模型“说错一句话”，而是它能：

• •发消息
• •调后台接口
• •读组织知识库
• •修改状态
• •调代码执行环境

一旦触碰这些执行面，安全问题就会从“回答不准确”升级成“业务副作用失控”。

4. 输出、日志与审计层

很多团队会在输出侧做一些过滤，却忽略了：

• •trace 是否记录了敏感原文
• •评估集里是否保留了客户数据
• •错误日志里是否包含 token、密钥或文件片段
• •审计记录是否能解释一次高风险调用是怎么发生的

如果这层不收好，观测系统本身就会变成风险面。

在 AI 应用里，一个更稳的职责拆分通常是：

更适合模型处理的部分

• •理解用户问题
• •提取文档信息
• •整理检索结果
• •生成候选答案或执行计划

更适合系统处理的部分

• •鉴权与 RBAC
• •租户数据过滤
• •工具和知识访问控制
• •secrets 管理
• •高风险动作审批

如果让模型直接跨过这些系统边界，最后最容易发生的不是“表达有点问题”，而是真正的越权和泄露。

更稳的方式，是在进入模型前先建立一份安全上下文。

from typing import Literal
from pydantic import BaseModel, Field


class SecurityContext(BaseModel):
    user_id: str
    tenant_id: str
    access_level: Literal["public", "internal", "restricted"]
    allowed_tools: list[str] = Field(default_factory=list)
    allowed_sources: list[str] = Field(default_factory=list)
    contains_untrusted_content: bool = True
    requires_human_review: bool = False


def evaluate_request(context: SecurityContext, policy_engine):
    checks = policy_engine.check(context)
    if checks.blocked:
        return {"status": "blocked", "reason": checks.reason}
    return {"status": "allowed", "context": context}

这个模式的价值在于：

• •用户、租户和敏感级别可以被显式传递
• •工具和知识访问先由系统决定
• •不可信输入不会自动获得高权限

很多旧写法会通过正则去匹配：

• •ignore previous instructions
• •system:
• •forget everything

这些模式能挡住一些显性的攻击，但远远不够。因为真正更重要的问题是：

• •不可信内容是否和系统规则混在一起
• •模型输出是否必须走 schema 校验
• •工具调用前是否再次做权限检查

也就是说，Prompt 注入的核心不是“某些词很危险”，而是你有没有让不可信文本影响高权限行为。

AI 应用一旦加上：

• •RAG
• •文件上传
• •Code Interpreter
• •外部网页抓取

安全问题就会明显升级。因为这意味着系统开始处理更多外部内容，也更容易触碰真实副作用。

更稳妥的做法通常包括：

• •检索前先做租户过滤
• •上传文件和解析结果走隔离存储
• •代码执行环境使用最小权限与短生命周期
• •对高风险产物和外发动作做人工确认

很多安全设计只关注“用户看到了什么”，但真实事故经常发生在：

• •失败重试日志
• •trace 平台
• •评估样本
• •支持排障导出

更合理的默认策略通常是：

• •输出前脱敏
• •日志最小化
• •trace 支持匿名化或字段屏蔽
• •评估和调试数据走专门访问控制

这样系统才能在可观测和可合规之间找到平衡。

AI 应用安全的评估，更应该围绕这些问题：

• •是否发生跨租户数据访问
• •上传文档是否能污染高权限上下文
• •工具调用是否会绕过用户权限
• •日志和 trace 是否残留敏感内容
• •人工审核是否拦住了高风险动作

这些指标比“正则命中了多少注入关键词”更有工程意义。

1. 把安全等同于输入过滤

真正的安全边界，大量发生在鉴权、工具权限、知识访问和日志链路里。

2. 用管理员上下文帮普通用户回答问题

这会让系统天然带着越权风险，即使模型本身看起来很“听话”。

3. 只管用户可见输出，不管 trace 和评估数据

很多泄露不是发生在最终答案，而是发生在调试和观测系统里。

AI 应用安全真正可交付的价值，不是做一张“防 Prompt 注入”清单，而是把身份、租户、检索、工具、输出和日志收进同一条安全链路：

• •先把用户和租户边界讲清楚
• •不可信输入始终视为不可信
• •工具和副作用动作必须由系统重新校验
• •输出、日志和 trace 一起纳入脱敏与审计

只要这些边界做实，AI 应用才能真正进入长期可维护的生产状态。

• •OpenAI Safety Best Practices
• •Best Practices for API Key Safety
• •OpenAI Security and Compliance
• •OWASP GenAI Security Project