Agents — getting your data AI-ready without giving it the keys.
Agents
Getting your data AI-ready is a contract problem.
Retrieval is the easy half. The hard half is what happens when an autonomous agent decides to act on what it retrieved. The 2026 literature on agent governance and the zero-copy discipline are, we think, the same argument in different vocabularies.
01
AI-ready is contract-ready.
The market currently equates "AI-ready data" with vectorized, embedded, indexed. That is the easy half. An agent does not fail because it couldn't retrieve; it fails because it retrieved something it was never supposed to touch and then acted on it. Retrieval is a read problem. Action is a contract problem.
The same discipline that keeps a warehouse honest — one boundary, one schema, one owner — is what keeps an agent honest. Every tool an agent can call is a copy of authority into a runtime. If that copy isn't under a contract you wrote on purpose, you are, functionally, letting an LLM issue database credentials to itself.
Every tool call is a copy of authority. Copy at the boundary, under contract, or not at all.
02
Authorize before the tool call, not after the incident.
The 2026 literature has converged on a striking claim: agent safety cannot be bolted on at the model layer. It has to be enforced deterministically, outside the model, before the side-effect happens. Uchibeke's Open Agent Passport specifies pre-action authorization as a protocol. Palumbo et al. compile natural-language policy into Datalog and evaluate it on every proposed action. Salfeld-Nebgen makes the same move at the institutional layer — attest the action, not the agent.
In zero-copy terms, this is release/acquire ordering for authority. The producer (the model) proposes; the consumer (the tool) commits only after a deterministic check against a policy that a human wrote. No policy, no acquire. This is not friction — it is the only place the audit trail can live.
The model proposes. The policy commits. Never the other way around.
03
Proof of execution, not proof of intent.
Logs are what an agent said it did. Proofs are what actually ran. Rhodes & Kang's Proof of Execution and Jin et al.'s Proof-of-Guardrail push the same idea from opposite ends: the runtime that executes the tool call, and the guardrail that gates it, both need to emit evidence that a third party can verify without trusting the agent's own transcript.
For a data platform, this collapses to a familiar request: emit the alarm with the row. If a pipeline can't tell you which policy version approved which write, at the moment of the write, you are running on faith. Faith is fine until the regulator asks.
If the agent's own log is the only evidence, you don't have evidence.
04
Least copy is least blast radius.
AgentGuardian frames the containment problem as access control: learn the smallest set of capabilities an agent needs, then deny everything else by default. Bhattarai & Vu's "Lethal Trifecta" names the failure mode when you don't — untrusted input, sensitive data, and external side-effects, colocated in one context, is a breach waiting for a prompt.
This is the zero-copy argument, restated for agents. Every place a row exists is a place it can be exfiltrated. Every tool an agent holds is a capability it can be tricked into using. Fewer copies, fewer capabilities, narrower contracts. The stack that is cheapest to operate is also the one that is cheapest to defend.