The ZTroven control layer

Control every agent handoff. Prove what crossed it.

ZTroven runs inside your agents, at every outbound handoff to a model, a tool, an MCP server, another agent or a queue. It decides what that recipient may see, sends the permitted payload itself, and signs a value-free record of what left.

Discuss an integration  → How it works  →

Inside your application · No ZTroven service in the data path · Works across agent stacks

Outbound transaction · TXN-4821Policy applied
What the agent holds

Operations agent

The full workflow context stays inside the application.

customer.recordpayment.detailsshipping.address
At the outbound boundary

ZTroven

Your policy decides this hop.

  • Bind sender, recipient, purpose and parent hop
  • Apply the permitted view before dispatch
  • Sign a value-free record of what left
Payment servicePayment subset onlyAllowed
Analytics agentTokenized referenceLimited
Unknown serviceNo matching contractBlocked
Signed hop recordsender · recipient · purpose · actions · dispatched-payload hash · parent hop
Alongside your platform

Your platform controls what an agent can call. ZTroven controls what each call discloses.

Gateways, routers and runtime controls decide which agents run, which tools they may use and what they spend. ZTroven works one layer in, inside the agent, deciding which facts each recipient may learn and recording exactly what was sent. It adds to the controls you already run. It replaces none of them.

Question
Platform and gateway controls
ZTroven
Unit of control
The agent, the tool, the model, the budget
Each declared field, for this recipient and this purpose
Where it runs
At the gateway or in the runtime
In the agent’s own process, at the boundary where data leaves
Who holds the data
The gateway sees payloads as they pass
Values, tokens and keys stay with you. ZTroven holds none of them.
What you can show later
Platform logs and traces
A signed record per hop that anyone can verify without trusting ZTroven or the platform

Five steps on every handoff.

The same pattern applies whether the recipient is a model, a tool, another agent or a queue.

01

Bind

Sender, recipient, purpose and parent hop are attached before anything leaves.

02

Decide

Your egress contract determines this recipient’s permitted view, deterministically.

03

Apply

Each declared field is allowed, removed or tokenized locally. The hop can also be blocked or held for review.

04

Dispatch

ZTroven sends the payload itself, so the bytes evaluated are the bytes sent.

05

Prove

A signed, value-free record links the hop to its transaction.

Fail-closed by default. If a policy cannot be enforced, or a recipient has no matching contract, the hop stops or is visibly marked unverified. There is no model in the decision path, so the same inputs always give the same decision.

One fact. A different answer for each recipient.

You declare which fields are sensitive. ZTroven locates them and applies the action your contract sets for each recipient.

allow

The recipient needs this value for this purpose, so it is sent.

remove

The field is taken out of this recipient’s view entirely.

tokenize

A reversible token replaces the value. The vault and keys stay with you.

block

The hop does not go out.

require_review

A person on your team confirms before the hop proceeds.

Evidence, not certification.

Each hop record is something your reviewers can check for themselves. It is deliberately specific about what it does and does not show.

What a hop record shows

  • The declared sender, recipient and purpose
  • Which actions were applied to which fields
  • A hash of the exact payload that was dispatched
  • How the hop links to the rest of the transaction
  • An Ed25519 signature anyone can verify, with no values inside the record

What it does not claim

  • That every sensitive fact was found. Declaration and detection still matter.
  • That no path bypassed ZTroven. Your deployment and network controls still count.
  • How the recipient handled the data afterwards
  • Any compliance verdict. The record is input to your process.

Wrap the handoff. Keep everything else.

A TypeScript library that runs in-process. Your models, orchestration, tools and runtime stay as they are. Available today to design partners.

1Declare the sensitive fields in a workflow
2Write egress contracts per recipient and purpose
3Route each outbound call through ZTroven
Discuss an integration  →
One governed handoff
import { ztrovenSend } from "ztroven";

const result = await ztrovenSend(
  call,
  customerContext
);

return continueWorkflow(result);
Models and providersUnchanged
Agent frameworksUnchanged
Your platformUnchanged

Building or running agents for others?

Whether you run an agent platform or build agents for regulated workflows, we would like to show you the control layer on one of your handoffs.

Talk to us  → hello@ztroven.com