Choose Your Production Integration Path

You have protected a real service, made your runs identifiable, and traced both an allow and a deny. One decision remains before production work starts: where enforcement happens in your architecture. This page helps you make that decision once, deliberately.

So far, every call was verified by the Gateway - the checkpoint in front of your service. That is one of two possible boundaries:

Boundary	How it works	Choose it when
Gateway-routed (what you have been using)	Requests travel through the Gateway, which verifies each mandate, attaches upstream credentials, and records the action result centrally.	Your protected target is HTTP and you want enforcement, credential brokering, and audit in one place your services never have to implement.
In-process adapter	Your own service verifies mandates inside its process using a framework adapter, then records its own action results.	You own the service’s code, and requests should not detour through a central checkpoint - for latency, topology, or deployment reasons.

Both enforce the same contract; they differ in where verification runs and who writes the action-result audit. Start with the Gateway boundary unless you have a concrete reason not to - it is the path you have already proven end to end.

One boundary first

Pick one boundary and take it to production before adding a second pattern, delegation flows, or approvals. Every mixed-pattern debugging session starts with someone who skipped this step.

Prerequisite

Complete Trace One Protected Request or be able to explain an equivalent request from application to resource.

Choose by Boundary

Gateway-routed - requests detour through the central checkpoint:

If your production path is…	Continue with
Route HTTP traffic through the Caracal Gateway	Protect a Gateway-Routed HTTP API

In-process adapter - your service verifies mandates itself:

If your production path is…	Continue with
Protect an Express resource server in process	Protect an Express App
Protect a FastAPI or Starlette service in process	Protect a FastAPI App
Protect a FastMCP server in process	Protect a FastMCP App
Protect a Go net/http service in process	Protect a Go net/http Service
Protect an MCP server without a dedicated adapter	Protect an MCP Server

Two paths sit alongside the boundary choice rather than replacing it - how your application code obtains authority, and how existing CLIs receive provider credentials:

If you also need to…	Continue with
Add Caracal sessions and Gateway calls to app code	TypeScript SDK, Python SDK, or Go SDK
Launch an existing CLI or worker with injected provider credentials	Run an Agent with caracal run

Add Capabilities After the Boundary Works

These build on a verified boundary; none of them replaces it:

When you need to…	Continue with
Model zones, apps, resources, and customer boundaries	Model Your Application in Caracal
Configure provider credentials or OAuth	Define Resources and Providers and Provider Recipes
Debug denies or unexpected allows	Debug Authorization Decisions
Hand narrowed authority between agents	Implement Multi-Agent Delegation
Export or query audit evidence	Tail and Query the Audit Stream
Hold sensitive actions for human approval	Human Approval

Choose by Team Role

Role	Start with
App engineer	SDK guide for your language, then the Gateway or adapter guide.
Platform engineer	Production Integration Patterns, then operations pages.
Security reviewer	Debug Authorization Decisions, Audit and Request Traces, and Review the Threat Model.
Policy owner	Author Policy Data and Activate a Policy Set.

Expected Outcome

You leave this page with one primary enforcement boundary and one implementation guide, recorded before anyone adds delegation, approvals, or alternative adapters. You have completed the tutorial path: a real protected API, identifiable runs, self-serve debugging, and a deliberate production direction.

Next Step

Open Guides and follow the path that matches your boundary.