Guarded MCP Gateway · 线上可体验 · 免注册 · 双域真库验证过（Twenty 线上）

给 Agent 接内部系统,
先加一道守卫网关

一层协议级(MCP)、与 agent 框架无关的守卫网关——所有入口共用同一套守卫,HR/CRM 等系统即插即用。角色定工具面、行级过滤、字段脱敏、逐调用审计:不该看到的工具连 tools/list 都不出现,不是模型忍住不说,是数据根本没进上下文。

4 道控制

工具白名单 · 行级/脱敏 · 人工审批 · 签名审计

100 · 11 类

越权/泄漏评测题 · 跨 3 个域

2 真后端

Twenty 线上 · OrangeHRM 5.7 曾本地实测（现走 fixture）

0.00

×3 重复通过率标准差(百分点)· 无摇摆题

同一个网关 · 同一句提问:「张三的工资是多少?」

tools/list · 该身份可见的工具面

张三的工资是多少?

audit/foundry.jsonl ← 本次调用已留痕(参数只记哈希)

线上体验(免注册): CRM 助手 ↗ Twenty 后台 ↗ LangGraph 前端 · 真 Twenty 数据

为什么做

三个事故 → 三个能力

安全不靠提示词自觉——结构化规则在守卫层强制执行。

事故:员工顺嘴一问,拿到同事工资

角色 → 工具白名单

不该用的工具在 tools/list 里根本不出现,而不是调用被拒后再解释。

事故:模型把手机号、薪资整行吐进回答

行级过滤 + 字段脱敏

结构化规则在守卫出口强制执行;越权数据不进上下文,模型想编也没材料。

事故:出事后翻不出谁问过什么

逐调用审计流水

每次调用一条 JSONL;只记参数哈希不记原文,审计日志不成为第二个泄漏面。

人工审批 · Human-in-the-loop

动钱、改库这类高危写,先过人的点头

行级过滤拦得住泄漏,拦不住已经发生的写。涉审写操作在执行前被挂起成审批单,独立审批人批准后才落库——审批必须在写入之前。

Guard 管线 · 审批闸门在 execute 之前

1角色查找 → 工具白名单

2写前归属校验(preimage)越权即 row_denied

3审批闸门pending · 无 data

4adapter.execute(人批准后)一单一次

5行级过滤 → 字段脱敏 → 审计

独立审批人,不能自批

发起人(sales_rep)与审批人(sales_manager,approver:true)分离;RBAC 只标谁能批(approver:true),而「发起人不能批自己的单」是网关代码级硬校验(userId 比对)。

闸门在写入之前

挂起发生在 adapter.execute 之前——行级过滤拦得住读的泄漏,拦不住已经落库的写。审批必须在写入发生前。

一单一次,防重放

批准后同参调用重试即消票执行;审批单一次性核销,重复提交不再触发第二次写入。

拒答/挂起分支无 data

pending 与 refusal 在类型层就没有 data 字段,结构上不可能夹带业务数据或模型自由文本。

issue_refund policy-as-code 按金额与账期信号分档

金额 ≤ ¥500 · 本月 < 2 笔

自动放行

金额 > ¥500

挂起等经理批

本月已退 ≥ 2 笔(第 3 笔起)

挂起等经理批

订单号 / 邮箱 / 卡尾号不符

直接拒

归属约束叠加:只退自己名下订单,越权退款在审批前就 row_denied。金额缺失/非数值一律判「需审批」(fail-closed)。

架构

所有入口,同一套守卫

MCP 客户端

LangGraph / Claude Code / 任意 Streamable HTTP host · Bearer 签名令牌

飞书 bot

长连接 · open_id → principal · 工具面按身份收窄

▼

Guard 管线 · packages/core

角色查找 → 工具白名单 → 审批闸门（写前挂起） → 行级过滤 → 字段脱敏 → 审计 JSONL

▼

orangehrm

HR · 真实 5.7 已验

twenty

