ietf-draft-analyzer/workspace/drafts/new-drafts/draft-dats-dynamic-agent-trust-scoring-00.md

fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com

normative: RFC7519: RFC7515: RFC7518: RFC9110: I-D.nennemann-wimse-ect: title: "Execution Context Tokens for Distributed Agentic Workflows" target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/

informative: I-D.nennemann-agent-dag-hitl-safety: title: "Agent Context Policy Token: DAG Delegation with Human Override" target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

--- abstract

This document defines the Dynamic Agent Trust Scoring (DATS) protocol, a mechanism for AI agents to build, assess, and revoke trust relationships based on observed behavior over time. Static authentication verifies identity but says nothing about reliability. DATS augments identity-based auth with a numeric trust score that adjusts dynamically based on interaction outcomes recorded in the ECT DAG. Trust events are derived from ECT action outcomes rather than agent-local tracking, making trust computation auditable and tamper-evident. Trust assertions are ECTs themselves, and trust thresholds integrate with ACP-DAG-HITL node constraints as enforceable policy.

--- middle

Introduction

The IETF has 98 drafts addressing agent identity and authentication, providing strong mechanisms for verifying who an agent is. But identity alone is insufficient for long-running autonomous systems. A properly authenticated agent may still produce bad results, violate expectations, or degrade over time.

DATS adds a behavioral dimension to trust. It answers: "I know who you are, but should I rely on you?" The model is deliberately simple -- a single floating-point score between 0.0 and 1.0 per agent relationship -- because complex reputation systems tend to be gamed or ignored.

By building on ECT {{I-D.nennemann-wimse-ect}}, DATS derives trust from the cryptographically signed record of actual interactions rather than agent-local counters that can be manipulated. At L3, the audit ledger provides an immutable interaction history.

The protocol is inspired by:

• TCP congestion control: trust increases slowly (additive) and decreases quickly (multiplicative) on failure.
• TLS certificate transparency: trust assertions are logged.
• Web of trust (PGP): trust propagates through intermediaries with attenuation.

Conventions and Definitions

{::boilerplate bcp14-tagged}

Trust Score:

A floating-point value in [0.0, 1.0] representing one agent's assessed reliability of another, based on observed ECT outcomes.

Trust Event:

An observable interaction outcome that causes a trust score adjustment. Derived from ECTs in the workflow DAG.

Trust Decay:

Automatic reduction of trust scores over inactivity, reflecting the principle that trust requires ongoing evidence.

Trust Assertion:

An ECT recording one agent's trust score for another, transportable as a signed token.

Problem Statement

Agent A delegates a task to Agent B. After 100 successful interactions, Agent B starts returning incorrect results (model drift, adversarial manipulation, or degradation). Agent A has no standard way to:

1. Track B's reliability over time.
2. Reduce B's privileges based on degraded performance.
3. Share its experience with Agent C.
4. Automatically revoke B's access when trust drops below acceptable levels.

Existing attestation drafts (STAMP, DAAP) provide cryptographic proof of specific actions but not ongoing behavioral assessment. The ECT DAG records what happened; DATS adds evaluation of whether what happened was good.

Trust Score Model

Each agent maintains a trust table: a mapping from peer agent IDs to trust scores.

{
  "spiffe://example.com/agent/b": {
    "score": 0.82,
    "interactions": 147,
    "last_updated": "2026-03-01T11:30:00Z",
    "last_event_ect": "550e8400-e29b-41d4-a716-446655440099"
  }
}

