大模型应用面试里，安全边界经常被轻描淡写：提示词里写“不要输出敏感信息”，或者加一句“违法内容拒答”。真实上线后，这远远不够。模型安全不是一段提示词，而是一套后端控制链路。
只要系统会读取用户数据、调用工具、生成建议或影响业务动作，就必须考虑输入、输出、权限、确认和审计。否则模型回答看起来聪明，系统风险却不可控。
输入侧要先做分流
用户输入进来后，系统要先判断请求类型和风险。普通知识问答、文本润色、简历建议、工具执行、数据查询，它们的风险完全不同。低风险请求可以直接进入模型，高风险请求需要权限校验、敏感信息处理或人工确认。
敏感信息也要在输入侧处理。身份证号、手机号、客户信息、合同内容、内部密钥等数据，不应该无条件原样送给模型。能脱敏就脱敏，能摘要就摘要，必须处理完整敏感内容时要有明确授权和日志。
输出侧不能只信模型自觉
模型可能生成不合规建议、泄露上下文里的敏感片段、编造确定结论，或者把不该执行的动作说成已经完成。后端需要对输出做校验：结构是否符合预期，是否包含敏感信息，是否越过权限边界，是否需要加风险提示。
对于工具型 Agent，输出校验尤其关键。模型说“可以取消订单”不代表后端就能取消。真正执行前，还要检查用户身份、订单状态、业务规则和二次确认结果。
拒答要可解释
拒答不是简单说“我不能回答”。如果拒答太生硬，用户体验差；如果拒答太宽松，风险高。更好的方式是区分原因：缺少权限、证据不足、请求涉及敏感操作、需要更多信息、超出系统能力。
比如用户问企业内部资料，系统可以说明当前账号无权访问相关文档；用户要求模型给医疗或法律确定结论，系统可以给一般性信息并建议咨询专业人士；用户要求执行高风险操作，系统应该要求确认或转人工。
审计是上线后的底线
一旦模型参与业务决策，系统就要能回答：谁在什么时间问了什么，系统用了哪些资料，模型给了什么结果，是否调用了工具，最终执行了什么动作。没有审计链，出了问题很难定位，也很难证明系统遵守了权限边界。
审计日志也要注意隐私，不一定保存完整用户输入，但要保存足够复盘的信息。对于高风险动作，最好记录确认过程、参数摘要、执行结果和操作人身份。
面试里可以这样收束
我会把大模型安全放在后端链路里设计，而不是只靠提示词。输入侧做风险分流和脱敏，检索侧做权限过滤，模型输出后做结构和敏感信息校验，高风险动作需要确认，所有关键步骤保留审计。这样安全边界才真正落地，模型能力也才能放心接入业务系统。
安全策略还需要按场景分级。内部助手、公开问答、企业知识库、自动化 Agent 的风险完全不同。公开问答更关注内容合规，企业知识库更关注权限和数据泄露，Agent 更关注真实动作的副作用。把所有场景套同一条拒答规则，往往既影响体验，也挡不住真正风险。
面试里可以把这点说成“分层防护”：低风险内容走轻量校验，高风险数据和动作走严格校验、确认和审计。这样既不过度保守，也不会把安全完全交给模型。