The trust_required decorator is missing a crucial security step: signature verification. The README.md mentions an X-Agent-Signature header, but the middleware does not read or validate it. Without signature verification, an agent can be impersonated by simply sending its public DID and public key, which defeats the purpose of a cryptographic trust layer. The request body (or a digest of it) should be signed by the calling agent's private key and verified here using its public key.

The X-Agent-Signature header is documented as optional, but the current implementation in middleware.py does not process it at all. For a robust trust layer, verifying the request signature is critical to prevent impersonation and ensure message integrity. Please consider implementing the signature verification logic.

The except (InvalidSignature, ValueError, Exception): clause is too broad. Catching the generic Exception can hide unrelated bugs and make debugging difficult. It's better to catch only the specific exceptions you expect from the cryptographic operations, such as InvalidSignature and ValueError. This ensures that unexpected errors are not silently swallowed.

The _peer_has_capability method duplicates the logic found in CMVKIdentity.has_capability. To adhere to the DRY (Don't Repeat Yourself) principle and avoid potential inconsistencies, this logic should be refactored into a single, reusable utility function. This function could be a static method or placed in a shared utility module.

logger.info(f"...") will violate the repo’s Ruff rule G004 (no f-strings in logging calls). Use logger interpolation (e.g., %s args) instead so lint passes.

TrustManager is documented as thread-safe, but _log_audit mutates _audit_log (append + trimming) without holding _lock. This can race with get_audit_log() and lead to inconsistent/lost entries. Acquire _lock inside _log_audit (and keep trimming under the same lock) to make the thread-safety guarantee true.

verify_workflow_step() reads _trust_scores without holding _lock, even though other accesses are locked. This breaks the “thread-safe” guarantee and can race with record_success/record_failure. Read the score under _lock (and ideally log the audit entry under the same lock).

verify_peer() currently treats peer_did, peer_public_key, and X-Agent-Capabilities as self-asserted inputs and does not perform any cryptographic proof (e.g., request signature) that the caller controls the claimed key/DID. With the current scoring logic, any non-empty public key gets a passing default score (0.6), so this can be bypassed if used for authorization. Implement signature verification (e.g., X-Agent-Signature over canonical request data) and validate DID↔public-key binding, or avoid reporting the peer as “verified” without cryptographic proof.

The verification cache is keyed only by peer_did. A caller can reuse a cached “verified” result by replaying the same DID with a different X-Agent-Public-Key, which becomes especially dangerous once real signature verification is added. Include the public key (and/or a key fingerprint) in the cache key, or ensure the provided public key matches what was previously verified before returning the cached result.

Audit log and trust scores are stored only in in-memory process state (_audit_log, _trust_scores). In a typical multi-worker / multi-instance deployment, this will not be shared across workers and will be lost on restart, which undermines the “compliance audit logging” and trust scoring features. Consider persisting these to a shared store (DB/Redis/logstore) or clearly document that this is best-effort / dev-only.

This introduces a new security-adjacent decorator/middleware path, but there are no tests covering header parsing, permissive vs strict mode, capability enforcement, and response status codes. Add unit tests for trust_required / TrustMiddleware.require_trust (and core TrustManager.verify_peer behavior) to prevent regressions.

PR description claims “cryptographic identity and trust verification”, but the README notes that request signature verification (X-Agent-Signature) is not implemented/enforced by the middleware yet. Either implement signature verification as part of this PR, or adjust the PR description/wording so it doesn’t overstate the current security properties.

This fallback for key generation is insecure. It uses parts of a SHA256 hash as a 'private' and 'public' key, which is not a valid asymmetric key pair and provides no real security. This could create a false sense of security. The cryptography library should be a required dependency. If it's not available, this method should raise an error. A similar issue exists in the sign method's fallback.

The verify_peer method does not perform any cryptographic signature verification to confirm the peer's identity. It relies on headers (X-Agent-DID, X-Agent-Public-Key) that can be easily spoofed. This allows an attacker to impersonate any agent, undermining the security of the trust layer. While the README mentions that X-Agent-Signature verification is a TODO, this is a critical security gap that should be addressed to make this a true 'Trust Layer'.

Using time.time_ns() as the main source of entropy for the DID seed can lead to predictable DIDs, especially if identities are generated in quick succession. For generating unique identifiers, it's better to use a cryptographically secure source of randomness. Consider adding secrets.token_hex(8) to the seed (you'll need to import secrets).

Manually truncating the audit log list like this can be inefficient for large logs, as it creates a new list slice in memory. A more idiomatic and performant approach for a fixed-size log is to use collections.deque with a maxlen. You would need to change the type of _audit_log in __init__ to deque(maxlen=10000) and then you can remove this block.