CRM · 真实 REST 已上线

memory

跨会话记忆 · 域内 RBAC

工具面在 LLM 看到之前就收窄

员工的工具定义里根本没有 get_salary;拒答是结构化分支,结构上不可能夹带业务数据。

角色不跨域

HR 的通配权力跨不进 CRM,销售看不到全员业绩盘——业务全权 ≠ 跨域全权。

生产级签名身份

HS256 共享密钥或 JWKS 非对称(ES256/RS256)+ 热轮换;伪造头不是被拒绝,是根本不在信任路径上。线上实例现跑 JWKS URL 模式。

两分钟本地验证

fixture 模式无需任何密钥:pnpm install 后换身份问同一个问题,行为不同——这正是卖点。

飞书机器人

自然语言进,按身份收窄的工具面出

长连接接入,无需公网回调。sender open_id 映射到 principal,同一套守卫——安全不靠提示词。三个域已在真实飞书应用上端到端验证。

Foundry 助手

工具面在 LLM 看到之前收窄

GLM tool-calling 循环拿到的工具定义已按身份过滤——员工的定义里根本没有 get_salary。

越权数据在出口就不存在

refusal 分支无 data 字段,模型想编也没材料;拒答如实转述「已记入审计」。

跨域实测零泄漏

sales_rep 跨域问工资零泄漏;hr_admin 反向无任何 CRM 能力——业务全权 ≠ 跨域全权。

身份源可信

sender open_id 由飞书服务端签发,经 identity.feishu.yaml 映射到 principal,全程留审计。

评测

守卫的价值是分数差,不是一句「我们有 RBAC」

100 题越权/泄漏题库跨三个域(含对抗红队与退款分级),硬断言 + LLM-judge 双轨(judge 须先过人工校准,只能加严不能翻案)。头条:红队攻击得手率无守卫 77.2% → 生产配置 0%,所有数据可本机复现。

100

题 × 11 类,跨三个域
HR 29 · 记忆 20 · CRM 51

100%

全开配置全绿
fixture 常测 · 真后端曾实测

0.00

×3 重复通过率标准差
(百分点) · 无摇摆题

77→0%

红队攻击得手率
无守卫 → 生产配置(0 题泄漏)

守卫逐层 Ablation(100 题;分层贡献与后端实现无关)

同一套题在四档守卫配置下各跑一遍——每一层的贡献是可测的:

全关（无守卫）

48.0%

仅角色+工具白名单

64.0%

白名单+行级过滤

95.0%

全开（生产配置）

100.0%

泄漏题数:47 → 28 → 5 → 0(攻击得手率 77.2% → 0%)。工具白名单先砍一截(红队拦截 22.8% → 50.9%);行级过滤是拦截主力(→ 98.2%);字段脱敏把「白名单+行级」档残留的 5 条脱敏泄漏清零(→ 100%)。

judge 不过校准线不上岗

对人工标注 golden 集一致率 ≥90% 才允许进报告;换模型 = 重新过校准。judge 只能把通过的题追加判失败,不能翻案救回。

双轨的价值在发现,不在分数

judge 上岗第一轮就抓到一个硬断言看不见的出口污染(ZodError 原样透传),修复后沉淀为确定性回归断言。

CI 门禁只信硬断言

红队题任何一道失败,CI 退出码 1;LLM-judge 有成本且依赖外部 API,不进门禁。

本机复现(无需密钥)

pnpm --filter @yiong/foundry-eval run eval \
  --repeat 3 --ablation

标准映射

每道控制,对标 2026 的公开威胁框架

守卫不试图「检测」提示注入——那是打不赢的仗;它让注入「没有后果」。以下把每道控制映射到 OWASP 与中国 TC260 的逐条编号。

控制

拦住什么攻击

框架编号

工具白名单

越权工具调用(员工查薪资、销售摸全员业绩盘)

OWASP ASI02LLM06TC260 最小权限

行级过滤

