PyxGrant / Pilot

A pilot on one team's coding agents.

One team, the laptops and CI runners they work on, and the MCP servers they use. This page lists what is in scope, how setup works, what we measure together, and what the product won't do yet.

Scope

Small enough to finish, real enough to judge.

WHO

One engineering team

Developers running Cursor, Claude Code, or CI agents with MCP tools, and the security owner who reviews what gets refused.

WHERE

Hardware you control

One host runs PyxGrant: a Node service (22.13 or later) and one SQLite file. The collector and checkpoint run on the team's laptops and CI runners.

IN

What the pilot covers

  • Finding the team's agents and MCP servers
  • The MCP guard on the servers you choose
  • The runtime checkpoint for shell and file actions
  • Run budgets, signed receipts, and SIEM export
OUT

What it leaves out

  • Host-wide file and syscall monitoring
  • A drop-in model proxy
  • Vendor-built SaaS, meeting, or plant connectors
  • High availability
Setup

Five steps, in this order.

  1. Install the appliance.Run it on a host you control and connect your OIDC identity provider, or use the built-in one for the pilot.
  2. Find what's running.Run the collector scan on the team's machines and CI runners. Approve the MCP servers you want to keep; the rest stay off. npm run collect
  3. Wrap the MCP servers.Start each approved server through the guard, so denied calls are never forwarded. npm run collect -- proxy
  4. Route shell and file actions.Put the runtime checkpoint beside the agent on laptops and in CI.
  5. Preview before you publish.Replay draft rules against the history you have recorded, and see what would have changed, before the new rules go live.

The quickstart has the exact commands →

What we measure together

Success criteria you can check from the receipts.

Every number below comes from records the pilot produces on your hardware, not from our reporting.

01

Coverage

How many of the team's agents and MCP servers were found and enrolled, and which were missed and why.

02

Wrong refusals

Every refusal reviewed. Each one that shouldn't have happened is counted and fixed with a rule change or an approval.

03

Decision time

Median and slowest decision times on your own traffic, read from the timing each receipt records.

04

Independent check

Your auditor verifies a sample of receipts with your key, without help from us.

Limits to plan around

  • It fails closed. If the PyxGrant host is down, routed calls stop. Start with workflows where a refusal is acceptable, and keep a documented way to take a machine out of the pilot.
  • There is no observe-only mode yet. The guard and checkpoint enforce from the first call. Use the replay in step five to preview the effect of rules first.
  • One host. High availability is not built yet.
  • Only routed actions are seen. Built-in agent tools that bypass both the checkpoint and MCP are not.
  • Detection has edges. Data protection is pattern-based, and prompt injection is not solved.

Before you install anything

  • A security review against this build, including the parts that say "not yet"
  • The pilot scope, success criteria, and support terms agreed in writing
  • A named contact on each side for refusals that block work

What each path covers →

Plan a pilot.

Tell us which agents and MCP servers the team uses. We'll come back with a written scope against this build.