# Ingress and egress: the two gateways every enterprise agent platform needs > Source: > Published: 2026-10-26 19:05:32+00:00 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. 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. 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. The principle: **agents propose, the gateway decides, the executor verifies.** 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 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. Two words need a clear definition here, because we use both: `refund.process`. It has a name, an input schema and an output schema. 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. 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: If your needs are met by what you already run, use it. We would like to hear where our claims don't hold. 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.** `tools/call`, authenticated with a gateway API key and a tenant ID. **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](https://dev.to/fcn06/personal-agent-protocol-should-the-company-agent-be-a-back-end-channel-like-the-website-or-the-api-g4n) 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](https://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?