Agents in Oncology Need Brakes Before They Need Speed

Today we are open-sourcing Custody, chain of custody for AI agents, a governance layer that sits between an AI agent and the tools it uses on oncology data. It does four things. It pauses risky actions for a named human to approve. It records every action in a tamper-evident log. It runs commands in isolated sandboxes. And it keeps patient data away from models that are not allowed to see it.

Coding agents can now write a cohort query, run it, check the output, and draft the report in a few minutes. In most cancer centers and oncology research groups, they still are not allowed to. The reason is rarely that the agent is not smart enough. It is that nobody can answer three questions a privacy officer will ask on day one: who approved this, what exactly did it touch, and can you prove the record was not changed afterward.

The blocker is governance, not capability

Clinical data work runs on accountability. Every access to identified patient data has to be justified, every export has to be authorized, and the record of who did what has to survive an audit years later. A human analyst fits that model: they have a login, a role, a supervisor, and a signature.

An autonomous agent does not fit it out of the box. It acts fast, takes many small actions, and can be steered by anything it reads, including a malicious instruction hidden in a document or a web page. Most agent tools answer this with a yes/no permission prompt in a terminal. That is fine for a developer fixing a bug. It is not an approval record, and it does not tell a compliance team anything they can use.

The broader market is hitting the same wall. In June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing costs, unclear value, and inadequate risk controls. In healthcare the risk-control part dominates. A team that cannot show controls does not get to run the pilot at all.

So we built the controls first.

What Custody does

Custody is a gateway. The agent (Claude Code, Codex, OpenHands, Goose, or anything that speaks MCP) connects to Custody instead of connecting to tools directly. Every tool call passes through four checks before anything runs.

1. Data-aware policy. Datasets and tools are labeled by sensitivity: synthetic, de-identified, limited data set, or identified. Policies are plain YAML that a compliance reviewer can read. Each call is allowed, denied, or held for approval, and the default is deny.
2. Approval gates. Actions that touch identified data, export results, or reach the network wait for a named human to approve with a written reason. Approvals time out to deny. Sensitive actions can require two different approvers, and the agent can never approve itself.
3. Tamper-evident audit log. Every request, decision, approval, and result is written to an append-only log where each entry carries the hash of the one before it. Periodic signed checkpoints let anyone verify that nothing was edited or removed. The log stores references and hashes, not raw patient data.
4. Isolated execution. Commands run in a locked-down container: no network by default, read-only filesystem, non-root user, resource limits, and only the datasets the policy allows mounted in.

Agent (Claude Code, Codex, OpenHands, Goose, any MCP client)
        |
        v
   Custody Gateway
        |
        +--> 1. Policy check        (data-aware, deny by default)
        +--> 2. Approval gate       (named human, written reason)
        +--> 3. Sandboxed execution (no network, read-only, non-root)
        +--> 4. Audit log           (hash-chained, tamper-evident)
        |
        v
   Dataset or tool, only if every check passes

The agent never reaches data or tools directly. Each call is checked against policy, may wait for a human, runs sandboxed, and is logged at every step.

One more control matters more in oncology than anywhere else: model routing by data class. If a call carries identified data, Custody only lets it go to models on an approved list, such as a local model or an endpoint covered by a business associate agreement. A frontier model can plan the work on de-identified or synthetic data, while identified data never leaves the boundary you set.

Design choices, and what Custody is not

A few principles shaped every decision:

• Deny by default. An unknown tool, an unlabeled dataset, or an unreachable approver all resolve to no.
• Readable by non-engineers. Policies and audit exports are meant to be reviewed by privacy and compliance staff, not only by developers.
• Model-agnostic, but not model-indifferent. You can use any model. Custody decides which models may see which data.
• Synthetic data only in this repository. Every example and test uses generated oncology records. No real patient data belongs anywhere near the project.

We also want to be clear about the limits. Custody is not a HIPAA certification, and installing it does not make anyone compliant. It does not replace a business associate agreement, a risk assessment, or your institution's review process. The audit log is tamper-evident, not tamper-proof: it detects changes, and for long-term retention it should be shipped to write-once storage. No sandbox is perfect, so Custody is one layer in a defense-in-depth design, not the whole design. The repository includes a threat model that lists what we defend against and what we do not.

What's shipped since the initial release

A few roadmap items are already in the repo:

• Signed policy bundles, so a reviewer can verify a policy file has not changed since they approved it
• An OPA backend, for teams that already run Open Policy Agent
• An egress allowlist proxy, for the rare case where sandboxed code needs the network
• A read-only FHIR connector
• An S3 Object Lock audit sink, for write-once retention
• A Kubernetes deployment
• OIDC-verified approver identity, for teams with real SSO

Each one was built and tested against a real instance of the thing it talks to, not written and assumed to work. The CHANGELOG says exactly what landed and how it was verified. It also says what we looked at and decided not to build: gVisor and Firecracker sandboxing both need a Linux host with KVM, which we do not have, so we are not shipping sandbox code we cannot verify.

Try it, and help us shape it

The code is on GitHub under the Apache 2.0 license: github.com/unmirihealth/custody. The CLI and the gateway itself are also on PyPI (pip install custody-mcp). The demo below needs a clone either way, since it builds the sandbox's DuckDB image from a Dockerfile in the repo:

git clone https://github.com/unmirihealth/custody
cd custody
uv sync --extra dev
docker build -f docker/sandbox.Dockerfile -t custody-sandbox:duckdb .
uv run custody demo

The demo runs entirely on your laptop. An agent works through a synthetic tumor registry, produces a de-identified cohort report on its own, gets stopped when it tries to export identified records, and leaves an audit trail you can verify with custody audit verify.

Custody is built by UNMIRI, where we are building software infrastructure for precision oncology. It is early. We are looking for a small number of design partners: oncology data, research informatics, and compliance teams who want to use agents but have not been able to get approval. If that is you, I would like to hear which workflow you would automate first and what your reviewers would need to see. Open an issue, or reach me at hello@unmiri.com.

Agents will get faster every month. In oncology, the teams that benefit first will be the ones that can prove what their agents did.

Umair Khan

Founder and CTO, UNMIRI

Building UNMIRI, a precision oncology infrastructure company with four product surfaces: cross-vendor NGS interpretation, genomics-aware decision support, oncology literature intelligence, and a free cross-vendor unification tool for clinicians. Writing here on architecture, clinical data, and HIPAA-ready AI.

See the NGS Interpretation API →

Advisors: Somdutta Saha, PhD, advises on technical architecture and bioinformatics methods as Technical and Scientific Advisor. On the clinical side, UNMIRI is in ongoing conversations with multiple board-certified pathologists about advisory roles. Public introductions land on the About page once each engagement is formalized and the advisor approves being named.