The gateway

The gateway is the one component of the engine that calls a model. Every model call from every agent goes through it, in your account, under its own workload identity. Spending caps, the kill switch, screening and the tool gate are enforced there, in code the model cannot reach.

What the gateway does

On every call, in this order:

1. checks the run’s envelope, and checks the model against the allow-list for your tier and prices it;
2. checks the kill switch, the run’s guards and every budget the call counts against, and reserves its estimated cost, in one transaction;
3. screens the prompt and masks personal data before it leaves;
4. paces the call to the model’s quota, where your policy sets one;
5. calls the model on the backend your policy names: Amazon Bedrock, the Claude API, an OpenAI-compatible endpoint, or the engine’s own model layer;
6. settles the reservation at what was billed;
7. checks the answer against the material it was given, where your policy turns grounding on (off by default);
8. sends a model_call record: tokens, cost, latency, outcome. Never the prompt or the answer.

A timeout keeps its reservation as spent, because the call may have run and been billed. That is how a run cannot creep past its cap one timeout at a time.

Only the gateway’s identity may invoke a model. The engine’s other components cannot, by their cloud permissions. See Engine and gateway security.

Spending caps and kill switches

• Budgets are set per scope (the tenant, a pack, a task, a person or a run) and per period: total, month or day. A call that would pass a cap is refused before it is made.
• The kill switch stops a scope: everything (*), the tenant, a pack, a task, a run, an agent or a person. It holds until a named person revives it.
• From LightHouse, a handler pauses an agent (agent.pause) or sets its cap (budget.set), and an administrator sends a spending limit from Spend → Limits. See Handlers and Limits and alerts.
• In your cloud, a second switch removes the gateway’s permission to call models at all (models_enabled = false in the stack). See Suspension.

The tool gate

An agent’s tools are authorised at run time, not by its prompt. Each tool call passes, in order:

1. the run’s signed run token: a short-lived token binding the tenant, the person, the run, its tools and its budget;
2. a Cedar policy generated from the agent’s card, deny by default: a tool the card does not list is refused;
3. for a tool that acts, the person’s own delegated credential, so the agent acts with that person’s access and no more.

Run tokens are off until a deployment turns them on.

Model routing

The gateway can route each call to the cheapest model that meets the quality bar for the job. See The model router.

In LightHouse and the API

• Security and context → Safeguards shows the safeguards: refusals, screening and stop switches.
• GET /api/v1/budgets, GET /api/v1/kills, GET /api/v1/refusals, GET /api/v1/usage: see the Read reference.
• MCP: kills, refusals, usage, rate_limits.