Security model
PitBridge is local-first, so its security model is mostly about keeping the order route on your own machine and making the dangerous actions deliberate. This page describes the controls as built.
on this page
The principle
One process is the trust anchor. The daemon is the only listener, and authentication, permissions and guardrails all live inside it. The NinjaTrader 8 add-on is deliberately simple: it connects out to the daemon and never opens a port of its own. Everything sensitive is in one place you run and can read.
Localhost by default
Out of the box the daemon binds to 127.0.0.1. Nothing on your network can reach it, and nothing on the internet can. In this default mode the daemon and NinjaTrader 8 run on the same Windows machine, and the order route never touches a network interface.
Pairing tokens
Paired mode is the exception, and it is gated. Running the daemon on your Mac while NinjaTrader 8 runs on Windows means the add-on connects across your local network. That requires two things at once, both checked at startup: an explicitpaired_mode = true flag, and a configured pairing token. A non-localhost bind without both is refused before the daemon starts.
The token is generated with pitbridge pair new and sent by the add-on in its first message. A wrong or missing token closes the connection.
Read-only, paper, live
Every account runs in one of three permission modes, checked in the pipeline before any guardrail even runs:
- read_only: the agent can read state. Order tools are refused.
- paper: orders route to a simulation account such as Sim101. This is the default.
- live: orders route to a real account. This mode is not available until the account is armed.
The arm-live ritual
Live is off until you turn it on, and turning it on is a command line action, never an agent tool. The daemon refuses to arm live at all unless a live execution plugin is registered, and the arm step is deliberately manual so no automated sequence can flip an account to live on its own.
$ pitbridge arm-live eval # manual, command line only. never exposed as an mcp tool. account eval armed for live. human_confirm = every_live_order
The kill switch
The kill switch halts all order flow at once. It can be tripped three ways: a file, the command line, or the local REST endpoint. Re-arming, though, is command line only. An AI agent cannot un-kill a bridge you closed, by any route it has.
$ pitbridge kill kill_switch armed. all order flow halted. $ pitbridge unkill # command line only kill_switch cleared.
The audit log
Every decision is appended to a hash-chained JSONL audit log: allows, blocks, the reason code and the config checksum in force at the time. Because the log is hash-chained, a reordered or edited entry breaks the chain and is detectable. You can ask the daemon why a specific order was refused with pitbridge audit why, and verify the chain with pitbridge audit verify.
What leaves your machine
On the order route, nothing. There is no PitBridge server between the agent and the account. A PitBridge cloud may exist for opt-in telemetry only. It sits off the order rail, it can receive a heartbeat if you enable it, and it can never carry an order. If you never turn telemetry on, nothing leaves at all.