Eve Gateway Model
Eve is the shared gateway path for applications, services, users, robots, and agents. It can sit in front of databases, model providers, APIs, tools, and internal services so teams do not have to duplicate authentication, endpoint credentials, routing, policy, and telemetry in every client.
Gateway Responsibilities
| Responsibility | What Eve owns |
|---|---|
| Identity context | Resolve the caller, organization, token, and subject type. |
| Endpoint resolution | Map a logical endpoint name or UUID to configured backend connection details. |
| Permission checks | Enforce control-plane and data-plane access before allowing configuration or runtime use. |
| Routing | Dispatch requests to the selected backend, model provider, API, or tool. |
| Protocol handling | Speak supported native protocols where Eve is deployed as a protocol-aware interlay. |
| Policy | Observe, warn, mask, or block risky operations before they execute. |
| Telemetry | Emit request, endpoint, policy, latency, and error signals from the request path. |
Gateway Shapes
Eve can be used in multiple shapes depending on the workload.
REST API Gateway
Applications and operators call Eve's HTTP API for organization management, endpoint configuration, query execution, workflows, templates, users, RBAC, and migrations.
Use this shape when:
- clients can call HTTP,
- you want one API for many endpoint types,
- or the operation is control-plane oriented.
Native Protocol Interlay
Applications connect to an Eve listener that speaks the backend protocol. This is used when the client should keep using a native driver or when Eve must sit in the live traffic path.
Use this shape when:
- the client should keep its Redis, PostgreSQL, MongoDB, or other native driver,
- a migration needs traffic forwarding, mirroring, or rollback,
- command policy must happen before the backend sees the command,
- or protocol-level metrics are required.
AI And Tool Gateway
Model providers, tools, functions, and APIs can be exposed as endpoints through Eve so Adam and agent workflows inherit the same access model.
Use this shape when:
- agents need governed tool access,
- model traffic should share usage accounting and routing,
- or tool calls need a traceable audit trail.
Request Path
A runtime request usually flows through these checks:
- Authenticate the caller.
- Resolve organization context.
- Resolve the endpoint or tool.
- Check data-plane permission for the action.
- Apply routing and policy.
- Forward to the backend.
- Return a native or API response to the caller.
- Emit telemetry and audit context.
Operational Guidance
Before moving production traffic through Eve:
- create the endpoint and verify health,
- confirm the caller has least-privilege access,
- test the same protocol and payload shapes the app uses,
- export telemetry to the team's normal monitoring stack,
- define rollback or bypass behavior,
- and load test the gateway shape that will be used in production.