Aishwarya-G-M/secure-llm-gateway

# Secure LLM Gateway — 工程 README Secure LLM Gateway 是一个基于 FastAPI 的代理，它会检查 prompt 和模型响应，应用安全策略，并拦截或净化不安全的交互，从而降低 OWASP 类型的 LLM 风险。 ## 概述 该服务被设计为位于 LLM 客户端前方的控制层，而不是一个简单的透传 API。其核心理念是：用户输入和模型输出都属于攻击面，因此 gateway 必须在将响应返回给调用方之前，对其进行验证、检查并执行策略。 本文档重点介绍架构演进、设计选择以及系统当前形态背后的逻辑。这里使用了 Mermaid 图表，因为 GitHub Markdown 原生支持 Mermaid 代码块，这使得架构图在仓库文档中具有良好的可读性和可维护性。[1][2] ## 当前端点形态 | 端点 | 用途 | |---------|---------| | `GET /` | 基础的根/存活探测响应。 | | `GET /health` | 运维健康响应，包含运行时间、应用版本、prompt 版本以及 inspector 的就绪状态。 | | `GET /metrics` | 用于 gateway 可观测性的指标端点。 | | `POST /chat` | 主要的安全 gateway 执行路径。 | ## 设计目标 - 在客户端和模型调用路径之间设立安全控制点。 - 将 prompt 输入和模型输出均视为可检查的攻击面。 - 保持策略逻辑的外部化和可演进性，而不是永久硬编码。 - 通过健康检查、指标和结构化决策支持系统的运维可见性。 - 保持系统的高可扩展性，以便在最小化破坏的前提下替换 LLM 客户端和 AI 防护层。 ## 架构演进 理解该系统的一个有效方式是将其视为一系列深思熟虑的架构升级。将架构记录为“初始状态+后续演进”是一种推荐的文档编写模式，因为它不仅解释了系统现在的样子，还说明了当前设计是如何形成的。[3][4] ### 阶段 1 — 模型调用前的硬编码规则检查 第一个版本在将请求发送给 LLM 客户端之前，使用了硬编码的规则检查层（主要是基于 regex 的检查）。其流程简单实用：检查输入，如果允许则调用模型，并将模型响应返回给调用方。 ``` flowchart LR A[Caller] --> B[Gateway API] B --> C[Hard-coded Rule Inspector] C -->|Allow| D[LLM Client] C -->|Block| E[Blocked Response] D --> F[LLM Provider] F --> G[Model Output] G --> H[Return Response to Caller] ``` #### 为什么这种设计是合理的 这是从空白仓库到一个具备实际意义的安全 MVP 的最快路径。它尽早确立了核心产品理念：模型不应被直接暴露，请求必须首先经过安全决策层。 #### 局限性 - 不修改代码，规则就难以演进。 - 检查主要侧重于请求输入。 - 对于一个注重安全的 gateway 来说，对输出的处理过于信任。 ### 阶段 2 — 针对

标签：AI网关, API安全, AV绕过, FastAPI, JSON输出, 代理服务, 内容审查, 知识图谱, 逆向工具