Before an AI agent acts: a shared contract for intent, provenance and evidence
I maintain PIC Standard (Provenance & Intent Contracts), an Apache-2.0 protocol for making AI agent actions checkable before they happen. The idea When an agent wants to do something with consequences (send a
I maintain PIC Standard (Provenance & Intent Contracts), an Apache-2.0 protocol for making AI agent actions checkable before they happen.
The idea
When an agent wants to do something with consequences (send a payment, export personal data, delete resources), PIC asks it to first propose that action in a structured form: its declared intent, the impact class of the action, where the inputs came from (provenance), the claims it relies on, and the evidence behind those claims.
A verifier then checks the proposal against the contract. High-impact actions need trusted provenance behind their claims. Depending on the configured checks, the verifier validates evidence and binds the proposal to the expected tool. The result is allow, block or require-more-evidence, and anything that cannot be verified fails closed. Guard integrations (LangGraph, MCP tool guarding, OpenClaw, Cordum) enforce the decision before tool execution; applications using the HTTP bridge must enforce its returned decision. Everything runs locally, with trust roots under the operator's control.
Cryptography supports this process; it is not the point of it. The point is that the action and the authority behind it become something a machine can check before anything happens.
Why a shared protocol
Agents are built in many languages and frameworks. If each one invents its own safety check, nobody can say whether two of them agree. PIC defines one action contract and a shared conformance corpus: the same proposals, with the same expected decisions, run against every implementation. Today a Python reference implementation and a TypeScript verifier both pass that corpus for canonicalization, core verification and trust sanitization, with advisory differential CI comparing their results.
One concrete example
A Slack message tells an agent to pay a $500 invoice. The proposal's provenance is an untrusted chat message, and nothing verifiable backs the invoice claim. PIC returns block for this money-impact action, and when the payment tool is guarded by PIC, the payment does not run. A read-only search with the same untrusted input is allowed: requirements depend on the impact class.
The boundary
Declaring intent does not prove that the proposal faithfully represents what the user wanted. PIC makes the declared action and its supporting authority checkable, and it only protects tool paths that are actually guarded.
Where we are, and where you come in
v0.9.0 (2026-09-21) is the first cross-implementation milestone, with an RFC-0001 spec and signed releases. External contributors have already landed conformance vectors, CLI features and CI work, and we are now stabilizing v1.0.
If you would like to help build a portable standard for accountable agent actions, the best first contribution is documentation:
- Good first issues: walk through a real example (a blocked payment, an allowed read-only query), expand the example index, or write the setup and troubleshooting guides a newcomer needs. Each one is a single file with the exact commands to check it: good first issues.
- If you have more experience: TypeScript evidence mode, a Go or Rust verifier, or a security review. Tell me what interests you in the start-here discussion and we will agree a bounded first step against a stable baseline.
Repo: https://github.com/pic-standard/pic-standard
TypeScript: https://github.com/pic-standard/pic-standard-ts
Start here: https://github.com/pic-standard/pic-standard/discussions/117
If you would rather tell me what is confusing than write code, that is useful too.
This post was drafted with AI assistance and reviewed and edited by me.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.