Keys are stored at ~/.signet/keys/ (override with SIGNET_HOME).

~/.signet/keys/
├── my-agent.key       # Encrypted private key (Argon2id + XChaCha20-Poly1305)
└── my-agent.pub       # Public key (plaintext JSON)

• File permissions: 0600 (owner read/write only)
• Encrypted key file format:

{
  "v": 1,
  "algorithm": "ed25519",
  "name": "my-agent",
  "kdf": "argon2id",
  "kdf_params": { "t": 3, "m": 65536, "p": 1 },
  "salt": "hex...",
  "cipher": "xchacha20-poly1305",
  "nonce": "hex...",
  "ciphertext": "hex..."
}

• AAD (Additional Authenticated Data): Canonical JSON of header metadata (v, algorithm, name, kdf, kdf_params). Tampering with any header field causes decryption to fail.
• Unencrypted mode: --unencrypted flag stores raw key bytes for CI/automation. Use SIGNET_PASSPHRASE env var for automated encrypted key access.

The full receipt body (minus the sig and id fields) is canonicalized via JCS:

canonical({v, action, signer, ts, nonce}) → bytes → Ed25519.sign(bytes)

The id field is derived after signing (rec_ + first 16 hex chars of SHA-256(signature)), so it is not part of the signed payload. Modifying any signed field — tool name, params, timestamp, signer identity, nonce — invalidates the signature.

receipt.id = "rec_" + hex(SHA-256(signature))[0..16]

This provides a short, collision-resistant identifier derived from the signature itself.

Not all receipt fields are inside the Ed25519 signature scope. Building on unsigned fields for security-relevant decisions is unsafe.

The extensions field on BilateralReceipt is deliberately excluded from the server's signature scope. Do not store security-relevant metadata in extensions.

Attack scenario: A developer stores agent identity or trust scores in extensions, then verifies the receipt expecting that data to be tamper-proof. An attacker modifies extensions after signing without invalidating the signature. Any authorization decision based on that data is compromised.

Safe uses for extensions: debugging metadata, display hints, non-security context. Unsafe uses: agent identity, trust scores, authorization claims, policy decisions. These belong in signed fields (action.params, policy, authorization, or a future attestations field).

Each audit record contains a hash linking it to the previous record:

record_hash = SHA-256(canonical({prev_hash, receipt}))

• Genesis: First record uses sha256:0000...0000
• Cross-day: New daily files link back to the last record of the previous day
• Verification: signet verify --chain recomputes every hash and checks continuity

• Audit log is local. An attacker with filesystem access can delete the entire log.
• No remote attestation server (planned for v2).
• Hash chain proves ordering and integrity, not completeness — a compromised agent could skip logging (--no-log).

• Agent key X signed intent to call tool Y with params Z at time T
• The audit log has not been tampered with (hash chain intact)
• Receipts were created by the holder of the signing key

┌─────────────────────────────────┐
│  Trusted (Signet's scope)       │
│                                 │
│  Key generation                 │
│  Signing (client-side)          │
│  Audit log append               │
│  Offline verification           │
└─────────────────────────────────┘

┌─────────────────────────────────┐
│  Untrusted (outside scope)      │
│                                 │
│  MCP server execution           │
│  Network transport              │
│  Agent authorization            │
│  Identity binding               │
└─────────────────────────────────┘

• Zero unsafe blocks in signet-core
• No unwrap() in production code — all errors propagated via ? and SignetError
• 172 tests across Rust (68), Python (85), TypeScript (11), WASM (8)
• CI runs cargo clippy -- -D warnings and cargo fmt --check on every PR

If you discover a security vulnerability, please email security@prismer.ai instead of opening a public issue. We will respond within 48 hours.