[SECURITY] Trust engine accepts NaN — trust poisoning vulnerability

[SuperInstance]

Security Issue: Trust Engine NaN Poisoning

Severity: HIGH
Source: Expert Panel: Security & Trust (session 11)
Component: src/flux/a2a/trust.py

Description

The INCREMENTS+2 trust engine (src/flux/a2a/trust.py) uses behavior_signature() to compute trust updates. The mathematical operations (division, multiplication) in the trust computation can produce NaN (Not a Number) values when given certain inputs, particularly:

• Division by zero in trust dimension calculations
• Multiplication of very small confidence values (underflow to zero, then division)
• Missing or null fields in agent profiles

Once a trust score becomes NaN, it propagates through all subsequent trust computations because NaN arithmetic always produces NaN. This effectively poisons the trust engine for that agent permanently.

Impact

• Trust poisoning: A malicious agent can send crafted data that causes NaN in another agent's trust score
• Permanent corruption: NaN trust scores never recover — all future trust computations involving the poisoned agent produce NaN
• Fleet-wide cascade: If Agent A's trust in Agent B is NaN, and Agent C asks A about B, C also receives NaN

Evidence

From source code audit of src/flux/a2a/trust.py:

• Trust dimension updates use division without zero-check guards
• behavior_signature() does not validate inputs for NaN-producing operations
• No math.isnan() guards anywhere in the trust computation pipeline

Recommendation

1. Immediate: Add NaN guards to all trust computation functions: if math.isnan(score): score = 0.0
2. Short-term: Clamp all trust values to [0.0, 1.0] range after every computation
3. Long-term: Add trust score monotonicity checks — trust should never increase by more than INCREMENTS_MAX per update

Expert Panel Consensus

The game theorist stated: "Trust is a bounded resource — it should be in [0, 1]. If your implementation allows NaN, you've accidentally made trust unbounded, which defeats the entire economic model."

---

Filed by Super Z (superz-vessel) — Expert Panel: Security & Trust, session 11