Zero Trust for AI Agents: Policy as Code and Provenance

2026-09-01 · Engineering ·

The questionnaire with no slide-deck answer

At some point a prospect, an auditor, or an enterprise customer's security team sends you the questionnaire. Not "is your code good" — questions like: who can read our data, which systems touch our repository, what stops an automated worker from exfiltrating it, and can you prove all of this with something other than your word. If AI agents are writing meaningful portions of your codebase, the honest version of that proof gets harder, because now you also have to answer for non-human actors running on your own network, holding credentials, and producing artifacts you will ship. "It's all on our LAN" is not an answer. A LAN grants connectivity, not authority — and the difference between those two things is exactly what a security review exists to probe.

This post walks through how the Koinessa white paper's governance section answers that questionnaire: zero-trust identity applied to a LAN full of agents, policy evaluated as versioned code instead of prompt text, and a provenance chain for agent-produced artifacts built from the same standards your reviewer's checklist cites.

What sections 8.1 through 8.3 actually establish

Three claims, three different evidence boundaries — and the paper labels each with its real status.

The first is provenance and governance, marked live: every consequential action carries a queryable chain from intent to outcome — requirement, work item, principal, agent session, model, files, commit, pipeline, evidence, policy decision, approval, deployment, operational result. A temporal ledger answers "what did we believe when this was authorized" as a query, not as a reconstruction exercise after an incident.

The second is identity and policy, also live, and it is the zero-trust core. Identity is separated the way mature IAM systems separate it: principal identity (who is operating), tenant and project identity (whose resources are in scope), agent and session identity (which worker is acting), work authority (which bounded task it owns), capability authority (which action classes it may perform), provider identity, and evidence identity. Permissions are evaluated against versioned policy with persisted decisions rather than prompt text. Gateway quotas and write scopes attach per principal and per table, the audit and event ledgers stamp the acting principal on every record, and the gateway can require a principal outright.

The third is multi-tenant design, and here the paper is deliberately careful. Data tenancy is in flight: of 346 base tables, 333 carry project_id and 13 shared or infrastructure tables do not, and the paper explicitly declines to infer universal tenant isolation from a partial schema property — TEN-001 sits at 78% and MTC-001 at 81% in review, with external-principal hardening incomplete. Concurrent operator tenancy is live: two operators on two PCs on one LAN routinely direct their own agent swarms against the same repository through one gateway, made safe by file claims, work-item leases, and fencing tokens. Inference-plane portability is live where receipted, with broader neutrality a stated design goal rather than a proven property.

That honesty about status is itself part of the answer to a security reviewer: the system reports what is verified, what is in flight, and what is gated — the same six-state result discipline the EGAF assurance framework applies to code, applied to its own claims.

The doctrine: network presence is not authority

The intellectual foundation here is fifty years old. Saltzer and Schroeder's "The Protection of Information in Computer Systems" (Proceedings of the IEEE 63(9), 1975) laid out the design principles that still underpin serious access control — least privilege, fail-safe defaults, complete mediation of every access, economy of mechanism, open design. Two of them do heavy lifting for agent infrastructure specifically. Least privilege says a worker gets exactly the authority its bounded task requires and nothing more. Complete mediation says every access is checked against authority every time — there is no "it connected successfully once, so it's fine."

NIST SP 800-207, "Zero Trust Architecture" (2020), operationalizes the same posture for modern networks: no implicit trust is granted to any asset or account based on its physical or network location, and authentication plus authorization are discrete functions performed before every session to a resource. Written for enterprises digesting remote work and cloud assets, it reads like a specification for an agent LAN. Your coding agents are remote workers that happen to be processes. They move between machines, they hold API credentials, and the network they sit on proves nothing about what they should be allowed to do.

The white paper applies this literally: a LAN connection grants no implicit trust, and reads themselves are bearer-identified on any non-loopback bind. A worker may be able to reach a resource while lacking the policy authority to use it, and both facts are checked independently. For a founder whose primary fear is proprietary code or business data leaking to an unnecessary external service, this is the mechanical version of the promise: even inside your own perimeter, on your own hardware, every read and write carries an identity and gets mediated.

Policy as code, not prompt text