越权读取他人的行(投毒备注指示"导出全部联系人")

LLM01LLM02ASI02

字段脱敏

敏感字段泄露(电话、工资整行吐进回答)

LLM02

写前归属校验

越权改删同事的行 / 伪造归属新建(归属由 principal 盖戳)

ASI03

审批闸门

高危写未经人批就落库(改/删/改阶段)

ASI09LLM06TC260 二次确认

分级审批

大额 / 频繁退款自动放行("动钱"类动作)

ASI09TC260 资金二次确认

签名令牌

冒充身份 · alg:none 降级(不读令牌自述 alg)

ASI03

签名审计链

事后抵赖 / 篡改审计(可选 Ed25519 签名链,公钥离线复核;默认明文 JSONL)

ASI10 可追溯TC260 全量审计

框架:OWASP Top 10 for Agentic Apps 2026(ASI02/03/09/10)· OWASP LLM Top 10 2025(LLM01/02/06)· 中国 TC260《AI 智能体安全部署使用指南》(2026-07 生效:最小权限 / 高危操作人工二次确认 / 全量审计)。设计对标 lethal trifecta(Willison)与 Meta「Agents Rule of Two」的 [AB] 档(对外动作前人类校验)。EU AI Act Art.14 高风险人工监督已推迟至 2027–2028,本项目 HITL 只作中期顺风、不宣称现在受其强制。

诚实边界

说清楚验证了什么、没验证什么

安全产品最怕过度承诺。以下边界与 README 保持同步:

✓两条真库链路都已验证:HR 对真实 OrangeHRM 5.7(只读 MySQL,本地 docker;docker 已下线,prod 走 fixture),CRM 对真实 Twenty(REST + Bearer,线上)——都是演示数据口径,不是生产规模

✓线上 CRM 域连的是真实 Twenty(crm.yiongspace.com 读写真数据);HR 域线上仍走 fixture

✓体验链接的身份是配好的,不是登录来的——演示「同一网关、不同身份、行为不同」,不是登录系统

✓行级/字段规则只在 Guard 出口生效;绕过 Foundry 直连源系统管不到——源系统凭据只发给 Foundry

✓JWKS URL 模式默认可用性优先:端点持续故障期间吊销不生效,fail-closed 需自行开启 max-stale

✓ERP 仍是路线图;「多签发方」是能力,线上是单签发方口径

路线图

11 项里程碑:8 项已交付 · 3 项规划中

每一项「已交付」都附带可复现的验证口径。

已落地

HR 域 + Guard 管线真库已验

角色白名单 / 行级过滤 / 字段脱敏 / 审计 JSONL；对真实 OrangeHRM 5.7 只读 MySQL 全绿。

记忆域（跨会话，域内 RBAC）

越权召回走行级规则兜底；投毒防线是接口级——save_memory 根本没有 employee_id 参数。

CRM 域（twenty 适配器，已上公网）2026-07

同一套用例 schema 换适配器即全绿；线上网关连真实 Twenty（REST + Bearer），角色不跨域。

签名身份：HS256 → JWKS → URL 拉取线上已切

ES256/RS256 多签发方 + 热轮换；线上实例现跑 JWKS URL 模式，私钥永不落服务器。

飞书 bot 三域端到端 + LangGraph 公网2026-07

真实飞书应用实测脱敏/拒答/审计；自建 LangGraph 前端上公网，连真实 Twenty，免注册可试。

对抗红队评测 + 攻击得手率指标2026-07

被劫持的 agent 试图伪造归属/越权改删/导出他人数据——红队攻击得手率无守卫 77.2% → 生产配置 0%，由 ablation 跑出。

防篡改审计（Ed25519 签名哈希链）可选开启

每条审计带 hash 链 + 签名：改一条断整链、伪造验签不过，校验只需公钥、可离线复核（verify-audit）。

退款分级动作 + 威胁模型2026-07

