PitSense

PitSense / Platform

From a repository or a running agent to a proven finding

The platform has two ways in. Both end in the same place: a replay that fires before the patch and is blocked after it.

Code lane: start from a repository

Eight stages, each handing the next an artefact you can open and inspect.

  1. Snapshot

    A git URL becomes a read-only copy.

  2. Agent graph

    Agents, tools and memory, mapped to file and line.

  3. Sources to sinks

    Untrusted inputs traced to ungated actions.

  4. Hypotheses

    One isolated agent investigates each path.

  5. Exploit

    The attack is written into a fixed replay template.

  6. Replay

    Five attack runs, five controls, network off.

  7. Fix

    The patch must block the replay and mutated payloads.

  8. Report

    Severity, evidence and a ready pull-request branch.

Harness lane: start from a running agent

We rebuild your setup in the sandbox and run an adaptive campaign against it until a recorder fires or the budget is spent.

  1. Replica

    Your harness rebuilt: permissions, hooks, MCP servers, memory and model.

  2. Reconnaissance

    The agent graph and its taint paths.

  3. Control run

    A baseline with no attack, so normal behaviour is on record.

  4. Adaptive campaign

    Attacker agents inject, observe the result and mutate the next attempt.

  5. Minimise and replay

    The smallest attack that still works, replayed under the proof standard.

Eight recorders, none of them inside your harness

An agent's own logs are part of what is being attacked. Our recorders sit outside it and log what actually ran.

Egress proxy

Every outbound request.

Model proxy

Every prompt and completion, with the model pinned.

Tool shims

Every tool call and its arguments.

MCP proxy

Tool definitions hashed, so a silent change shows as a diff.

File watcher

On the host, out of the agent's reach.

Approval stub

Always answers no. Anything that runs anyway is a bypass.

System under test

Your agents, tools and harness, sealed in a sandbox.

Planted secrets

Decoy keys that should never leave.

Attacker canary

A marker that only appears at a sink if the attack worked.

The proof standard

A model saying an attack worked never counts. A recorder has to see the effect, a control has to stay clean, and the patch has to make it stop.

3 of 5 or moreattack runs where the effect is recorded
0 of 5control runs without the payload
0 of 5attack runs against the patched build
3 or moremutated payloads the patch also blocks

What ships with a finding

A self-contained proof folder. Anyone with Docker can re-run it and get the same counts, which makes a report quick for a maintainer to confirm.

When the budget runs out without a finding, the report says the budget was spent. It never says the system is safe.

proof/
├── replay.py      fixed template
├── payload.json   the attack input
├── output.txt     5 attack, 5 control, 5 patched
├── fix.patch      what the replay fails against
└── sha256.txt     target commit and every file

Where it runs

Targets only ever execute inside the sandbox, and we test local copies, never a live third-party system. Your code stays out of our attack corpus.

  • available

    Local Docker

    Runs on a single machine. Analysis agents call a frontier model API.

  • roadmap

    Your own model key

    Evidence and replays stay in your CI.

  • roadmap

    On-premises, open-weight models

    Nothing leaves your hardware.

Frameworks in scope

The platform is in private preview. These are the agent frameworks and runtimes our research targets today.

  • LangGraph
  • LangChain
  • OpenAI Agents SDK
  • Claude Agent SDK
  • CrewAI
  • AutoGen / AG2
  • Mastra
  • OpenHands
  • Strands
  • Haystack
  • MCP servers

See the pipeline run on your stack

Bring a repository or a running agent. We will walk through a campaign and what a finding looks like when it lands.

Request a briefingRead the research