The map so far

What should a coding agent be allowed to do, and who decides?

Coding agents run commands, install packages and edit files on real machines. Most of what they do is fine, and a guardrail that interrupts constantly gets switched off. We work on controls that stop a short list of clearly dangerous actions, record the rest honestly, and leave the final say with the provider's own permissions and the people using the agent.

• Charted

  Block a short list of high-confidence dangerous actions at runtime.

  DiffWitness Protect ships three policies: observe records only, standard blocks high-confidence dangerous actions, strict also asks for confirmation before dependency installs where the agent protocol allows it.

• Charted

  Keep what was observed separate from what was proven.

  Runtime observations are labelled as observed and never count as proof about a change.

• Charted

  Record agent activity without keeping its contents.

  Protect receipts leave out raw commands, source code, prompts and raw session identifiers. Sessions appear only as a short digest.

• Surveying

  One control model across agents and harnesses.

  Runtime protection works through native hooks in Claude Code and Codex. Other command-line agents get proof checks through a generic wrapper, but not runtime blocking.

• Uncharted

  What do guardrails cost in practice?

  We have not yet measured how often blocking rules interrupt legitimate work on real projects, or how people respond when they do.

• Uncharted

  How should permissions work for long-running and cloud agents?

  Agents that run unattended on remote machines change who is present when a risky action happens. We want to understand what control looks like when nobody is watching.

What does the evidence actually establish about a change an agent wrote?

A passing test suite says that a patch passes. It does not say which parts of the patch the tests depend on, or whether the new tests would have caught the bug at all. We build counterfactual experiments on the real diff and report what they show, including when they show nothing.

• Charted

  Contrast: would the new tests have caught the problem?

  The candidate's tests are run against the old code, which should fail, and against the new code, which should pass.

• Charted

  Necessity: which hunks does the evidence depend on?

  Each production hunk is removed in turn. Hunks are reported as witnessed, unwitnessed or inconclusive, always relative to the chosen evidence.

• Charted

  Sufficiency within declared bounds.

  A search for the smallest subset of the patch that still passes. The result states whether the search was exhaustive, and a bounded search is never presented as a global answer.

• Charted

  Interaction between hunks.

  Two changes that back each other up can each look unnecessary on their own. Pairwise checks report them together.

• Charted

  Engineering debt as a verifiable ledger.

  Obligations a change leaves behind are recorded in an append-only, hash-chained ledger and close only when a check confirms them.

• Uncharted

  How much of a typical agent patch is unwitnessed?

  Our engines are tested on fixtures and benchmarks. Measurements on real repositories and real agent sessions have not been done yet.

• Uncharted

  When is the evidence too weak to say anything?

  Weak tests produce weak evidence. We want tools to recognise that case and say so, rather than report a clean result.

• Uncharted

  Keeping counterfactual runs affordable.

  Every experiment reruns the evidence. Large test suites make this expensive, and we are looking for ways to cut the cost without weakening the claims.

Can the people responsible for a product still understand it?

When an agent writes most of the code, the risk is not only bugs. It is a team that no longer knows how its own product works. We study explanations that are tied to what was actually observed in the project, that name real files and real dependencies, and that admit when they do not know.

• Charted

  Plain-language explanations bound to observed evidence.

  IdleProof explains what an agent is doing, what it means, which parts of the project are involved and what risks matter.

• Charted

  Say unknown instead of inventing a role.

  Observed facts and inferences are kept apart. When a file's purpose is not supported by evidence, the explanation says so.

• Charted

  Static maps of what a change touches.

  A bounded map of related files, services, dependencies and tests, presented as static analysis and not as a runtime call graph.

• Charted

  A benchmark for explanations.

  A 30-scenario benchmark checks explanation quality as part of IdleProof's test gates.

• Surveying

  Checks that help understanding without becoming homework.

  Optional understanding checks exist and are collapsed by default. Skipping them is not treated as failure. We do not yet know which formats people find useful.

• Uncharted

  Linking explanations, proofs and obligations.

  Joining what IdleProof explains, what DiffWitness proves and what the Debt Ledger records through a stable identity for each change. This is a long-term goal, planned for Paitite's optional commercial Portal.

• Uncharted

  Can knowledge debt be measured?

  We want to know whether the gap between a codebase and its team's understanding of it can be tracked over time without collecting source code or prompts.

Our tools do not prove that code is correct. They cannot establish requirements that the tests do not encode, and weak tests produce weak evidence. Runtime protection is not a sandbox. Flaky or timed-out experiments never become causal claims, and a bounded search is reported as bounded. Each project documents its own limits and threat model.

Several of the open questions above can only be answered on real codebases. If your team runs coding agents on production software and wants to work on any of them with us, write to contact@paitite.com.