Protocol Overview: Agentic Identity & Responsibility

This overview consolidates the current repository into one compare-ready narrative. It is designed to answer: what the protocol claims, how it works, where responsibility is enforced, and what exists today in this repo.

Table of Contents

1. Executive Snapshot
2. Core Architecture (Identity → Delegation → Audit)
3. Governance and Judiciary Model
4. Terms, Liability, and Slashing
5. Forensic Accountability and Backtracking
6. Developer Integration Path
7. Launch Readiness and Roadmap State
8. Implementation Surface in This Repo
9. Comparison View: Current State vs Intended Protocol
10. Open Questions and Suggested Next Moves

1. Executive Snapshot

The current protocol vision is a hardware-anchored trust stack for autonomous agents:

• Identity is bound to silicon (TPM/TEE), not usernames or API keys.
• Delegation is cryptographically wrapped through Shield-MCP semantics.
• Every meaningful action is expected to carry signed evidence and intent metadata.
• Disputes are resolved via deterministic verification and judiciary scoring.
• Penalties can escalate to physical identity revocation (hardware blacklist).

In practical terms, this repo currently reads as a design and operating doctrine with selective proof-of-concept code snippets, not yet a full runnable platform.

2. Core Architecture (Identity → Delegation → Audit)

2.1 Identity Layer

The system roots trust in TPM-derived keys and measured boot/PCR state:

• The protocol rejects purely software identity for high-trust participation.
• Agent trust state depends on cryptographic attestation continuity.
• Any substantial runtime drift (e.g., guardrail tampering) should invalidate trust.

2.2 Delegation Layer

Delegation is framed as MCP with hardened wrapper semantics:

• Session-scoped keying and parent-child causal links are core concepts.
• Intent declarations are expected before critical tool invocation.
• Evidence packets should couple result hashes, timing, and environment metadata.

2.3 Audit Layer

Audit combines cryptographic verification and semantic review:

• Fast checks validate signature authenticity and policy conformance.
• Deep checks replay context to evaluate logic quality and intent-action alignment.
• Output is meant to feed reputation updates and potential revocation actions.

3. Governance and Judiciary Model

The governance model introduces a dedicated Judge layer with explicit anti-collusion controls:

• Strict Judge eligibility (security profile + reputation prerequisites).
• Blind/randomized assignment and conflict-of-interest filtering.
• Structured penalties from warning-level score loss up to total revocation.
• Appeals route to human-in-the-loop adjudication for contested outcomes.

This is notable because governance is treated as a first-class protocol subsystem, not an afterthought.

4. Terms, Liability, and Slashing

The ToS material defines accountability aggressively:

• Signed output is attributable to the provider (non-repudiation stance).
• PCR and integrity violations trigger immediate trust degradation/termination.
• “Logic negligence” formalizes semantic failure cases, not only security breaches.
• Severe abuse can invoke irreversible hardware-level blacklisting.

This creates a tight coupling between technical controls and legal/commercial responsibility.

5. Forensic Accountability and Backtracking

A major strength of this doc set is recursive forensic logic:

• Intent-action binding adds inspectable rationale to the execution trace.
• Deterministic verification is positioned as the canonical dispute primitive.
• Hash-linked delegation enables responsibility tracing across multi-agent chains.
• Two-speed scoring separates mechanical integrity from outcome quality.

The protocol therefore targets both “was this authentic?” and “was this sensible?”.

6. Developer Integration Path

The developer guide prescribes a fairly clean adoption flow:

1. Prepare TPM/TEE-capable environment.
2. Wrap existing MCP tools with trusted middleware.
3. Register attestation material with the identity registry.
4. Receive reputation updates via periodic platform root sync.
5. Accept that revocation and kill-switch rules are enforceable.

The onboarding narrative is coherent, though implementation details are still mostly reference-level.

7. Launch Readiness and Roadmap State

The 30-day roadmap has clear sequencing:

• Phase 1: Identity roots and SDK primitives.
• Phase 2: Pilot onboarding and handshake realism tests.
• Phase 3: Judiciary rollout, revocation drills, and transparency publication.

As of current repo content, this remains a planning-state roadmap rather than a completed milestone report.

8. Implementation Surface in This Repo

What exists now

• Comprehensive conceptual/technical policy docs.
• POC-style Python snippets in Shield and audit docs.
• TPM command appendix and schema sketches.
• Brutalist web pages generated from markdown for browsing and comparison.

What does not yet exist (in this repo)

• Production identity registry service code.
• End-to-end signed workflow implementation with persistent storage.
• Live judge orchestration and replay service binaries.
• Automated conformance test suite for protocol guarantees.

9. Comparison View: Current State vs Intended Protocol

10. Open Questions and Suggested Next Moves

Open questions

• What is the exact authoritative schema for all signed envelopes and replay manifests?
• Which components are trusted central services vs decentralized verifiers in v1?
• What minimum evidence is legally sufficient for final adjudication?

Suggested next moves

1. Freeze a canonical protocol schema (initialize, tools/call, evidence packet, verdict packet).
2. Build a minimal runnable reference stack (registry + signer + verifier + replay worker).
3. Add conformance tests for intent-action binding and replay determinism.
4. Publish a versioned compatibility matrix for clients and agents.