Paladin docs

Paladin sits between an AI agent and everything it touches, and decides each action before it happens.

Everything here runs from the published package.

Where it sits

An agent asks to do something: call a model, call a tool, reach an MCP server, open a URL. Paladin sees that request first, evaluates it against your policy, and returns one of four decisions. Only then does the action run, or not. That includes the agent that is itself a browser: when an agent navigates pages, every page is untrusted input, so navigations and page content go through the same decision path as any tool call. And when something looks wrong, you can stop agent actions everywhere at once, without a redeploy, and turn them back on when you are ready.

The decision is deterministic. The same input gives the same decision, every time. There is no model in the enforcement path, so nothing guesses.

That is a different kind of control from the judge inside a coding agent's harness. Claude Code's auto mode and Codex's auto-review each put a second model in front of the actions they would otherwise ask you about, and ask it whether the action looks right. Anthropic's own documentation says what that layer is for: it reduces permission prompts, it does not guarantee safety, and when you need a boundary held for certain it tells you to add a deny rule instead. Paladin is that kind of rule, written once for the actions it can name, and enforced across Claude Code, Codex, Cursor, MCP servers, and the browser.

A judge can form an opinion about an action nobody wrote a rule for. Paladin cannot, and does not pretend to. Its answer for an action the policy never named is the policy default you set: allow it, deny it, or hold it for a person. If you want a guess, keep the judge. If you want the same answer every time, add the rule. The two stack. Sources for the harness descriptions: Claude Code docs, permission modes and Codex docs, agent approvals and security. Third-party names and marks identify compatibility only. They belong to their respective owners, and no endorsement is implied.

Everything runs inside your own infrastructure. Prompts, data, and models stay on your network.

Install

pip install paladin-ai

One package. The engine ships compiled inside it, so there is no toolchain to install.

First run

paladin up

That is the whole setup. On first boot Paladin writes a versioned policy store seeded with a safe baseline, generates an agent token, and opens a hash-chained audit log:

policy store at v1 (policy "paladin-recommended")
audit log: jsonl events.jsonl (hash-chained, tamper-evident)
agent token: auto-generated and saved
interceptor listening on :8080 [PLAINTEXT] (model->, mcp->)
admin/metrics listening on 127.0.0.1:9090 (http)

It is enforcing from the first request. There is no monitor-only mode to forget to turn off.

Note the listen addresses. The proxy binds every interface in plaintext by default; the admin plane binds loopback. Running it covers what to set before production traffic.

The rest of the docs

Four short pages, grouped by what you are doing.

• Put it in front of an agent: one command per agent, the four decisions, and what a blocked call looks like.
• Writing policy: the YAML policy language, what the default baseline covers and does not, what there is to tune, and the audit log.
• When the agent drives a browser: two decision points, two integration depths, and the limits, stated plainly.
• Running it: listen addresses and TLS, how to confirm it is enforcing, and the platforms with published wheels.

Getting deeper

Deployment topology, the Helm chart, credential brokering, multi-agent delegation, and the compliance and risk-graph reporting are not on the site yet. We walk through them directly with teams putting Paladin into a real deployment.

Book a call

Cortexa Labs, Inc.