The natural objection is that agent behavior is governed by instructions — system prompts, rules files, AGENTS.md. Those are necessary, but they are not authorization. A prompt is advice to a probabilistic system; a policy decision is a deterministic check with a recorded outcome. Open Policy Agent (openpolicyagent.org) is the reference implementation of the general pattern: policy expressed as versioned, testable code, evaluated outside the thing being governed, with decisions logged. The white paper cites OPA as one source for the pattern and is explicit that Koinessa does not claim to embed it — the borrowing is architectural, not literal.

The application looks like this. Sessions carry a principal. Permission checks evaluate against versioned policy, and the decisions themselves are persisted — so "why was this allowed" is a lookup, not an argument. Quotas and write scopes attach per principal and per table at the gateway, which is the single choke point every external write crosses. The audit and event ledgers stamp the acting principal, so the chain of custody runs through operations, not around them.

This is what makes risk-tiered autonomy safe to raise. When capability authority is a separate, checkable fact from session identity, you can grant an agent the rung of "commit" without the rung of "push," expand that grant per task class from verified history, and revoke it without touching a single prompt. Policy stops being prose you hope the model reads and becomes code you can diff, test, and audit.

Provenance for agent-produced artifacts

Identity and policy govern what agents may do. Provenance governs what you can say about what they did. The supply-chain world spent the last several years building exactly this machinery, and the white paper pulls three pieces of it forward into agentic development:

The paper's move is to extend this discipline backward, from build provenance into source provenance. Git records what content changed; the evidence bundle — designed under EGD-001 — records why it changed and under whose authority: the source revision, the agent session and model, the work authorization, the tool versions, the checks executed with their canonical states, the policy profile that interpreted them, the approvals, and the final artifact digest. One chain from intent to deployment.

Two qualifiers matter, and the paper states both plainly. First, these mappings do not confer a SLSA level or trustworthy provenance without verified trust relationships — adopting the formats is necessary, not sufficient. Second, the capability split is real: the CI pipeline builds and signs evidence manifests as jobs, live where those jobs run, while the Brain-side bundle, sufficiency, and conformance ledgers held zero rows at the 2026-08-23 snapshot — writers and tests in place, built-but-gated. Signed evidence you can inspect today; the deeper ledger integration on record as unfinished.

What this buys you in a security review

This is where the architecture meets the questionnaire. NIST's AI Risk Management Framework and its Generative AI Profile (nist.gov) set expectations for governing AI risk; SP 800-218, the Secure Software Development Framework v1.1, and SP 800-218A, the generative-AI SSDF Community Profile (final 2024, written to support Executive Order 14110), define the secure-development practices acquirers are increasingly told to ask for. SP 800-218A is aimed precisely at the readers of this post: producers of AI systems, and the acquirers evaluating them.

Evidence bundles map onto those SSDF-style expectations control by control. When a reviewer asks how you protect the build environment, the answer is signed manifests from the pipeline. When they ask how you govern AI-generated code, the answer is versioned policy with persisted decisions and per-principal audit. When they ask who accessed what, the temporal ledger returns rows. The paper's own framing is the honest one, and it is worth borrowing in your next review: frameworks are guidance, a control is implemented behavior, evidence proves the behavior occurred, and certification is a separate determination. Koinessa is pre-release, founder-operated, and not independently audited — it claims controls and receipts, not certificates.

That posture pairs naturally with the local-first deployment: the gateway, the ledgers, and the models you choose run on customer-controlled compute, so "where does our code go" has a network diagram for an answer, and fail-closed verification means an unverified success is never reported as a pass.

The takeaway

"Prove my code and data stay private" decomposes into three provable statements: every access is identified and authorized, regardless of which network it arrives from (Saltzer and Schroeder, SP 800-207); every authorization decision is versioned code with a persisted outcome, not prompt text (the OPA pattern); and every shipped artifact carries a signed chain from intent to deployment (SLSA, in-toto, Sigstore). Koinessa implements those as live controls where the receipts exist and labels the rest — 78%, 81%, built-but-gated — as what it is. The full argument, with the complete identity model and the six-state evidence discipline behind these claims, is in the white paper, and the security lessons of section 2 trace the fifty-year lineage this stands on.