---
title: "Assurance Profiles for Agent Ecosystems (APAE)"
abbrev: "APAE"
category: info
docname: draft-apae-assurance-profiles-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
  - dynamic trust
  - assurance
  - behavior verification
  - data provenance

author:
  -
    fullname: TBD
    organization: Independent
    email: placeholder@example.com

normative:
  RFC2119:
  RFC8174:
  RFC7519:
  RFC7518:
  I-D.nennemann-wimse-ect:
    title: "Execution Context Tokens for Distributed Agentic Workflows"
    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
  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/

informative:

--- abstract

This document defines Assurance Profiles for Agent Ecosystems
(APAE): dynamic trust scoring, behavior verification, data
provenance, and graduated assurance profiles that allow the same
agent ecosystem to operate in relaxed (dev/K8s) and regulated
(healthcare, finance) environments.  Trust events are derived from
ECT outcomes.  Trust assertions are ECTs.  Behavior verification
references ECT claims.  Provenance chains are implicit in the ECT
DAG.  Assurance profiles select which combination of these
mechanisms is required for a given deployment, mapping to ECT
assurance levels L1/L2/L3.

--- middle

# Introduction

Identity verifies who an agent is.  ECT records what an agent did.
But neither answers: should I rely on this agent?  Is it doing what
it promised?  Can I trace where this data came from?

APAE adds three capabilities to the ecosystem:

1. **Dynamic trust scoring** — behavioral reputation that adjusts
   based on interaction outcomes (AIMD model).
2. **Behavior verification** — checking agent actions against
   declared specifications.
3. **Data provenance** — tracing data lineage through the DAG.

These three capabilities are bundled into assurance profiles
(relaxed, standard, regulated) that map to ECT assurance levels,
so the same ecosystem works from a dev cluster to a hospital.

# 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.

Trust Event:
: An interaction outcome that causes a trust score adjustment.
  Derived from ECTs.

Behavior Specification:
: A machine-readable declaration of permitted agent actions and
  constraints.

Provenance Chain:
: The sequence of ECT nodes recording how a piece of data was
  produced, transformed, and consumed.

Assurance Profile:
: A named configuration selecting which trust, verification, and
  provenance mechanisms are required.

# Dynamic Trust Scoring {#trust}

## Trust Score Model

Each agent maintains a trust table: peer agent IDs mapped to
trust scores.  Initial trust for unknown agents is deployment-
configured (RECOMMENDED: 0.5; zero-trust: 0.1).

Scores update using additive-increase, multiplicative-decrease
(AIMD):

- Positive event: `score = min(1.0, score + alpha)`
- Negative event: `score = max(0.0, score * beta)`

Defaults: `alpha = 0.01`, `beta = 0.8`.

Trust builds slowly (100 successes: 0.5 → ~1.0) and drops fast
(one failure: 0.82 → 0.66).

## Trust Events from ECT {#trust-events}

Trust events are derived from ECTs rather than agent-local
counters, making trust computation auditable:

