385 lines
11 KiB
Markdown
385 lines
11 KiB
Markdown
---
|
|
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.
|