审批闸门升级为分级放行（policy-as-code）：小额自动、超额/频繁挂起、身份核验前置。控制到 OWASP ASI/LLM + TC260 的逐条映射。

规划中

ERP 适配器

第三个业务域——检验 SystemAdapter 抽象在财务形状数据上的迁移成本。

第三方红队

现状是出题人和被评人同仓同评审；引入外部对抗测试补上这个口径。

独立签发方（SSO/IdP）

线上现为单签发方口径（签发方=部署方同机）；接真实 SSO 验证多签发方与轮换纪律。

Guarded MCP Gateway · live demo · no signup · two real backends verified (Twenty live)

Put a guarded MCP gateway in front of
your internal systems

One protocol-level (MCP), framework-agnostic guard layer — every entrypoint shares the same guard; HR, CRM and any system plug in. Role-scoped tools, row-level filtering, field masking, per-call audit: off-limits tools never appear in tools/list at all — it's not the model holding back; the data never enters the context.

4 controls

whitelist · row/field · human approval · signed audit

100 · 11 cat

leak/privilege eval cases · across 3 domains

2 real backends

Twenty (live) · OrangeHRM 5.7 (verified, now fixture)

0.00

std-dev over ×3 repeats (pts) · no flaky cases

Same gateway · same question: "What is Zhang San's salary?"

tools/list · surface for this identity

What is Zhang San's salary?

audit/foundry.jsonl ← this call was logged (params stored as hashes)

Live (no signup): CRM assistant ↗ Twenty admin ↗ LangGraph frontend · real Twenty data

why

Three incidents → three capabilities

Safety doesn't rely on prompt discipline — structured rules are enforced at the guard layer.

Incident: a casual question returns a coworker's salary

Role → tool whitelist

Off-limits tools never appear in tools/list — instead of rejecting the call and explaining afterwards.

Incident: the model dumps whole rows — phones, salaries — into answers

Row filtering + field masking

Enforced at the guard's exit; unauthorized data never enters the context, so there's nothing to leak.

Incident: afterwards, no one can tell who asked what, when

Per-call audit trail

One JSONL line per call; params stored as hashes, never raw — the audit log doesn't become a second leak surface.

Human-in-the-loop

Money and mutations wait for a human's nod

Row filtering stops leaks, not writes that already happened. Approval-gated writes are suspended as a ticket before execution; only an independent approver's sign-off commits them — approval must precede the write.

Guard pipeline · the gate sits before execute

1role lookup → tool whitelist

2preimage ownership checkelse row_denied

3approval gatepending · no data

4adapter.execute (after approval)one ticket, once

5row filter → mask → audit

Independent approver, no self-approve

The requester (sales_rep) and approver (sales_manager, approver:true) are separate; RBAC only marks who may approve (approver:true); the no-self-approve rule itself is a hardcoded gateway check (userId comparison).

The gate sits before the write

Suspension happens before adapter.execute — row filtering stops read leaks, not writes already committed. Approval must precede the write.

One ticket, once — replay-safe

After approval, retrying the same call consumes the ticket and executes; the ticket is single-use, so resubmits never fire a second write.

Refusal/pending carry no data

pending and refusal branches have no data field at the type level — structurally incapable of smuggling business data or model free-text.

issue_refund policy-as-code tiered by amount & account signals

amount ≤ ¥500 · < 2 this month

auto-approve

amount > ¥500

hold for manager

≥ 2 refunds this month (3rd+)

hold for manager

order / email / card tail mismatch

reject

Ownership stacked on top: refunds only for your own orders — an out-of-scope refund is row_denied before approval. Missing/non-numeric amounts always resolve to "needs approval" (fail-closed).

architecture

Every entry point, one guard pipeline

MCP clients

LangGraph / Claude Code / any Streamable HTTP host · Bearer signed tokens

Feishu bot

long connection · open_id → principal · identity-scoped tools

▼

Guard pipeline · packages/core

role lookup → tool whitelist → row filter → field masking → audit JSONL

▼

