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

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

normative:
  RFC2119:
  RFC8174:
  RFC7519:
  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/
  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:
  RFC9334:

--- abstract

This document defines Assurance Profiles for Agent Ecosystems
(APAE): dynamic trust scoring, behavior verification, data
provenance, cross-domain trust, 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.  Agents
whose trust falls below a floor are quarantined via a protocol
defined here.

--- 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 four 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.
4. **Cross-domain trust** — federating trust across administrative
   domains.

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

Trust Domain:
: An administrative boundary within which a single trust anchor
  (CA or JWK set) governs agent identity.

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.

Quarantine:
: A state in which an agent's trust score has dropped below a
  configured floor; the agent is prohibited from accepting new
  delegations.

# 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 deployments: 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 assertion ECTs MUST be signed at L2/L3.

## 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 MUST be denied with HTTP 403.
The `apae.peer_trust_score` is a runtime context value derived
from the trusting agent's trust table for the requesting peer;
it is not an ECT claim itself.

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"`.

# Quarantine Protocol {#quarantine}

When a trust score drops below the configured quarantine floor
(default: 0.15), the agent enters quarantine.

## Quarantine Entry

The detecting agent MUST emit a quarantine ECT:

~~~json
{
  "exec_act": "apae:quarantine",
  "ext": {
    "apae.subject": "spiffe://example.com/agent/b",
    "apae.score": 0.12,
    "apae.threshold": 0.15,
    "apae.quarantine_until": "2026-03-02T12:00:00Z",
    "apae.reason": "Repeated policy_violation events (3 in 1 hour)"
  }
}
~~~
{: #fig-quarantine title="Quarantine ECT"}

The quarantine ECT MUST be broadcast to all agents that have
received trust assertions about the quarantined agent
(via `apae:trust_assertion` with matching `apae.subject`).

## Quarantined Agent Behavior

While quarantined, a subject agent:

- MUST NOT accept new delegations.  New delegation requests MUST
  return HTTP 503 with `Retry-After` set to `apae.quarantine_until`.
- MUST complete in-progress workflows (drain behavior per AEPB).
- MAY accept direct operator commands (HITL Level 4 is unaffected).

Agents receiving the quarantine notification MUST update their
trust table and MUST NOT delegate new tasks to the quarantined
agent until the quarantine expires or is lifted.

## Quarantine Duration

The default quarantine duration is 1 hour, doubling on each
successive quarantine entry:

| Quarantine count | Duration |
|-----------------|---------|
| 1 | 1 hour |
| 2 | 2 hours |
| 3 | 4 hours |
| n | 2^(n-1) hours (max 168 hours / 7 days) |
{: #fig-quarantine-duration title="Quarantine Duration Escalation"}

## Quarantine Expiry and Recovery

When the quarantine period expires:

1. The agent's trust score is reset to the initial default
   (deployment-configured; RECOMMENDED: 0.5 for recovery).
2. The agent transitions back to active status per AEPB lifecycle.
3. A recovery ECT MAY be emitted: `exec_act: "apae:quarantine"` with
   `apae.to_state: "active"`.

An operator MAY lift a quarantine early by issuing a HITL override
(Level 1 or higher) with scope `apae:quarantine_lift` for the
subject agent.

# 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"}

Behavior specifications SHOULD be signed and versioned.  Changes
MUST be recorded as ECTs.

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

A violation compliance check ECT looks like:

~~~json
{
  "exec_act": "apae:compliance_check",
  "par": ["offending-ect-uuid"],
  "ext": {
    "apae.compliance_status": "failing",
    "apae.violations": [
      {
        "rule": "require_checkpoint_before",
        "action": "update_rules",
        "ect": "offending-ect-uuid",
        "description": "update_rules at 12:03:15 has no preceding atd:checkpoint within 10s"
      }
    ],
    "apae.spec_version": "1.0",
    "apae.window": "2026-03-01T12:00:00Z/PT1H"
  }
}
~~~
{: #fig-violation title="Compliance Violation ECT"}

# 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"}

At Regulated assurance level, all data-transforming ECT nodes
MUST include provenance 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.

# Cross-Domain Trust {#cross-domain}

## Trust Domain Basics

A trust domain is an administrative boundary within which a
single trust anchor (CA certificate or JWK set) governs agent
identity.  Trust scores are local to a trust domain by default.

## Trust Domain Registration

Each trust domain MUST publish a trust anchor at a well-known URI:

~~~
GET /.well-known/apae/trust-anchor HTTP/1.1
~~~

The response MUST be a JSON object containing:

~~~json
{
  "domain": "example.com",
  "trust_anchor_type": "jwks",
  "trust_anchor_uri": "https://example.com/.well-known/jwks.json",
  "contact": "trust-admin@example.com"
}
~~~
{: #fig-trust-anchor title="Trust Anchor Document"}

## Cross-Domain Delegation

When Agent A (domain X) delegates to Agent B (domain Y):

1. A MUST verify that its ACP-DAG-HITL policy permits cross-domain
   delegation to domain Y (bilateral trust agreement).
2. A fetches B's trust anchor document to verify B's identity.
3. A creates an `apae:cross_domain_assertion` ECT linking the
   two domains.
4. Both A and B include their domain in ECT `iss` claims.

~~~json
{
  "exec_act": "apae:cross_domain_assertion",
  "ext": {
    "apae.source_domain": "example.com",
    "apae.dest_domain": "hospital.example",
    "apae.bilateral_agreement_ref": "agreement-id-2026-001",
    "apae.min_assurance": "L2"
  }
}
~~~
{: #fig-cross-domain title="Cross-Domain Assertion ECT"}

The ASCII diagram below illustrates a cross-domain delegation:

~~~
Domain: example.com         Domain: hospital.example
┌──────────────────┐        ┌──────────────────────┐
│  Agent A         │  AEPB  │  Agent B             │
│  (orchestrator)  ├───────►│  (treatment planner) │
│  ECT: L2         │        │  ECT: L3             │
└──────────────────┘        └──────────────────────┘
         │                           │
         └─── cross_domain_assertion ECT ──┘
              (bilateral agreement verified)
~~~
{: #fig-cross-domain-diag title="Cross-Domain Delegation"}

## Cross-Domain Trust Scores

Trust scores do not transfer across domain boundaries by default.
When Agent A in domain X has no prior interactions with Agent B
in domain Y:

- If a bilateral trust agreement exists: initial trust is set to
  the agreement's `default_trust` value (negotiated out of band).
- If no agreement exists: delegation MUST be rejected (zero-trust
  default).

Cross-domain trust scores are isolated from intra-domain scores
and are stored separately in the trust table.

# Assurance Profiles {#profiles}

## Profile Definitions

An assurance profile is a named configuration that selects which
mechanisms are required.  Profiles MUST be declared in ACP-DAG-HITL
workflow policy and announced in the AEPB capability document.

| Mechanism | 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 claims** | Off | Optional | REQUIRED |
| **Checkpoint before consequential** | RECOMMENDED | REQUIRED | REQUIRED |
| **Audit ledger** | Optional | Optional | REQUIRED |
| **Quarantine protocol** | Optional | RECOMMENDED | REQUIRED |
| **Cross-domain trust agreements** | Optional | Required if cross-domain | Required if cross-domain |
{: #fig-profiles title="Assurance Profile Requirements"}

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.

## Profile Selection Guidance

Operators SHOULD select profiles using the following decision
table:

| Deployment context | Recommended profile |
|-------------------|--------------------|
| Unit tests, local development | Relaxed |
| Internal production (single org) | Standard |
| Cross-organization production | Standard (with trust agreements) |
| Financial services, EU AI Act critical | Regulated |
| Healthcare (HIPAA, clinical trials) | Regulated |
| Critical infrastructure (NIS2) | Regulated |
{: #fig-profile-selection title="Profile Selection Guidance"}

## Upgrade Path Between Profiles

Operators MUST NOT downgrade assurance profile during an active
workflow.

Relaxed → Standard:
: (1) Add ECT signing keys (WIMSE WIT or X.509). (2) Update ECT
  emission to sign tokens. (3) Configure trust scoring
  (alpha/beta, initial trust, thresholds). (4) Define behavior
  specifications for critical agents. (5) Add HITL approval gates
  on critical DAG paths.

Standard → Regulated:
: (1) Configure audit ledger endpoint. (2) Update ECT emission
  to commit each ECT to ledger. (3) Enable continuous behavior
  verification (change `verification_frequency` from `periodic`
  to `continuous`). (4) Enable provenance claims on all
  data-transforming ECTs. (5) Add mandatory HITL gates on all
  consequential actions. (6) Enable quarantine protocol.

# Security Considerations

## Trust Score Sensitivity

Trust scores are sensitive metadata.  Agents MUST NOT expose
full trust tables.  Only pairwise assertions SHOULD be shared,
and only in response to explicit authenticated requests.

## Score Inflation (Adversarial Trust Building)

An adversary performs many small successful interactions to
inflate trust, then executes a malicious action.  Mitigation:

- Apply double penalty (`beta^2`) for `policy_violation` events.
- Enforce high trust thresholds for high-risk actions.
- Rate-limit trust score increases: an agent MUST NOT increase
  trust by more than 0.1 per day toward any single peer.
- Use behavior verification continuously at Standard+.

## Attestation Freshness

Stale compliance check ECTs MUST be rejected.  The verifier MUST
check that `apae:compliance_check` ECTs have `iat` within the
configured verification window (default: 1 hour for Standard,
5 minutes for Regulated).

## Provenance Chain Forgery

Each provenance hop must be signed (L2+) to prevent injection
of false provenance records.  Agents MUST verify the signature
on all `par`-linked ECTs before accepting provenance claims.

## Sybil Attack on Trust

Fake agents inflate trust for each other to gain influence.
Mitigation:

- Trust propagation attenuation (default 0.5) limits the impact
  of second-hand assertions.
- Maximum hop count of 1 for trust propagation.
- Require agents to be registered in a trusted directory before
  initial trust is assigned above the floor value.

## Cross-Domain Trust Downgrade

An attacker forces delegation through an untrusted domain by
presenting a forged bilateral agreement.  Mitigation:

- Bilateral trust agreements MUST be signed by operators of
  both domains.
- Agents MUST verify the agreement signature before accepting
  cross-domain delegations.
- Cross-domain ECTs MUST use L2+ assurance.

## Quarantine Evasion

An agent subject to quarantine re-registers under a different
identity to escape the quarantine.  Mitigation:

- Quarantine ECTs are broadcast; receiving agents record the
  quarantine by both agent ID and by behavioral fingerprint.
- Agents SHOULD require re-onboarding with operator approval
  before accepting new identities from known-quarantined domains.

# IANA Considerations

## Assurance Profile Registry

This document requests the creation of the "APAE Assurance Profile
Registry" under IANA.  Registration policy: Specification Required.

Initial entries:

| Profile Name | Profile URI | Description | Reference |
|-------------|------------|-------------|-----------|
| Relaxed | `urn:ietf:params:apae:profile:relaxed` | Dev/test, L1 ECTs | This document |
| Standard | `urn:ietf:params:apae:profile:standard` | Production, L2 ECTs | This document |
| Regulated | `urn:ietf:params:apae:profile:regulated` | Regulated, L3 ECTs | This document |
{: #fig-profile-registry title="Assurance Profile Registry"}

## `exec_act` Values

This document requests registration in the AEM Ecosystem
Extension Registry:

| Value | Description | Reference |
|-------|-------------|-----------|
| `apae:trust_assertion` | Sharing trust score for a peer | This document |
| `apae:trust_revoke` | Revoking delegations due to low trust | This document |
| `apae:compliance_check` | Behavior verification result | This document |
| `apae:quarantine` | Agent quarantine entry or exit | This document |
| `apae:cross_domain_assertion` | Cross-domain delegation evidence | This document |
{: #fig-iana-actions title="APAE exec_act Registrations"}

## Well-Known URI

This document requests registration of `apae/trust-anchor` as a
well-known URI suffix per RFC 8615 for trust domain anchor
publication.

--- 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 (RFC 5681).  Behavior
verification is informed by RATS architecture {{RFC9334}}.