{"slug": "ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs", "title": "Ingress and egress: the two gateways every enterprise agent platform needs", "summary": "A developer outlines a four-role architecture for enterprise agent platforms that separates a cognitive broker (model access) from a trust gateway and executor (action authorization), so agents propose tool calls while the gateway decides and the executor verifies. The design binds approvals to input hashes so an approved refund cannot be replayed at a higher amount, and it replaces per-team connectors with shared, auditable skills that never expose credentials or network access to agents. The author notes the mechanics exist but the publishing, certification and versioning catalog across teams does not yet.", "body_md": "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.\n\nThe question that stalls deployments is on the other side:\n\nHow does an agent act on a production database, an ERP or an internal API without holding ambient credentials?\n\nThe 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.\n\nWe find it easier to reason about an agent platform by **role** than by component. Four roles, one level of abstraction:\n\n```\nORCHESTRATOR            goals, sub-tasks, SLAs\n      |\nWORKER                  reasoning + observation loops\n      |                              |\n      | thinking                     | acting\n      v                              v\nCOGNITIVE BROKER        TRUST GATEWAY + EXECUTOR\nmodel access            decides, then executes\n      |                              |\n      v                              v\nLLM providers           Databases, ERPs, APIs\n```\n\nThe two roles at the bottom are **parallel paths**, not a stack. A worker talks to both: one to think, one to act.\n\nA 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.\n\nA 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.\n\nThe principle: **agents propose, the gateway decides, the executor verifies.**\n\nBecause 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.\n\nAn agent proposes:\n\n```\n{\n  \"tool\": \"refund.process\",\n  \"args\": { \"order_id\": \"A-1042\", \"amount\": 5000, \"currency\": \"EUR\" }\n}\n```\n\nThe delegation for this user caps refunds at 1,000 EUR. The gateway denies:\n\n```\n{\n  \"decision\": \"deny\",\n  \"reason\": \"amount 5000 exceeds delegated cap 1000\",\n  \"escalation\": \"human_approval_available\"\n}\n```\n\nThe 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.\n\nTwo words need a clear definition here, because we use both:\n\n`refund.process`. It has a name, an input schema and an output schema.\nToday, 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.\n\nThe 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.\n\nFair 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:\n\nIf your needs are met by what you already run, use it. We would like to hear where our claims don't hold.\n\nThe sections above are meant to hold for any implementation. This one describes ours, and what is real today.\n\n*Status legend, as in our earlier posts: 🟢 implemented and open source · 🟡 implemented but private · ⚪ design goal, not built yet.*\n\n**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.\n\n**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.\n\n**Orchestrator.** ⚪ We don't build one. Our worker accepts A2A tasks from an orchestrator or a peer agent, authenticated with a signed token.\n\n**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.\n\n**Trust Gateway.**\n\n`tools/call`, authenticated with a gateway API key and a tenant ID.\n**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.\n\n**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.\n\n**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.\n\nThis 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)\n\nAgents 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.\n\nCode: [github.com/fcn06/trust_gateway](https://github.com/fcn06/trust_gateway).\n\n**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?", "url": "https://wpnews.pro/news/ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs", "canonical_source": "https://dev.to/fcn06/ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs-1fek", "published_at": "2026-10-26 19:05:32+00:00", "updated_at": "2026-10-26 19:13:14.172598+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-safety", "mlops", "developer-tools"], "entities": ["LiteLLM", "OPA", "Cedar", "OAuth", "PostgreSQL", "Jira", "SAP"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs", "markdown": "https://wpnews.pro/news/ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs.md", "text": "https://wpnews.pro/news/ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs.txt", "jsonld": "https://wpnews.pro/news/ingress-and-egress-the-two-gateways-every-enterprise-agent-platform-needs.jsonld"}}