Trusted Agent: end-to-end trust establishment for mesh participation

[arkavo-com]

Summary

Cross-cutting feature: agents must complete a 6-phase trust chain before participating in the Arkavo mesh. Today, agents can join with zero verification.

Trust Chain Phases

Phase	Name	Crate	Status
1	Device identity establishment	arkavo-device-identity	Primitives exist (key gen, persistence)
2	Platform attestation	arkavo-attestation	Metadata collection exists, not cryptographically signed
3	Orchestrator registration	arkavo-protocol (registration)	Challenge-response exists, no attestation verification
4	Agent authentication	arkavo-agent-auth	JWT token flow exists, capabilities not enforced
5	Config encryption	arkavo-config-encryption	OpenTDF encryption exists, KAS partially stubbed
6	Config transport & activation	arkavo-config-transport	Transport envelope exists, client fetch stubbed

Spec

Defined in specs/arkavo-edge/trusted-agent.spec.yaml — 7 scenarios, all wip.

Key gaps to close

• Attestation must be cryptographically bound to device identity key
• Registration must verify attestation evidence
• Auth tokens must enforce capabilities (not just store them)
• message/send RPC must require valid auth token
• mDNS discovery must verify agent identity
• Config application must actually load policy into runtime

Composed specs

• device-identity.spec.yaml (Phase 1)
• attestation.spec.yaml (Phase 2)
• registration.spec.yaml (Phase 3)
• agent-auth.spec.yaml (Phase 4)
• config-encryption.spec.yaml (Phase 5)
• config-transport.spec.yaml (Phase 6)

🤖 Generated with Claude Code

[arkavo-com]

Review Feedback (from spec author)

Good refinements

• Schema conformance (feature/module/version/scenarios with given/when/then/refs/edge_cases/changed) makes this machine-validatable against schema.json — original draft was standalone format
• Dropping KeyStorageProof as Phase 1 output avoids over-specifying before platform APIs are known
• SEC-TA-004 names OpenTDF explicitly — a real implementation decision, not hand-waved
• Edge cases on scenarios (TA-002 stale-evidence/missing-binding, TA-007 cached-token-revalidate) catch bugs in implementation, not just happy paths

Gap identified: stale policy during initial establishment

Window exists between Phase 3 (registration) and Phase 5 (config encryption) where orchestrator policy could be updated. Agent could receive a config bundle built from a superseded policy version.

Decision: Policy staleness is resolved at next trust refresh. Given the one-way ratchet invariant (runtime adaptation may tighten but never loosen beyond Phase 6 baseline), a stale policy can only be more permissive than current — the next refresh cycle tightens it. Added explicit note to Phase 5 in the spec.

🤖 Generated with Claude Code