ietf-draft-analyzer/workspace/drafts/new-drafts/draft-e-apae-assurance-profiles-01.md

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

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

• exec_act: "apae:trust_assertion"

{
  "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:

{
  "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:

{
  "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

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:

{
  "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 Specifications

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

{
  "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"

{
  "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:

{
  "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

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:

{
  "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

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:

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

{
  "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

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:

{
  "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}}.