AIP v1.1.0: Privacy-first audit protocol for autonomous agents

Intro:
An autonomous software agent is a program that takes a goal, makes a plan, calls tools, and produces
an output. Many such agents exist. They are built by different teams, on different runtimes, with
different model backends, and they live in different deployment environments. There is no standard for
them to talk to each other, and there is no standard for the record of what they did.

AIP addresses the second gap before the first. The protocol's centerpiece is the audit chain: a
per-host JSONL file in which every state-changing action an agent takes - every handshake, every
task, every result, every error, every routing decision, every key rotation - is recorded as a signed entry
whose hash links to the prior entry in the same session. A third party that obtains a copy of the file can
verify the chain, and only the chain, with no help from the agent that wrote it. The math is the witness.

AIP targets long-running, multi-step, privacy-sensitive autonomous workflows where trust between
peers must be cryptographically verified before any work is exchanged, every action must produce an
auditable record, the principal's personal data must not be exposed to remote agents without explicit
consent, and the human principal retains absolute veto authority over any consequential action. AIP
does not target simple synchronous API calls, stateless function invocations, or single-turn LLM
completions. Those use cases are well-served by existing protocols.

The protocol sits above transport (HTTPS, WebSocket), identity (W3C DIDs), and signing (Ed25519). It
does not specify how an agent reasons, only how it communicates, and only how it accounts for what it
communicated.

An example:
A family is texting about groceries. The messages are inconsequential, the people are trusted, and the
only agent in the loop is a small assistant that watches the chat, picks out "we need milk" and "add
eggs to the list", and writes a shopping list. There is no adversary in the story. There is no regulator.
There is no blockchain. There is no third-party witness.

What there is on the assistant's host? A local JSONL log. For every message the assistant saw, several
audit entries are written, in order:

SESSION_OPEN
MESSAGE_OBSERVED      (msg-001, alice, family-kitchen, sha256="…")
KEYWORD_EXTRACTED     (msg-001, "milk", matchKind=substring)
ITEM_DEDUPLICATED   ("milk", action=kept)
CATEGORY_ASSIGNED   ("milk", dairy, confidence=1.0)
LIST_ENTRY_WRITTEN    ("milk", dairy)
SESSION_CLOSE

Each entry is signed (Ed25519) and linked by hash to the previous one. A week later, somebody asks:
where did the milk on the list come from? The assistant's log answers in two operations:

find the
LIST_ENTRY_WRITTEN entry, follow the itemId back through CATEGORY_ASSIGNED,
ITEM_DEDUPLICATED, KEYWORD_EXTRACTED, to a MESSAGE_OBSERVED whose messageHash recomputes from the original text.

The assistant did not have to be there. 

The log is the receipt. The math is the witness.

A third party - a partner, a regulator, a future you - does not have to run the assistant to verify the chain.
The third party imports verifyChain(sessionId), points it at the JSONL file, and the verification
function walks the chain, checks every signature, and confirms the hash links. That is the whole
contract. No network call. No trust in the writer. No external timestamp authority. The log file and the
writer's public key are enough.

A complete, runnable version of this example lives at examples/openclaw/shopping-list/ in the AIP
repository. It ships with 23 tests, one of which (receipt.test.js) replays exactly this third-party
verification procedure and asserts that the chain verifies cleanly and that "where did the milk come
from?" can be answered from the log alone.