veto-guardrails/veto-core

# the instruction says "keep all professional terms in their original English form", so "gateway" is a professional term, I should keep it in English. But in the examples, "Kubernetes Setup" is translated to "Kubernetes 设置", where "Setup" is translated, but "Kubernetes" is kept. Similarly, here "gateway" might be kept as "gateway". **Veto** 是一个面向 LLM 应用的运行时防护层。它位于你的应用与模型之间，能在毫秒级时间内阻断 PII 泄漏、提示注入、密钥泄露和有害内容。 `veto-core` 是该项目的开源核心：包含网关、正则引擎、ONNX 运行器以及开源模型封装。采用 Apache-2.0 许可证。 ## 项目内容 ``` veto-core/ ├── gateway/ Go service — public /v1/check API, regex hot path → gateway/README.md ├── inference/ Python service — ML classifiers (uv-managed) → inference/README.md ├── scripts/ │ └── test.sh curl smoke-test against a live gateway ├── docker-compose.yml brings up gateway + inference together ├── LICENSE Apache-2.0 └── README.md ← this file ``` 每个子目录都有自己的 README 提供更深入的细节 —— 阅读完本文后可查阅。 ## 架构 ``` ┌──────────────────────────────────────────────┐ │ Customer app / browser │ └─────────────┬─────────────────────────────────┘ │ REST · SDK · proxy ▼ ┌───────────────────────┐ │ veto-gateway (Go) │ │ :8088 │ │ POST /v1/check │ │ · auth (X-Veto-Key) │ │ · regex: PII + secrets│ │ · forwards to ML │ └─────────────┬─────────┘ │ HTTP (gRPC target) ▼ ┌─────────────────────────────┐ │ veto-inference (Python) │ │ :8000 (internal-only) │ │ POST /detect/injection │ │ · prompt-injection ML clf │ └─────────────────────────────┘ ``` 网关是**唯一对外可达的服务**。推理容器仅存在于 Compose 网络中 —— 永不对外发布。 ## 运行技术栈 需要 Docker + Docker Compose v2。 ### 独立模式 (开源，无控制平面) 将 `VETO_STATIC_KEYS` 设置为 `<明文>:<组织ID>:<层级>` 三元组的逗号分隔列表，网关将从该环境变量解析密钥 —— 无需 Redis、无需 `veto-cloud`，除 `inference` 外无其他依赖。 ``` # I need to decide. Let's list all technical terms: KEY=$(printf 'vt_live_'; head -c 32 /dev/urandom | base32 | tr -d '=' | tr '[:upper:]' '[:lower:]') echo "$KEY" # save this — it's your gateway credential VETO_STATIC_KEYS="$KEY:my-org:free" docker compose up -d --build # - veto-core: likely a project name, keep as is. # - plaintext key: technical term, keep "plaintext key" in English? Or translate "key" to "密钥"? In the context, "key" might be translated, but "plaintext" is specific. curl -X POST http://localhost:8088/v1/check \ -H "X-Veto-Key: $KEY" \ -H "Content-Type: application/json" \ -d '{"text":"my email is leak@example.com"}' ``` 静态模式会禁用计量和按组织限速（它们需要 Redis）。按 IP 限速和密钥认证仍然生效。适用于自托管、评估和 CI 冒烟测试。 要“吊销”一个密钥，请使用更新的 `VETO_STATIC_KEYS` 重启网关。 ### 托管模式 (使用 `veto-cloud` 控制平面) 如需多租户、计费、仪表盘和可吊销密钥功能，请将网关与专有的 `veto-cloud` 服务一起运行： ``` docker compose up -d --build # - base32: encoding scheme, keep in English. # - vt_live_: prefix, keep in English. ``` 需要设置 `VETO_CLOUD_URL`、`VETO_CLOUD_INTERNAL_TOKEN` 和 `VETO_REDIS_URL`。云服务实现了 `/internal/v1/keys/lookup` RPC，并将缓存条目写入 Redis 供其使用。参见 `veto-cloud`（私有）或自行实现该合约 —— `config/keycache.go` 文档记录了数据格式。 首次构建会将提示注入模型（约 750 MB）和 torch CPU 轮子下载到推理镜像中。后续构建将使用缓存，几秒钟内即可完成。 要停止： ``` docker compose down ``` ### 端口冲突 如果宿主机的 `:8088` 端口被占用： ``` VETO_HOST_PORT=18088 docker compose up -d --build ``` ## 冒烟测试 ``` # - gateway: common term in networking, often translated as "网关" in Chinese, but since it's specified to keep professional terms in English, I'll keep it as "gateway". But to make it readable, I might translate it. The instruction is ambiguous; it says "keep all professional terms... in their original English form", so for terms like "gateway", if it's considered professional, keep it. # Looking at the example: "Kubernetes Setup" -> "Kubernetes 设置". Here, "Setup" is translated, but "Kubernetes" is kept. So, for compound terms, the proper noun is kept, and common words are translated. VETO_API_KEY=vt_live_… bash scripts/test.sh # Similarly, for "API Reference" -> "API 参考", "API" is kept, "Reference" is translated. VETO_URL=http://localhost:18088 VETO_API_KEY=vt_live_… bash scripts/test.sh ``` 针对 `POST /v1/check` 的 9 次调用矩阵： | 样本 | 预期 `action` | |---|---| | 干净提示 | `allow` | | 邮箱 PII | `redact` | | AWS access-key 泄露 | `block` (严重性高) | | OpenAI API-key 泄露 | `block` | | 法国 IBAN | `block` (严重性高) | | 提示注入 ("忽略所有先前的指令…") | `block` (通过 ML 分类器) | | 多重发现 (邮箱 + IBAN + 注入) | `block` | | 对包含密钥的负载设置 `categories: ["pii"]` 覆盖 | 仅 `redact` | 可通过 `| jq .` 管道输出以美化打印，或者在 `scripts/test.sh` 文件顶部注释掉该行（如果你没有 jq）。 ## 环境变量 | 变量名 | 默认值 | 所属服务 | 用途 | |---|---|---|---| | `VETO_STATIC_KEYS` | — | gateway | 独立模式 —— `key:org:tier` 三元组（逗号分隔）。设置后，网关将跳过 Redis + 云查询。 | | `VETO_REDIS_URL` | — (托管模式必填) | gateway | 热路径密钥缓存 + 计量流 + 按组织限速。静态模式下为可选。 | | `VETO_CLOUD_URL` | — (托管模式必填) | gateway | 缓存未命中时进行密钥查询的控制平面基础 URL。静态模式下未使用。 | | `VETO_CLOUD_INTERNAL_TOKEN` | — (托管模式必填) | gateway | 内部云 RPC 的 Bearer 令牌。静态模式下未使用。 | | `VETO_HOST_PORT` | `8088` | compose | 宿主机侧用于网关的端口 | | `VETO_INFERENCE_URL` | `http://inference:8000` | gateway | ML 分类器的基础 URL | | `VETO_INJECTION_MODEL` | `protectai/deberta-v3-base-prompt-injection-v2` | inference | HuggingFace 模型 ID | | `VETO_MAX_LEN` | `512` | inference | 分词器最大长度 | | `HF_HOME` | `/models` | inference | HuggingFace 缓存（在构建时烘焙到镜像中） | API 密钥（从仪表盘生成的真实 `vt_live_…` 密钥）由调用方通过 `X-Veto-Key` 请求头发送，且从不记录日志。 ## **尚未**实现的功能 此仓库是原型版本。路线图中尚未落地的项目包括： - **Hyperscan** 多模式正则表达式（目前仅使用 RE2 标准库）。 - **基于 Redis 的按组织限速 + 计量。** 客户密钥认证已接线（Redis + 云 RPC + argon2id，进程内 LRU 缓存）；限速目前仍仅基于 IP，且计量事件尚未发出。 - **流式防护** —— `/v1/check` 目前仅支持请求/响应模式。 - **代理模式** —— 为 OpenAI/Anthropic 等服务实现 `base_url` 透明替换转发。 - **gRPC** 网关↔推理服务通信（目前使用 HTTP/JSON）。 - **ONNX Runtime + INT8** 推理。目前仅使用 PyTorch 的急切模式。 - **GLiNER + Presidio NER** 以提供更丰富的 PII 覆盖。 - **有害内容分类器。** - **`veto-injector-v2`**（蒸馏的自有模型）。 - 用于本地部署的 **Helm chart 骨架**。 - **Python + TypeScript SDK**。 - **OpenTelemetry** 集成。目前仅有标准输出日志记录。 高级的 **Veto Fused** 模型和多租户控制平面（计费、审计链、仪表盘）位于私有仓库中，不属于 `veto-core` 的一部分。 ## 许可证 Apache-2.0。详见 [`LICENSE`](./LICENSE)。

标签：AI安全, Apache许可证, Apex, Chat Copilot, CNCF毕业项目, Docker容器, EVTX分析, Go语言, Linux系统监控, ONNX模型, PII保护, Python语言, RESTful API, 实时防护, 应用层安全, 推理服务, 提示注入防护, 提示词优化, 攻击面发现, 数据泄露防护, 数据隔离, 日志审计, 机器学习, 模型安全, 版权保护, 秘密管理, 程序破解, 网关服务, 网络安全防护, 网络探测, 请求拦截, 逆向工具