Caretaker Research
We study how agents can act in production systems under explicit policy, human authorization, and verifiable records of what was approved and what executed.
An agent plan enters a policy gate. Non-consequential actions proceed to constrained execution. Consequential actions require a named human approval, which is signed into an attestation, then executed, then reconciled against what was approved. Audit and provenance run beneath every stage.
Caretaker’s control model separates policy, authorization, attestation, execution, and reconciliation, so that no interface gesture is mistaken for an enforcement boundary.
Conventional audit logs are usually produced by the same platform that runs the agent. They record what the platform says happened. They do not necessarily bind intent, approval, and execution into one chain that anyone can check.
Caretaker investigates a stricter model: discriminate consequential actions before they execute, bind authorization to the exact proposed change, and compare what executed against what was approved — using evidence the executing system does not produce by itself.
Research areas
How should a system identify consequential actions before they execute, without turning every operation into an approval prompt? Gating everything is the same as gating nothing once the reviewer stops reading.
How can a named person authorize one exact action, once — without approval replay, stale state, or enforcement that lives in the interface rather than the server?
What evidence is necessary to bind a proposal, a policy decision, an approval, and an execution into one chain that survives crossing a trust boundary?
How can observed execution be compared with approved intent, and what does that evidence actually support about reliability or certification?
Featured research
An approval link is only meaningful if it authorizes one change, once. We found our single-use enforcement was split across two statements and did not hold under concurrency, and rewrote it as one atomic predicate.
Implementation status
These labels are part of the trust design, not badges. “Verified” means the control was exercised by a recorded test or a live run, and in most cases that the guard was deliberately broken and the suite re-run to confirm it fails.
Latest publications
Gating every action produces approval fatigue, which is the same as gating nothing. Classification is the design problem — and a gate that classifies correctly can still be inert if nothing populates its rules.
CI job logs are third-party-influenced text that flowed unfiltered into a privileged planning prompt. We routed them through a zero-tool-access reader restricted to schema-validated output, and tested it against a real injection.
Approving a change and executing a change are separate events, and nothing structural forces them to match. We recompute the diff from the provider's own API at merge time and block on mismatch — and the first honest run failed.
Our attestation chain is signed, hash-linked, and re-verified on every read. It is tamper-evident. It is not independently verifiable, and the distinction is the first thing a security reviewer will test.
Caretaker is building an evidence base for accountable agent execution. We publish what works, what failed, and what remains unproven.