企業 Agent 平台需要認知中介與 Trust Gateway 分隔思考和操作

The question security teams keep asking

Most teams moving agents from demo to production now have a reasonable answer for cognitive ingress: routing prompts across providers, fallbacks, token budgets. Tools like LiteLLM cover this well. Orchestration (planning loops, multi-agent graphs) is also moving fast.

The question that stalls deployments is on the other side:

How does an agent act on a production database, an ERP or an internal API without holding ambient credentials?

The common pattern today is a service-account token plus a raw function schema. That mixes up two things: what the model wants to do, and what the system allows. We think they should be separate planes.

A four-role map

We find it easier to reason about an agent platform by role than by component. Four roles, one level of abstraction:

ORCHESTRATOR            goals, sub-tasks, SLAs
      |
WORKER                  reasoning + observation loops
      |                              |
      | thinking                     | acting
      v                              v
COGNITIVE BROKER        TRUST GATEWAY + EXECUTOR
model access            decides, then executes
      |                              |
      v                              v
LLM providers           Databases, ERPs, APIs

The two roles at the bottom are parallel paths, not a stack. A worker talks to both: one to think, one to act.

Orchestrator. Plans and delegates work to workers. It takes no position on how the work is done, and this post takes no position on which orchestrator you use.
Worker. A domain agent (support, billing, incident response). It reasons and observes. It holds no LLM provider keys and no credentials to enterprise systems.
Cognitive broker. The only path from a worker to a model. It handles routing, fallbacks and token budgets, and it holds the provider keys so workers don't. It has no access to internal systems. This is the ingress side, and it is well covered by existing tools.
Trust Gateway + executor. The only path from agent intent to enterprise systems. It is one role made of two parts: the gateway decides whether an action is allowed, and the executor carries it out, after verifying the gateway's decision itself. Only the executor ever touches the backing system, with credentials the agent never sees.

A caveat on the word "egress": the cognitive broker also sends business data out, to the LLM provider. Data leakage through prompts is a real egress problem, handled by DLP at the broker or by choosing where models run. The Trust Gateway is about actions, not about prompt content.

A dependency that is not in the diagram: identity. Each worker needs to prove who it is, and each request needs to be attributable to a user or an orchestrator. Whether that is enough for an agent acting on behalf of a user is the subject of our next post.

Propose, decide, verify

The principle: agents propose, the gateway decides, the executor verifies.

Propose. The worker submits a proposal: a tool name and arguments.
Decide (gateway). The gateway evaluates the proposal against deterministic policy: caps, allow-lists, argument validation.
Decide (gateway). A second check looks at semantics: is data being exfiltrated, is an argument suspicious. It is LLM-based, so it is advisory evidence, not a proof.
Decide (gateway). High-risk actions can require a human approval.
Grant (gateway). If allowed, the gateway issues a signed, single-use grant, short-lived and bound to a hash of the exact inputs.
Verify and execute (executor). The executor, which belongs to the same role as the gateway but runs separately, checks the grant signature and the input hash on its own. Only then does it call the enterprise system, using credentials the agent never sees.

Because the grant is bound to the input hash, an approved $100 refund cannot be replayed as a $5,000 one. And because the executor verifies instead of trusting the network path, a request that merely looks internal gets nowhere without a valid grant.

An example (illustrative)

An agent proposes:

{
  "tool": "refund.process",
  "args": { "order_id": "A-1042", "amount": 5000, "currency": "EUR" }
}

The delegation for this user caps refunds at 1,000 EUR. The gateway denies:

{
  "decision": "deny",
  "reason": "amount 5000 exceeds delegated cap 1000",
  "escalation": "human_approval_available"
}

The agent never saw a database credential. The denial is deterministic and logged. If a human approves a higher amount, the grant that comes back is valid for those exact arguments only.

From tools to certified skills

Two words need a clear definition here, because we use both:

A tool is a single callable operation, for example refund.process. It has a name, an input schema and an output schema.
A skill is a tool (or a small set of related tools) packaged for the whole company: schema, deterministic guardrails and a sandboxed executor, published once and certified by the domain team that owns it.

Today, each team that builds an agent writes its own connectors: a PostgreSQL wrapper here, a Jira or SAP wrapper there, each with its own ambient token and its own blind spots. The Trust Gateway turns those into shared, auditable skills. A domain team publishes a skill once. Any worker agent in the company can then propose calls against its tools, but no agent ever gets network or credential access to the backing service.

The mechanics (schema, guardrails, sandboxed execution, grants) exist, and so does discovery: a worker asks the gateway which tools are available to it and gets those active for its tenant. The part that does not exist yet is the catalog around them: publishing workflow, certification, versioning across teams. That is the hard organizational part, covered below.