| ECT condition | Event | Adjustment |
|--------------|-------|------------|
| Completed, no error follows | `task_success` | +1x alpha |
| Completed, partial result | `task_partial` | +0.5x alpha |
| `atd:error` referencing agent | `task_failure` | 1x beta |
| No response within threshold | `task_timeout` | 1x beta |
| `atd:error` with `constraint_violation` | `policy_violation` | beta^2 |
| ECT signature verification fails | `attestation_invalid` | beta^2 |
| `atd:rollback_request` targeting agent | `rollback_triggered` | 1x beta |
{: #fig-events title="Trust Events from ECT"}

## Trust Decay

If no interaction occurs for a configurable period (default:
7 days): `score = max(initial_default, score - 0.01/day)`.

## Trust Assertions as ECT {#trust-assertions}

Agent A shares its trust assessment via a trust assertion ECT:

- `exec_act`: `"apae:trust_assertion"`

~~~json
{
  "exec_act": "apae:trust_assertion",
  "ext": {
    "apae.subject": "spiffe://example.com/agent/b",
    "apae.trust_score": 0.82,
    "apae.interactions": 147,
    "apae.confidence": "high",
    "apae.hops": 0
  }
}
~~~
{: #fig-assertion title="Trust Assertion ECT"}

Confidence: `low` (<10 interactions), `medium` (10-99),
`high` (100+).

## Trust Propagation

When Agent C receives A's assertion about B:

~~~
c_score_for_b = max(c_score_for_b,
                    a_score * trust_of_a * attenuation)
~~~

Default `attenuation`: 0.5.  Direct observations always take
precedence.  `apae.hops` tracks propagation depth; agents MUST NOT
propagate beyond their configured maximum (default: 1).

## Trust Thresholds as Policy

Trust thresholds are ACP-DAG-HITL node constraints:

~~~json
{
  "constraints": {
    "apae.min_trust": 0.7,
    "apae.min_confidence": "medium"
  }
}
~~~
{: #fig-threshold title="Trust Threshold as Node Constraint"}

Requests from agents below threshold are denied with HTTP 403.

Low trust can trigger HITL escalation:

~~~json
{
  "id": "r-low-trust",
  "trigger": {
    "kind": "confidence_below",
    "op": "lt",
    "value": 0.5,
    "input_ref": "apae.peer_trust_score"
  },
  "required_role": "operator:security",
  "action": "escalate",
  "allow_override": true,
  "override_action": "continue"
}
~~~
{: #fig-trust-hitl title="HITL Rule for Low Trust"}

## Automatic Revocation

When trust drops below a floor (default: 0.2), the trusting agent
SHOULD revoke delegations and emit:
`exec_act: "apae:trust_revoke"`.

# Behavior Verification {#behavior}

## Behavior Specifications

A behavior specification declares what an agent is permitted to do.
Specifications are JSON documents referencing ECT claims:

~~~json
{
  "spec_version": "1.0",
  "agent_id": "spiffe://example.com/agent/firewall",
  "allowed_actions": ["update_rules", "read_config", "report"],
  "constraints": {
    "max_actions_per_minute": 60,
    "forbidden_targets": ["core-router-*"],
    "require_checkpoint_before": ["update_rules"]
  },
  "verification_frequency": "continuous"
}
~~~
{: #fig-spec title="Behavior Specification"}

## Verification Against ECT Stream

A verifier monitors the agent's ECT stream and checks:

1. `exec_act` values are in `allowed_actions`.
2. Action rate does not exceed `max_actions_per_minute` (computed
   from `iat` timestamps).
3. `atd:checkpoint` ECTs precede `update_rules` ECTs (from
   `require_checkpoint_before`).
4. Targets in `ext` claims do not match `forbidden_targets`.

Verification results are ECTs:

- `exec_act`: `"apae:compliance_check"`

~~~json
{
  "exec_act": "apae:compliance_check",
  "par": ["latest-agent-ect-uuid"],
  "ext": {
    "apae.compliance_status": "passing",
    "apae.violations": [],
    "apae.spec_version": "1.0",
    "apae.window": "2026-03-01T12:00:00Z/PT1H"
  }
}
~~~
{: #fig-compliance title="Compliance Check ECT"}

Violations trigger trust score decreases (`policy_violation` event)
and MAY trigger HITL escalation.

# Data Provenance {#provenance}

## DAG as Provenance Chain

The ECT DAG already encodes data provenance: each ECT's `par`
references show which prior tasks produced its inputs.  The
`inp_hash` and `out_hash` claims prove what was processed without
revealing the data.

For deployments requiring explicit provenance metadata, agents
MAY include:

~~~json
{
  "ext": {
    "apae.data_source": "database:patients",
    "apae.data_classification": "pii",
    "apae.retention_days": 365,
    "apae.transformations": ["anonymize", "aggregate"]
  }
}
~~~
{: #fig-provenance title="Provenance Extension Claims"}

## Provenance Queries

At L3, the audit ledger enables provenance queries:

- "Which agents touched this data?" → walk `par` chain from
  final ECT to roots.
- "Was this data transformed?" → check `apae.transformations`
  along the chain.
- "Is provenance complete?" → verify all `par` references
  resolve to ledger entries.

# Assurance Profiles {#profiles}

An assurance profile is a named configuration that selects which
mechanisms are required:

| | Relaxed | Standard | Regulated |
|---|---------|----------|-----------|
| **ECT level** | L1 | L2 | L3 |
| **Trust scoring** | Optional | RECOMMENDED | REQUIRED |
| **Trust threshold enforcement** | Optional | RECOMMENDED | REQUIRED |
| **Behavior verification** | Off | Periodic | Continuous |
| **HITL approval gates** | Optional | Critical paths | Mandatory |
| **Data provenance** | Off | Optional | REQUIRED |
| **Checkpoint before consequential** | RECOMMENDED | REQUIRED | REQUIRED |
| **Audit ledger** | Optional | Optional | REQUIRED |
{: #fig-profiles title="Assurance Profiles"}

Relaxed:
: Internal dev/staging.  L1 ECTs.  Trust and verification
  optional.  Useful for debugging and observability without
  cryptographic overhead.

Standard:
: Production cross-org.  L2 ECTs.  Trust scoring and thresholds
  recommended.  Periodic behavior verification.  HITL on critical
  paths.

Regulated:
: Healthcare, finance, EU AI Act.  L3 ECTs with audit ledger.
  Continuous behavior verification.  All trust mechanisms
  required.  Full provenance chain.  Mandatory HITL gates.

Profiles are declared in ACP-DAG-HITL node constraints:

~~~json
{
  "constraints": {
    "apae.assurance_profile": "regulated"
  }
}
~~~
{: #fig-profile-policy title="Profile as Node Constraint"}

A single deployment MAY use different profiles for different
workflows.

# Security Considerations

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

Trust assertion ECTs MUST be signed at L2/L3.

Score manipulation (building trust then exploiting it): mitigated
by double penalties for `policy_violation` and high thresholds for
critical actions.

Sybil attacks (fake agents inflating trust): mitigated by
attenuation ({{trust-assertions}}), hop limits, and requiring
agents to be registered in a trusted directory.

Behavior specifications could be tampered with.  Specifications
SHOULD be signed and versioned.  Changes MUST be recorded as ECTs.

All trust and verification communications MUST use TLS 1.3.

# IANA Considerations

This document requests registration of `exec_act` values:

- `apae:trust_assertion`
- `apae:trust_revoke`
- `apae:compliance_check`

--- back

# Acknowledgments
{:numbered="false"}

APAE builds on ECT {{I-D.nennemann-wimse-ect}} for interaction
evidence and audit, and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for trust threshold and
assurance profile policy enforcement.  The AIMD trust model is
adapted from TCP congestion control.
