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

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 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 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 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 are denied with HTTP 403.

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

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

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.

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

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

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:

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