The audit log is listed as a core principle:
Audit-quality. Every decision results in a hash-chained, optionally signed log entry, verifiable from outside the agent.
and in v1 scope as "append-only hash-chained audit log with opt-in Ed25519 signing".
The property that phrasing implies is tamper evidence. On a single machine, with the log and the signing key both written by a process running as the same user, that property does not hold. Anything running as that user can rewrite the chain from any point, recompute every hash forward, read the key and re-sign the result. Append-only on a local filesystem is a convention, not an enforcement, and a hash chain only detects tampering when a verifier holds an anchor the tamperer cannot reach.
This may be entirely fine. The threat model already puts "agent process compromise or host OS container escapes" out of scope, so the log's real job is probably post hoc review of what a well behaved but misdirected agent did, which is a genuinely useful thing and does not need cryptographic tamper evidence. But the document should say that, because "verifiable from outside the agent" reads as a stronger claim than the design supports.
The things that would make the strong claim true are all heavier than v1: an anchor published somewhere the agent cannot write, a key held in the Secure Enclave or a TPM or on a hardware token, or a separate privileged writer process. Worth naming as future work rather than implying.
This also answers the key custody open question
Signing Key Custody: Should audit log signing keys be user-held or attested by Nano Collective?
Nano Collective attestation would mean the collective operates key material on behalf of users, which puts it in a custody and liability role and sits badly next to:
Not a hosted control plane or fleet manager.
It also creates the exact dependency the collective's positioning argues against, and there is no funded infrastructure behind it today. User held keys are the answer that matches the project's own principles. If fleet attestation is wanted later, it belongs to whoever runs the fleet, not to NC.
What would help: state what the log defends against and what it does not, say what Ed25519 signing buys when the key is local (mostly: attribution across machines, and detecting accidental corruption), and close the custody question in favour of user held keys with the reasoning recorded.
Raised during the public review window (closes 2026-09-19).
The audit log is listed as a core principle:
and in v1 scope as "append-only hash-chained audit log with opt-in Ed25519 signing".
The property that phrasing implies is tamper evidence. On a single machine, with the log and the signing key both written by a process running as the same user, that property does not hold. Anything running as that user can rewrite the chain from any point, recompute every hash forward, read the key and re-sign the result. Append-only on a local filesystem is a convention, not an enforcement, and a hash chain only detects tampering when a verifier holds an anchor the tamperer cannot reach.
This may be entirely fine. The threat model already puts "agent process compromise or host OS container escapes" out of scope, so the log's real job is probably post hoc review of what a well behaved but misdirected agent did, which is a genuinely useful thing and does not need cryptographic tamper evidence. But the document should say that, because "verifiable from outside the agent" reads as a stronger claim than the design supports.
The things that would make the strong claim true are all heavier than v1: an anchor published somewhere the agent cannot write, a key held in the Secure Enclave or a TPM or on a hardware token, or a separate privileged writer process. Worth naming as future work rather than implying.
This also answers the key custody open question
Nano Collective attestation would mean the collective operates key material on behalf of users, which puts it in a custody and liability role and sits badly next to:
It also creates the exact dependency the collective's positioning argues against, and there is no funded infrastructure behind it today. User held keys are the answer that matches the project's own principles. If fleet attestation is wanted later, it belongs to whoever runs the fleet, not to NC.
What would help: state what the log defends against and what it does not, say what Ed25519 signing buys when the key is local (mostly: attribution across machines, and detecting accidental corruption), and close the custody question in favour of user held keys with the reasoning recorded.
Raised during the public review window (closes 2026-09-19).