orangehrm

HR · real 5.7 verified

twenty

CRM · real REST, live

memory

cross-session · in-domain RBAC

The tool surface narrows before the LLM sees it

An employee's tool definitions simply don't include get_salary; refusals are a structured branch that can't carry business data.

Roles don't cross domains

HR's wildcard power stops at the HR domain; a sales rep can't see the team pipeline — full power in one domain ≠ power everywhere.

Production-grade signed identity

HS256 shared secret or asymmetric JWKS (ES256/RS256) with hot rotation; a forged header isn't "rejected" — it's never on the trust path. The live instance runs JWKS URL mode.

Verify locally in two minutes

Fixture mode, no secrets: ask the same question as different identities and watch the behavior change — that's the whole point.

Feishu bot

Natural language in, identity-scoped tools out

Long-connection integration, no public callback. Sender open_id maps to a principal behind the same guard — safety never relies on prompts. All three domains verified end-to-end on a real Feishu app.

Foundry Assistant

Tool surface narrows before the LLM sees it

The GLM tool-calling loop receives identity-filtered tool definitions — an employee's set simply has no get_salary.

Unauthorized data never exists at the exit

The refusal branch has no data field — nothing to fabricate from; refusals honestly report "logged to audit".

Zero cross-domain leaks, tested live

sales_rep asking about salaries leaks nothing; hr_admin has no CRM capability at all — domain power doesn't travel.

Trusted identity source

Sender open_id is issued by Feishu's servers, mapped via identity.feishu.yaml to a principal; everything is audited.

evals

A guard's value is a score gap, not "we have RBAC"

100 leak/privilege cases across three domains (incl. adversarial red-team + graded refunds); hard assertions + LLM-judge dual track. Headline: red-team attack success 77.2% (no guard) → 0% (production). All numbers reproducible locally.

100

cases × 11 categories, 3 domains
HR 29 · memory 20 · CRM 51

100%

green with guards fully on
fixture (CI) · real backends verified

0.00

std-dev over ×3 repeats (pts)
no flaky cases

77→0%

red-team attack success
no guard → production (0 leaks)

Per-layer guard ablation (100 cases; layer contribution is backend-independent)

The same suite under four guard configurations — each layer's contribution is measurable:

all off (no guard)

48.0%

role + whitelist only

64.0%

+ row filtering

95.0%

all on (production)

100.0%

Leaks: 47 → 28 → 5 → 0 (attack success 77.2% → 0%). The whitelist cuts a first slice (red-team block 22.8% → 50.9%); row filtering is the main blocker (→ 98.2%); field masking clears the 5 masking leaks left at "whitelist + rows" (→ 100%).

No calibration pass, no judge

≥90% agreement with a human-labeled golden set before a judge enters reports; new model = recalibrate. The judge can only add failures, never rescue them.

The dual track's value is discovery, not scores

On its first run the judge caught exit contamination invisible to hard assertions (a raw ZodError passthrough); the fix became a deterministic regression assertion.

The CI gate trusts hard assertions only

Any failed red-team case → CI exit 1; the LLM-judge costs money and depends on external APIs, so it stays out of the gate.

reproduce locally (no secrets)

pnpm --filter @yiong/foundry-eval run eval \
  --repeat 3 --ablation

standards

Every control, mapped to 2026's public threat frameworks

The guard doesn't try to "detect" prompt injection — an unwinnable fight; it makes injection consequence-free. Each control maps to specific OWASP and China TC260 clauses.

control

what it stops

frameworks

Tool whitelist

Unauthorized tool calls (employee reads salary, sales peeks at the pipeline)

OWASP ASI02LLM06TC260 least-priv

Row filtering

Reading others' rows (poisoned note: "export all contacts")

LLM01LLM02ASI02

Field masking

Sensitive fields leaking (phone/salary rows dumped into answers)

LLM02

Preimage ownership

Editing/deleting a colleague's row / forged-owner create (owner stamped by principal)

