Add persistent cryptographic agent identities

[coreytshaffer]

Add persistent cryptographic agent identities

Summary

Add persistent agent identities backed by cryptographic signing keys so TriageCore can attribute important control-plane and audit-ledger actions to known, authorized agents.

This should make agent activity inspectable and tamper-evident without granting agents unchecked autonomy.

Motivation

TriageCore is developing into a local-first control plane for task routing, scoped delegation, validation, and human approval. As the system grows from a single workflow into a council of workers, the audit ledger should be able to answer:

• Which agent performed this action?
• Was that agent authorized to perform this action?
• Was the payload changed after the event was recorded?
• Was the signing key active, revoked, or unknown?
• Did this event come from a local trusted component or an external/cloud worker handoff?

Persistent cryptographic identities provide accountable continuity for agents while preserving human approval gates.

Proposed design

Introduce a lightweight identity and signing layer.

AgentIdentity

Fields:

agent_id: str
role: str
public_key: str
public_key_fingerprint: str
created_at: str
status: str
capabilities: list[str]

AgentKeyStore

Responsibilities:

• Initialize local signing keys for named agents
• Store public identity metadata in a trackable registry
• Store private key material locally only
• Support revocation
• Support later key rotation

SignedLedgerEvent

Fields:

event_type: str
agent_id: str
payload_hash: str
previous_event_hash: str | None
timestamp: str
signature: str

Recommended first algorithm: Ed25519 using a mature Python crypto library.

Initial agents to consider

• ContextPlanner
• Implementer
• ValidatorTools
• LLMReviewWorker
• ProjectSteward
• Optional local supervisor/controller identity

Initial signed events

Start narrow:

• taskpacket_created
• route_decision
• route_audit
• validation_result
• project_steward_decision

Acceptance criteria

• TriageCore can initialize persistent local identities for core agents.
• Each identity has an agent ID, role, public key fingerprint, status, and capability list.
• Private key files are excluded from git.
• Public identity metadata can be safely committed or inspected.
• Ledger events can be signed by an agent identity.
• Signed events can be verified against the registered public key.
• Tampering with a signed event payload causes verification to fail.
• Unknown agent IDs fail verification.
• Revoked agent IDs fail verification.
• Events outside an agent’s declared capability set fail authorization checks.
• No private key material is written to prompts, TaskPackets, logs, cloud handoffs, CLI output, or audit output.
• Tests cover success, tampered payload, unknown agent, revoked agent, and unauthorized capability cases.

Non-goals for the first implementation

• No public blockchain.
• No agent self-sovereignty.
• No remote key custody.
• No automatic cloud trust.
• No bypass of existing human approval gates.
• No signing of raw sensitive prompt/data content.

Security notes

The identity system proves only that a known local component signed a specific event. It does not prove that the event is correct, safe, or approved.

Verification must remain separate from:

• human review
• privacy scanning
• validation
• approval gates
• route policy enforcement

Private key material must remain local and gitignored. Cloud workers should receive only scoped task envelopes and should never receive local private keys.

Implementation notes

A minimal MVP could add:

1. Identity registry under:

.triagecore/identity/agents.json

2. Local gitignored key directory under:

.triagecore/identity/keys/

3. Signing helper:

sign_event(agent_id, payload)

4. Verification helper:

verify_event(event)

5. CLI smoke command for initializing and verifying identities.

6. Unit tests proving:

• valid signature passes
• tampered payload fails
• unknown agent fails
• revoked agent fails
• unauthorized capability fails

This should integrate with the existing audit ledger rather than replacing it.

Future stretch goal: Post-Quantum Cryptography support

Design the identity and ledger-signing layer to be crypto-agile so TriageCore can later support post-quantum signature algorithms without redesigning the audit model.

Initial implementation should use Ed25519 for simplicity and maturity, but identity records and signed ledger events should include explicit algorithm metadata.

Example:

{
  "agent_id": "tc-agent-validator-01",
  "role": "ValidatorTools",
  "key_algorithm": "ed25519",
  "public_key_fingerprint": "sha256:..."
}

[coreytshaffer]

Resolved as MVP-complete.

The persistent cryptographic identity foundation is now implemented:

• AgentIdentity records stable agent ID, role, public key, key algorithm, public key fingerprint, created timestamp, status, and capabilities.
• AgentIdentityRegistry initializes local Ed25519 identities, persists public metadata, keeps private key material local, supports revocation, and checks identity/key consistency.
• Private key material is excluded from git via .triagecore/identity/ and *.key.
• Payload signing and verification enforce payload hash integrity, algorithm metadata, unknown-agent failure, revoked-agent failure, and capability authorization.
• route_audit has a signed ledger smoke path and verification support.
• CLI support exists for tc identity init/list/revoke/check, tc audit --signed-smoke-test, and tc audit --verify-signatures.
• Tests cover success, tampering, unknown agent, revoked agent, unauthorized capability, private-key non-leakage, rollback behavior, key permissions, and signed route-audit verification.

Closing this issue as the identity foundation MVP.

Follow-up work should be tracked separately:

1. Expand signed ledger event coverage beyond route_audit.
2. Implement runtime key rotation behavior if/when the system needs live rotation rather than documented recovery policy.

A valid signature remains provenance evidence only. It does not imply safety, correctness, approval, or authority escalation.