Skip to main content
sec0-sdk/gateway centralizes authentication, authorization, entitlements, quotas, vendor token brokering, idempotency/dedupe, and audit at network boundaries. Use it when tool execution crosses process or network boundaries so custody and policy enforcement continue across hops.

When to Use the Gateway

  • Your agents call tool servers over HTTP/HTTPS
  • You need centralized OIDC auth at the network edge
  • You want per-tenant/per-user rate limits and daily quotas
  • You need vendor API key injection without exposing keys to agents
  • You want idempotency/dedupe for side-effecting tool calls
  • You need egress and filesystem allowlists at the boundary

Starting the Gateway

Gateway Endpoints

Required Headers

Authentication

OIDC JWT Validation

For machine-to-machine agents, use OIDC client-credentials tokens (the gateway can authorize these via agents entitlements using the token azp/client_id claim).

Entitlements

Control which tenants, users, roles, and service agents can access which tools:

Quotas

Rate limiting and daily limits via pluggable adapters:

QuotaAdapter Interface

Vendor Token Brokering

Inject upstream API keys without exposing them to agents:

Broker Types

Boundary Guardrails

Restrict what upstream servers can access:

Idempotency & Dedupe

Prevent duplicate side-effect calls:

AP2 Mandate Enforcement

Verify multi-hop intent and cart mandates:

Agent State Analytics

Opt-in to derived telemetry written into agent state:

Remote Runtime Decisioning

Use the gateway’s runtime adapter when final allow or deny decisions should be delegated to a remote service:

Using the Pipeline Directly

If you already have an HTTP server, use the lower-level pipeline:

Policy-Driven Configuration

Map a Sec0 policy YAML into gateway config:
For the full gateway configuration reference, see Gateway Config Reference.