• 

  architecture

DocTrust — Compliance Authority for AI Agents

Inspiration

AI agents can now read documents, investigate evidence, and call tools. The question that matters in consequential workflows isn't can the agent understand this — it's who is actually authorized to decide.

That question stopped being philosophy while I built this. On August 2, 2026, the EU AI Act reached its general date of application, but the high-risk obligations for Annex III systems were subsequently deferred to December 2, 2027. Article 12 establishes record-keeping requirements for high-risk AI, and Article 14 establishes human oversight. At the same time, MCP and A2A are now hosted within the Linux Foundation's Agentic AI Foundation (AAIF): MCP defines agent-to-tool interoperability, while A2A defines agent-to-agent communication. The ecosystem is standardizing how agents connect; the separate question of how consequential authority is established and revoked remains open. My thesis: let the agent investigate; do not let it become the authority.

Then GhostJacking made the problem painfully concrete. At DEF CON 34, Tenet Security demonstrated how an attacker could plant instructions inside a blocked request that a later AI agent reads from a trusted security log; the agent then uses legitimate permissions to carry out the attack. In the demonstrated chain, the poisoned telemetry could drive a DNS change even though the firewall, authentication, and API controls had all worked as designed. Testing reported the planted instruction being followed in 9 of 10 Claude Code attempts under the tested configuration. The lesson is bigger than prompt injection: when untrusted data can directly become authorized action, the permission model becomes the attack surface.

That is the gap I am building DocTrust around: evidence can inform an agent without silently granting it the authority to decide. The same primitive led me to build Solvent separately — a general-purpose experiment in the authorization boundary for consequential agent actions. DocTrust applies that idea to evidence-driven compliance and regulated workflows.

I also got skeptical of my own demo, so I built a way to prove it instead of asking judges to trust it: I attacked my own public repo like an adversary, found a real audit-verification defect, fixed it, and re-tested the exact GitHub repo from a clean clone.

What it does

My proof case is shipment release. A shipment starts with 2 of 4 required documents. DocTrust returns REVIEW/BLOCKING rather than treating missing evidence as safe. Hermes investigates, finds the missing packing list and certificate of origin, and extends the evidence:

Commercial Invoice / Packing List / Certificate of Origin   4,650 KG
Bill of Lading                                              5,150 KG  ← OUTLIER

The agent can investigate — it cannot approve or reject. That capability is structurally absent from its MCP tool surface. Human sign-off happens on a separate, consent-driven, Ed25519-signed channel before the audit is sealed. Nutrient DWS provides page-and-bbox-grounded extraction; my EvidenceProvider interface keeps that swappable rather than load-bearing.

How I built it

I built a Go-based trust architecture, not an LLM wrapper:

• AI drafts policy, humans approve it. LLM-generated checks are candidates, never the runtime authority — a promotion gate separates drafting from enforcement.
• Deterministic enforcement. The same evidence + approved Ruleset always produces the same decision. No LLM vote at runtime.
• Authority is architectural, not promised. I rejected a request_human_review tool the agent could call — that capability simply isn't in its surface. This is Article 14's human-oversight requirement implemented as a missing method, not a policy line.
• Evidence has provenance. Every fact keeps its document/page lineage.
• I verified it in the open. My first self-attack found a real signing-key mismatch and exposed personal paths. I fixed it, published it, and re-attacked a fresh clone — signature checks, tamper mutations, and the full audit chain all passed.

Challenges I ran into

The hard problem was never the API call — it was deciding how much authority an AI should have.

GhostJacking sharpened that question for me: an attacker does not necessarily need to defeat the firewall, steal a session, or break an API. They can sometimes put instructions into information an agent is already trusted to read and let the agent's existing permissions do the rest. That is why I don't think “just make the prompt safer” is a sufficient architecture for consequential systems.

I nearly over-invested in LLM policy authoring before realizing weak generated policy is fine as a candidate and dangerous as governing truth. I also hit a real Nutrient quota wall mid-verification and kept the failure in the record instead of hiding it: a failure is a failure until it's actually fixed.