Is this just an API gateway plus a policy engine?

Fair question. API gateways, MCP gateways, OPA/Cedar and OAuth token exchange all solve parts of this, and you can build a version of this role from them. The differences we care about:

Grants bound to inputs and single-use, rather than scopes that authorize a class of calls.
The executor verifies, not just the gateway. The execution side does not trust the network path, or assume the caller is legitimate just because the request originated internally.
Agent-aware flow: proposals, escalation to humans and semantic checks in one decision path.

If your needs are met by what you already run, use it. We would like to hear where our claims don't hold.

What this does not solve

Intent. If an agent is prompt-injected into a legitimate, in-scope but harmful action, the gateway limits the blast radius. It does not detect bad intent. The semantic check helps but is not a guarantee, and reliable intent detection remains an open problem.
Prompt-level guards are soft. Instructions injected into a model's prompt, such as tenant-specific DLP rules, reduce leaks, but a model can be talked out of its instructions. The hard boundary is the gateway, not the prompt.
Poisoned results. Tool results flow back into the agent's context. Output filtering is partial today.
The skill catalog problem. Central certification gives governance, but also a bottleneck: who certifies, how are versions and supply chain handled, what happens when every team wants a new skill? The sandbox and schema mechanics are there; the organizational process is yours to design.
Key custody and the worker's own credential. Today the worker authenticates to the gateway with an API key and a tenant ID. That key never reaches your backing systems, but it is still a credential: if stolen, an attacker can propose calls as that worker, within policy. Having agents sign each proposal with short-lived keys delegated from a human or orchestrator is the attractive fix, but where those keys live and how a compromised agent is contained is an open design question.
Availability. A single chokepoint needs HA, latency budgets and a clear fail-closed vs. fail-open decision per tool.
Revocation across a delegation chain, mid-flight.

How Lianxi implements this

The sections above are meant to hold for any implementation. This one describes ours, and what is real today.

Status legend, as in our earlier posts: 🟢 implemented and open source · 🟡 implemented but private · ⚪ design goal, not built yet.

Cognitive broker. 🟡 Stateless mode keeps no conversation state. In stateful mode (response chaining) it stores conversation context, which can contain business data, so treat that store as sensitive.

Worker. 🟡 In our reference worker, three invariants are enforced in code: no LLM provider keys (all reasoning goes through the broker), no local shell or private database access (every side effect goes through the Trust Gateway), and cryptographic proof of identity on every inbound request. The worker does hold one credential: its API key and tenant ID for the gateway. For cross-tenant callers, it injects tenant-specific DLP rules into the model's prompt. Task state is in memory, so in-flight tasks are lost on restart.

Orchestrator. ⚪ We don't build one. Our worker accepts A2A tasks from an orchestrator or a peer agent, authenticated with a signed token.

Identity. 🟡 The worker verifies its caller with OAuth2 client-credential tokens checked against a JWKS endpoint, or with Ed25519-signed session tokens bound to a DID. The gateway resolves each tenant's issuer dynamically instead of from a static list.

Trust Gateway.

🟢 Proposals arrive as an MCP tools/call, authenticated with a gateway API key and a tenant ID.
🟢 Deterministic policy covers caps, allow-lists and argument validation.
🟢 The semantic check is LLM-based and advisory.
🟢 High-risk actions can require human approval.
🟢 Grants are Ed25519-signed and single-use, with a 30-second TTL, replay protection and a binding to a hash of the exact inputs.

Executor. 🟢 It runs in a Wasm sandbox, co-located with either the gateway or the target service. It verifies the grant signature and input hash itself, then dispatches against the enterprise core with credentials the agent never sees.

Skills. 🟢 Schema, guardrails, sandboxed execution, grants, and discovery through MCP tools/list, which returns the bundles active for the worker's tenant. ⚪ Catalog, publishing workflow, certification and cross-team versioning.

Output filtering and revocation. 🟡 Output filtering is partial. ⚪ Mid-flight revocation across a delegation chain is not built. ⚪ Per-proposal signing with short-lived delegated keys is not built.

This builds on our earlier post on why the company agent should not be just a back-end channel. Article about Personal Agent Protocol

Why we're sharing this

Agents rarely fail in production because the model can't reason. They fail because nobody can sign off on giving a non-deterministic system write access to critical systems. We think separating thinking from acting, and making the acting side verifiable, is the practical path.

Code: github.com/fcn06/trust_gateway.

Question for you: if you run agents against production today, what stops a confidently wrong tool call? Where would this design break in your environment?