{: #fig-trust-table title="Trust Table Entry"}

Initial trust for an unknown agent is deployment-configured. A value of 0.5 is RECOMMENDED as a neutral starting point. Zero-trust deployments MAY use 0.1.

Trust scores are updated using additive-increase, multiplicative-decrease (AIMD):

On positive event:

score = min(1.0, score + alpha)

On negative event:

score = max(0.0, score * beta)

Default parameters: alpha = 0.01, beta = 0.8.

This means trust builds slowly (100 successes from 0.5 to ~1.0) but drops quickly (a single failure takes 0.82 to 0.66). This asymmetry is intentional: in autonomous systems, the cost of trusting a bad agent exceeds the cost of slow trust building.

Trust Events from ECT

Trust events are derived from ECTs in the workflow DAG rather than agent-local tracking. This makes trust computation auditable.

Standard Trust Events

ECT condition	Event	Adjustment
exec_act completed, no error ECT follows	task_success	+1x alpha
exec_act completed, partial result	task_partial	+0.5x alpha
aerr:error ECT with par referencing agent	task_failure	1x beta
Timeout (no response ECT within threshold)	task_timeout	1x beta
aerr:error with constraint_violation	policy_violation	beta^2
ECT signature verification fails	attestation_invalid	beta^2
aerr:rollback_request targeting agent	rollback_triggered	1x beta
{: #fig-events title="Trust Events Derived from ECT"}

beta^2 means the multiplicative decrease is applied twice (score * beta * beta), reflecting the severity of policy violations versus simple failures.

Trust Decay

If no interaction (no ECT involving the peer) occurs for a configurable period (default: 7 days), the trust score decays:

score = max(initial_default, score - decay_rate)

Default decay_rate: 0.01 per day.

Agents MUST record all trust events in a local audit log. At L3, the trust events are derivable from the audit ledger, providing independent verifiability.

Trust Assertions as ECT

Agent A shares its trust assessment of Agent B with Agent C via a trust assertion ECT:

• exec_act: "dats:assertion"
• par: empty (trust assertions are standalone) or referencing the most recent interaction ECT

{
  "iss": "spiffe://example.com/agent/a",
  "ext": {
    "dats.subject": "spiffe://example.com/agent/b",
    "dats.score": 0.82,
    "dats.interactions": 147,
    "dats.confidence": "high",
    "dats.hops": 0
  }
}

{: #fig-assertion title="Trust Assertion ECT"}

dats.confidence is based on interaction count: low (<10), medium (10-99), high (100+).

Trust Propagation with Attenuation

When Agent C receives a trust assertion from Agent A about Agent B, it MAY incorporate it:

c_score_for_b = max(c_score_for_b,
                    a_score_for_b * trust_of_a * attenuation)

Where:

• a_score_for_b = A's reported score for B (0.82)
• trust_of_a = C's own trust score for A
• attenuation = constant (default: 0.5)

Trust assertions are advisory. An agent's own direct observations always take precedence over propagated trust.

Anti-Gaming Measures

To prevent trust laundering (colluding agents inflating each other's scores):

• Agents SHOULD limit propagation depth to 1 hop by default
• The dats.hops field tracks depth; agents MUST NOT propagate assertions where dats.hops exceeds their configured maximum
• At L3, trust assertions are recorded in the audit ledger, making collusion patterns detectable through graph analysis

Trust Thresholds as Policy

Threshold-Based Access

Agents SHOULD define trust thresholds per action type:

{
  "thresholds": {
    "read_data": 0.3,
    "execute_task": 0.5,
    "modify_config": 0.7,
    "delegate_auth": 0.9
  }
}

{: #fig-thresholds title="Trust Thresholds"}

When a request arrives, the agent checks the requester's trust score against the threshold. If below threshold, the request is denied with HTTP 403 and error trust_insufficient.

Integration with ACP-DAG-HITL

Trust thresholds can be expressed as DAG node constraints {{I-D.nennemann-agent-dag-hitl-safety}}:

{
  "dag": {
    "nodes": [{
      "id": "n-critical-action",
      "type": "modify_config",
      "agent": "spiffe://example.com/agent/b",
      "constraints": {
        "dats.min_trust": 0.7,
        "dats.min_confidence": "medium"
      }
    }]
  },
  "hitl": {
    "rules": [{
      "id": "r-low-trust",
      "trigger": {
        "kind": "confidence_below",
        "op": "lt",
        "value": 0.5,
        "input_ref": "dats.peer_trust_score"
      },
      "required_role": "operator:security",
      "action": "escalate",
      "allow_override": true,
      "override_action": "continue"
    }]
  }
}

{: #fig-policy title="Trust Policy as DAG Constraints + HITL"}

This means: if the delegated agent's trust score drops below 0.5, escalate to a human security operator before proceeding.

Automatic Revocation

When an agent's trust score drops below a configured floor (default: 0.2), the trusting agent SHOULD:

1. Revoke all outstanding delegations to that agent
2. Produce a revocation ECT (exec_act: "dats:revoke")
3. Emit an error ECT per AERR if the agent was part of an active workflow

Security Considerations

Trust scores are sensitive metadata. Agents MUST NOT expose their full trust tables to peers. Only pairwise trust assertions should be shared intentionally.

Trust assertion ECTs MUST be signed at L2 or L3. Agents MUST verify signatures before processing.

Score manipulation: a malicious agent could behave well to build trust, then exploit it. Mitigation: policy_violation events apply double penalties, and deployments SHOULD set high thresholds for critical actions.

Sybil attacks: an attacker creates many agents for fake positive assertions. Mitigation: attenuation ({{trust-assertions}}), hop limits, and requiring agents to be registered in a trusted directory before accepting assertions.

All trust-related communications MUST use TLS 1.3.

IANA Considerations

This document requests the following IANA registrations:

1. Registration of exec_act values dats:assertion and dats:revoke in a future ECT action type registry.

2. A "DATS Trust Event Type" registry under Specification Required policy. Initial entries: task_success, task_partial, task_failure, task_timeout, policy_violation, attestation_invalid, rollback_triggered.

--- back

Acknowledgments

{:numbered="false"}

This document builds on the Execution Context Token specification {{I-D.nennemann-wimse-ect}} for interaction evidence and the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}} for trust threshold policy enforcement.