Ingress and egress: the two gateways every enterprise agent platform needs

Two crucial gateways every enterprise agent platform requires are ingress and egress. Cognitive ingress, or routing prompts across providers, fallbacks, token budgets, is well managed by tools like LiteLLM. However, the egress side - how an agent interacts with production databases, ERPs, or internal APIs without holding ambient credentials - often stalls deployments. The current approach combines service-account tokens with raw function schemas, merging model intentions with system permissions, which is problematic.

To address this, we propose a four-role map: orchestrator, worker, cognitive broker, and trust gateway + executor. The orchestrator plans and delegates tasks to workers, while the worker reasons and observes, holding no LLM provider keys or enterprise system credentials. The cognitive broker, responsible for the ingress side, handles routing, fallbacks, token budgets, and holds provider keys, ensuring secure communication.

The trust gateway + executor, the egress side, decides whether an action is allowed and executes it after verifying the gateway's decision, with the executor being the only part touching enterprise systems.

A key principle is that agents propose actions, the gateway decides based on deterministic policies, and the executor verifies before execution. This ensures deterministic decision-making, prevents data leakage through prompts, and allows for human approval on high-risk actions. Proposed actions are signed and single-use, preventing replay attacks.

The executor also verifies inputs on its own to prevent network path trust issues. This approach eliminates the need for teams to write their own connectors, turning them into shared, auditable skills published once by domain teams. The main challenge lies in the cataloging around these skills, which involves publishing workflows, certification, and versioning across teams.