---
title: "Dynamic Agent Trust Scoring (DATS)"
abbrev: "DATS"
category: std
docname: draft-dats-dynamic-agent-trust-scoring-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
  - dynamic trust
  - reputation
  - agentic workflows
  - execution context

author:
  -
    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 {#trust-model}

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

~~~json
{
  "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}

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 {#trust-assertions}

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

~~~json
{
  "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 {#trust-policy}

## Threshold-Based Access

Agents SHOULD define trust thresholds per action type:

~~~json
{
  "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}}:

~~~json
{
  "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.