feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,384 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user