ASI03

Approval gate

High-risk writes committed without a human (edit/delete/stage)

ASI09LLM06TC260 2nd-check

Tiered approval

Large/frequent refunds auto-approved (money actions)

ASI09TC260 fund 2nd-check

Signed tokens

Identity spoofing · alg:none downgrade (token-stated alg is never read)

ASI03

Signed audit chain

Repudiation / audit tampering (opt-in Ed25519 signed chain; plaintext JSONL by default)

ASI10 traceTC260 full audit

Frameworks: OWASP Top 10 for Agentic Apps 2026 (ASI02/03/09/10) · OWASP LLM Top 10 2025 (LLM01/02/06) · China TC260 AI-Agent Security Guide (in force 2026-07: least privilege / human 2nd-check for high-risk actions / full audit). Design tracks the lethal trifecta (Willison) and Meta's "Agents Rule of Two" [AB] tier (human validates before outbound actions). EU AI Act Art.14 human oversight is deferred to 2027–2028; this project's HITL is a mid-term tailwind, not claimed as currently mandated.

honest limits

What was verified — and what wasn't

Overpromising is the worst failure mode for a security product. These limits stay in sync with the README:

✓both real backends verified: HR against real OrangeHRM 5.7 (read-only MySQL, local docker; docker retired, prod runs fixture), CRM against real Twenty (REST + Bearer, live) — demo-scale data, not production scale

✓The live CRM domain runs real Twenty (crm.yiongspace.com reads/writes real data); the HR domain stays on fixture online

✓Demo identities are pre-configured, not logged in — it demonstrates "same gateway, different identity, different behavior", not a login system

✓Row/field rules apply only at the guard's exit; bypassing Foundry to hit the source system directly is out of scope — source credentials go to Foundry only

✓JWKS URL mode defaults to availability-first: during a prolonged endpoint outage revocation doesn't take effect; fail-closed requires opting into max-stale

✓ERP is still roadmap; "multi-issuer" is a capability — the live deployment is single-issuer

roadmap

11 milestones: 8 shipped · 3 planned

Every shipped item carries a reproducible verification story.

shipped

HR domain + Guard pipelinereal DB verified

Role whitelist / row filtering / field masking / audit JSONL; green against real OrangeHRM 5.7 over read-only MySQL.

Memory domain (cross-session, in-domain RBAC)

Unauthorized recall blocked by row rules; poisoning defended at the interface — save_memory has no employee_id parameter at all.

CRM domain (twenty adapter, now public)2026-07

Same case schema green after just swapping the adapter; the live gateway talks to real Twenty (REST + Bearer). Roles never cross domains.

Signed identity: HS256 → JWKS → URL fetchlive

ES256/RS256 multi-issuer with hot rotation; the live instance runs JWKS URL mode — private keys never touch the server.

Feishu bot ×3 domains + LangGraph public2026-07

Masking / refusals / audit tested on a real Feishu app; a self-built LangGraph frontend is live against real Twenty, no signup.

Adversarial red-team eval + attack-success metric2026-07

A hijacked agent attempts forged ownership / cross-owner writes / exfil — red-team attack success 77.2% (no guard) → 0% (production), measured via ablation.

Tamper-evident audit (Ed25519 hash chain)opt-in

Each record hash-chained + signed: alter one and the chain breaks, forge one and the signature fails; verification needs only the public key, offline (verify-audit).

Graded refund action + threat model2026-07

The approval gate becomes graded (policy-as-code): small auto, large/frequent held, identity check up front. Per-control mapping to OWASP ASI/LLM + TC260.

planned

ERP adapter

A third business domain — testing the SystemAdapter abstraction against finance-shaped data.

Third-party red team

Today the case authors and the code authors are the same people; external adversarial testing closes that gap.

Independent issuer (SSO/IdP)

The live deployment is single-issuer (issuer = deployer, same box); wiring a real SSO validates multi-issuer and rotation discipline.