Any language (HTTP)

Get the same checks as agentfox.auto() from TypeScript, Go, Java or anything that speaks HTTP: change your client's base URL, or ask AgentFox before a tool runs.

Before you start

The server URL from your setup card, or a local gateway: agentfox serve listens on http://127.0.0.1:8080.

Point your client at the proxy
Any OpenAI-compatible client works. Set the base URL to the gateway's /v1 and name the agent in a header. Anthropic clients use /v1/messages the same way.
agent.ts
```
const client = new OpenAI({
  baseURL: "http://localhost:8080/v1",
  defaultHeaders: { "X-AgentFox-Agent": "support-triage" },
});
```
The prompt, the answer and every tool call the model asks for are checked before the response reaches you. Streaming works.
Handle a refusal
A blocked request is a 403. Do not retry it; log the trace_id. A call held for a person is a 428 with an approval_id. Once it is approved, send the same request with X-AgentFox-Approval: apr_… and it runs once.
Or check a tool call before it runs
If you call the model yourself, ask AgentFox before each tool runs. Say where each argument came from, so an id copied out of a web page is treated differently from one the user typed.
bash
```
curl -s http://localhost:8080/v1/guard/tool_call -H 'Content-Type: application/json' \
  -d '{"agent": "support-triage", "tool": "tickets.close",
       "arguments": {"ticket_id": "T-4411"}, "provenance": {"ticket_id": "user"}}'
```
This route always answers 200, even for a refusal. Read verdict: run the tool only on allow. On escalate, wait for the approval_id to be decided. On block, do not run it.
See it in the app
Each request appears on the agent's Activity tab and on Traces, with the rule that decided it.

Headers worth sending

Header	What it does
`X-AgentFox-Agent`	The agent's name. Without it, no grant or agent rule applies.
`X-AgentFox-Session`	Ties calls into one conversation, so runaway tool loops are caught.
`X-AgentFox-Intent`	The task the agent is on. Tool calls are checked against it.

Every route and field is in the HTTP API reference. Headers, streaming modes and status codes are under Gateway requests. Text checks (/v1/guard/input, /v1/guard/output), memory writes and MCP results have their own guard routes there too.

/v1 does not check an operator login. Keep the gateway on a private network, and give each agent a key (Authorization: Bearer nom_agt_…) so calls are tied to it.

If something goes wrong

You see	Do this
Everything is allowed, and `x-agentfox-would-be-verdict` says `block`	The guardrail is in Watch. Switch it to Block when you are ready.
A grant has no effect	The `X-AgentFox-Agent` header (or `agent` field) must match the agent's name exactly.
A self-hosted gateway cannot reach your model provider	Set `AGENTFOX_ALLOW_EGRESS=true` and the provider's key (Configuration).

Before you start

The server URL from your setup card, or a local gateway: agentfox serve listens on http://127.0.0.1:8080.

Point your client at the proxy

Any OpenAI-compatible client works. Set the base URL to the gateway's /v1 and name the agent in a header. Anthropic clients use /v1/messages the same way.

agent.ts

const client = new OpenAI({
  baseURL: "http://localhost:8080/v1",
  defaultHeaders: { "X-AgentFox-Agent": "support-triage" },
});

The prompt, the answer and every tool call the model asks for are checked before the response reaches you. Streaming works.

Handle a refusal

A blocked request is a 403. Do not retry it; log the trace_id. A call held for a person is a 428 with an approval_id. Once it is approved, send the same request with X-AgentFox-Approval: apr_… and it runs once.

Or check a tool call before it runs

If you call the model yourself, ask AgentFox before each tool runs. Say where each argument came from, so an id copied out of a web page is treated differently from one the user typed.

bash

curl -s http://localhost:8080/v1/guard/tool_call -H 'Content-Type: application/json' \
  -d '{"agent": "support-triage", "tool": "tickets.close",
       "arguments": {"ticket_id": "T-4411"}, "provenance": {"ticket_id": "user"}}'

This route always answers 200, even for a refusal. Read verdict: run the tool only on allow. On escalate, wait for the approval_id to be decided. On block, do not run it.

See it in the app

Each request appears on the agent's Activity tab and on Traces, with the rule that decided it.

Headers worth sending

Header

What it does

X-AgentFox-Agent

The agent's name. Without it, no grant or agent rule applies.

X-AgentFox-Session

Ties calls into one conversation, so runaway tool loops are caught.

X-AgentFox-Intent

The task the agent is on. Tool calls are checked against it.

/v1 does not check an operator login. Keep the gateway on a private network, and give each agent a key (Authorization: Bearer nom_agt_…) so calls are tied to it.

If something goes wrong

You see

Do this

Everything is allowed, and x-agentfox-would-be-verdict says block

The guardrail is in Watch. Switch it to Block when you are ready.

A grant has no effect

The X-AgentFox-Agent header (or agent field) must match the agent's name exactly.

A self-hosted gateway cannot reach your model provider

Set AGENTFOX_ALLOW_EGRESS=true and the provider's key (Configuration).