Accomplishments that I am proud of

• Working end-to-end MVP: extraction → deterministic evaluation → agent investigation → human authority → signed audit — not a concept.
• The authority boundary is architectural: the agent's tool surface cannot self-authorize.
• Turned skepticism into an engineering discipline: attack, find the weakness, fix it, publish it, then attack the public clone again.
• Built for the next agent era: the same compliance engine can serve different agents and interfaces; the agent is not the authority.
• Built the problem, not just the demo: DocTrust treats evidence, authorization, and auditability as separate primitives rather than assuming a more capable model will somehow provide all three.
• Built for a regulatory direction that is already here: Article 12 and Article 14 of the EU AI Act explicitly address record-keeping and human oversight for high-risk AI, while ISO/IEC 42001 provides an AI management-system framework. DocTrust implements an engineering pattern that can help organizations operationalize those kinds of controls.

Everything above is independently checkable — start with the 60-second verification in the README.

What I learned

Trustworthy agentic systems come from separating responsibilities, not from a smarter model: the skill constrains behavior, the architecture constrains capability, the deterministic engine constrains outcomes.

LLMs are excellent policy drafters and should never be the final authority that makes policy executable. GhostJacking reinforced the same lesson from the other direction: the dangerous transition is not merely from text to thought, but from untrusted information to authorized action. The system needs a boundary at that transition.

I also learned that reproducibility isn't just “does the build pass.” It is being able to say exactly which parts are live, historical, or frozen — and then prove that claim from a fresh clone.

What's next

The next step is to make the policy layer as useful as the enforcement layer: LLM-drafted policy candidates, human adversarial review, and a promotion gate that makes it impossible for a generated rule to become governing truth without approval.

Beyond that, I can put additional evidence providers behind the same EvidenceProvider seam and expand beyond shipment release into KYC, e-invoicing, trade finance, mortgage underwriting, and insurance workflows. The architecture is intentionally designed so the trust layer does not have to change every time the evidence source, agent, or regulated domain changes.

I am also building Solvent - https://github.com/PithomLabs/solvent - as a separate project to test the same idea outside documents: a database-enforced boundary between “the AI believes this” and “the AI may act on it.” DocTrust is the regulated-document expression of that pattern; Solvent is the general-purpose expression. The opportunity is bigger than document compliance: make authorization a primitive that AI agents cannot silently inherit from the data they consume.

Why this matters

GhostJacking is the clearest recent warning I know of about where agentic systems are heading: the attacker may not need to break the tool. They can poison the information going into the tool and let the agent perform an otherwise legitimate action. The firewall can work. Authentication can work. The API can work. The agent can still become the attack path.

That is why I think this is a rare window.

Agents are moving from assistants toward systems that can investigate, recommend, and act. Standards for agent-to-tool and agent-to-agent interaction are consolidating, while regulation increasingly emphasizes oversight, traceability, and accountability for high-risk uses. The architectural question I am pursuing is: before a consequential action happens, what evidence supports it, which policy governs it, who is authorized to approve it, and can I prove what happened afterward?

That is the company I am trying to build with DocTrust: an evidence-driven compliance engine between AI capability and consequential action — and, through Solvent, to explore a broader authorization layer for the agentic economy.

The one-line thesis: MCP standardizes how agents reach tools. A2A standardizes how agents reach each other. Solvent explores a complementary layer for how consequential authority could be established, verified, and revoked once agents get there. I am not claiming the industry has adopted Solvent as a third standard; I am building and testing the primitive while the agent ecosystem is still taking shape.

I am not betting that the winning agent will be Hermes, Goose, or any particular model. I am betting that organizations will eventually need to trust many agents — and that the trust layer underneath them will matter more than which model happens to be smartest that year.

My standard for DocTrust is still simple: not “trust me” — try to break it.

Built With

• chatgpt
• claude
• go
• opencode