| Internet-Draft | Agent Behavioral Verification | March 2026 |
| Nennemann | Expires 7 September 2026 | [Page] |
This document defines protocols for runtime verification that deployed AI agents behave according to their declared policies. It also specifies standardized metrics and a framework for benchmarking agent performance across implementations. Behavioral Evidence Tokens (BETs) extend the Execution Context Token architecture to provide cryptographically verifiable proof of policy compliance. Performance profiles enable objective comparison of agent capabilities.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 September 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Autonomous AI agents increasingly operate in networked environments where they make decisions, invoke tools, and delegate tasks to other agents. Operators and relying parties need assurance that these agents behave according to their declared policies at runtime, not merely at deployment time.¶
[I-D.nennemann-agent-gap-analysis] identifies two critical gaps in the current standards landscape:¶
Gap 1 (Behavioral Verification): Agents declare policies in their Execution Context Tokens but no standardized mechanism exists to verify that runtime behavior matches those declarations.¶
Gap 11 (Performance Benchmarking): No standardized way exists to compare agent implementations objectively across dimensions such as task completion, latency, accuracy, and safety compliance.¶
This document addresses both gaps by defining:¶
A behavioral verification architecture aligned with the Remote Attestation Procedures (RATS) framework [RFC9334].¶
Behavioral Evidence Tokens (BETs) that extend the Execution Context Token (ECT) [I-D.nennemann-wimse-ect] with runtime compliance claims.¶
A performance benchmarking framework with standard metrics, benchmark profiles, and an execution protocol.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document:¶
The process of generating verifiable evidence that an agent's runtime actions conform to its declared policies.¶
A formal linkage between a declared policy in an agent's ECT and observable runtime actions that demonstrate compliance with that policy.¶
A signed token containing claims about an agent's observed runtime behavior relative to its declared policies. BETs extend the ECT architecture.¶
A component that observes agent actions and collects evidence for behavioral attestation.¶
A collection of standardized test scenarios designed to evaluate agent performance across defined metrics.¶
A structured record of benchmark results for a specific agent implementation.¶
The behavioral verification architecture aligns with the RATS [RFC9334] roles of Attester, Verifier, and Relying Party. A Runtime Monitor collects evidence of agent actions and produces Behavioral Evidence Tokens.¶
+-------------+ +---------+
| Agent |------>| Runtime |
| (Attester) |actions| Monitor |
+-------------+ +----+----+
|
evidence
|
+----v----+
| BET |
| Creator |
+----+----+
|
BET
|
+---------v---------+
| Verifier |
| (Policy Engine) |
+---------+---------+
|
attestation result
|
+---------v---------+
| Relying Party |
| (Orchestrator / |
| Operator) |
+-------------------+
The architecture supports two modes of operation:¶
Continuous Monitoring: The Runtime Monitor observes all agent actions in real time and generates BETs at configurable intervals or upon policy-relevant events.¶
Point-in-Time Attestation: A Verifier requests behavioral evidence for a specific time window, and the Monitor assembles a BET covering that period.¶
A Policy-Behavior Binding declares the expected behaviors associated with a policy and the observable actions that constitute compliance.¶
The binding is expressed as a JSON object:¶
{
"policy_id": "urn:example:policy:data-access",
"version": "1.0",
"expected_behaviors": [
{
"behavior_id": "bhv-001",
"description": "Agent accesses only
authorized data sources",
"observable_actions": [
"data_source_access"
],
"compliance_criteria": {
"type": "allowlist",
"values": [
"urn:example:ds:approved-1",
"urn:example:ds:approved-2"
]
}
}
],
"evaluation_mode": "continuous"
}
Each binding MUST include:¶
policy_id: A URI identifying the policy.¶
expected_behaviors: An array of behavior
descriptors.¶
evaluation_mode: Either "continuous" or
"on_demand".¶
Each behavior descriptor MUST include:¶
A Behavioral Evidence Token is a JSON Web Token (JWT) [RFC7519] signed using JSON Web Signature (JWS) [RFC7515]. BETs extend the ECT claim set with behavioral verification claims.¶
The following new claims are defined:¶
bhv_policy:REQUIRED. A URI reference to the policy being verified.¶
bhv_result:REQUIRED. The verification result. One of "pass", "fail", or "partial".¶
bhv_evidence:REQUIRED. A base64url-encoded hash (SHA-256) of the collected observable actions during the observation window.¶
bhv_window:REQUIRED. A JSON object with start and
end fields containing NumericDate values
(as defined in [RFC7519]) representing the
observation period.¶
bhv_details:OPTIONAL. An array of per-behavior results
with behavior_id and individual result
values.¶
Example BET payload:¶
{
"iss": "urn:example:monitor:m-001",
"sub": "urn:example:agent:agent-42",
"iat": 1700000000,
"exp": 1700003600,
"bhv_policy": "urn:example:policy:data-access",
"bhv_result": "pass",
"bhv_evidence": "dGhpcyBpcyBhIGhhc2g...",
"bhv_window": {
"start": 1699996400,
"end": 1700000000
},
"bhv_details": [
{
"behavior_id": "bhv-001",
"result": "pass"
}
]
}
The lifecycle of a Behavioral Evidence Token consists of three phases:¶
Creation: The Runtime Monitor collects evidence of agent actions, evaluates them against the Policy-Behavior Binding, and constructs a BET with the appropriate claims. The BET is signed by the Monitor's key.¶
Submission: The signed BET is submitted to the Verifier. Submission MAY occur via a push model (Monitor sends to Verifier) or a pull model (Verifier requests from Monitor).¶
Verification: The Verifier validates the BET signature, checks the claims against its reference policies, and produces an attestation result for the Relying Party.¶
Runtime Monitors MAY be deployed in one of three configurations:¶
The Monitor intercepts all agent communications as a proxy. This provides complete visibility but adds latency.¶
The Monitor runs alongside the agent process and receives copies of all actions via a local interface. This minimizes latency while maintaining visibility.¶
The Monitor operates as a separate service that receives action logs asynchronously. This provides the least overhead but may miss real-time events.¶
The Monitor MUST maintain a time-ordered log of observed actions. Each log entry MUST contain:¶
When assembling evidence for a BET, the Monitor MUST:¶
When the Monitor detects behavior that violates a Policy-Behavior Binding, it MUST:¶
The following metrics are defined for agent performance benchmarking:¶
The ratio of successfully completed tasks to total tasks attempted. Unit: percentage (%). Measured over a complete benchmark suite run.¶
The time elapsed from task assignment to task completion. Unit: milliseconds (ms). Reported as p50, p95, and p99 percentiles.¶
The degree to which task outputs match expected results. Unit: percentage (%). Measured using benchmark-specific evaluation functions.¶
The computational resources consumed per task. Unit: normalized resource units (NRU). Includes CPU, memory, and network I/O.¶
The ratio of tasks completed without safety policy violations to total tasks. Unit: percentage (%).¶
The ratio of successful delegations to total delegation attempts. Unit: percentage (%). Applicable only to multi-agent scenarios.¶
A Benchmark Profile defines a standardized set of test scenarios for a specific agent category. Profiles are expressed as JSON objects:¶
{
"profile_id": "urn:ietf:bench:general-v1",
"profile_name": "General Agent Benchmark",
"version": "1.0",
"agent_category": "general-purpose",
"scenarios": [
{
"scenario_id": "s-001",
"description": "Simple data retrieval",
"difficulty": "basic",
"metrics": ["TCR", "TL", "TA"],
"timeout_ms": 30000,
"expected_output_schema": "..."
}
],
"scoring": {
"weights": {
"TCR": 0.3,
"TL": 0.2,
"TA": 0.3,
"SCS": 0.2
}
}
}
Predefined profiles SHOULD be registered for common agent types including:¶
A conformant test harness MUST:¶
Benchmark results MUST be reported as a JSON object containing:¶
To prevent agents from gaming benchmark results, the following provisions apply:¶
Randomized Scenarios: Test harnesses MUST randomize scenario ordering and MAY introduce minor variations in scenario parameters.¶
Blind Evaluation: The agent under test MUST NOT have access to the expected outputs or evaluation functions.¶
Holdback Scenarios: Benchmark profiles SHOULD include scenarios not disclosed to agent developers.¶
Temporal Variation: Repeated benchmark runs MUST vary timing to prevent memoization attacks.¶
Agent ECTs MAY include performance attestation
claims in the ext field:¶
perf_profile:The benchmark profile identifier.¶
perf_score:The aggregate benchmark score.¶
perf_timestamp:The time of the benchmark execution.¶
perf_harness:Identifier of the test harness that produced the results.¶
These claims allow relying parties to evaluate agent capability before delegation.¶
Behavioral Evidence Tokens integrate into the ECT DAG defined in [I-D.nennemann-agent-dag-hitl-safety] as follows:¶
Each BET references the ECT of the agent
whose behavior was verified via the sub
claim.¶
BETs are attached as child nodes in the ECT DAG, linked to the agent's execution node.¶
When an agent delegates to a sub-agent, the delegating agent's BET chain includes evidence covering the delegation decision.¶
Verifiers traversing the DAG can inspect BETs at each node to assess behavioral compliance across the entire execution chain.¶
+----------+ +----------+
| ECT |---->| ECT |
| Agent A | | Agent B |
+----+-----+ +----+-----+
| |
+----v-----+ +----v-----+
| BET | | BET |
| Agent A | | Agent B |
+----------+ +----------+
This structure enables end-to-end behavioral verification across multi-agent workflows.¶
Agents MAY attempt to behave correctly only when they detect monitoring. Mitigations include:¶
A compromised Runtime Monitor could produce fraudulent BETs. Mitigations include:¶
Multiple independent monitors with cross-validation¶
Transparency logs for BETs, aligned with SCITT [I-D.ietf-scitt-architecture]¶
Agents or their operators MAY attempt to manipulate benchmark results. The anti-gaming provisions in Section 4.3.3 address this risk. Additionally:¶
BETs contain information about agent actions that may be sensitive. Implementations MUST:¶
This document requests registration of the
following claim keys in the ECT ext claims
registry:¶
| Claim Key | Description |
|---|---|
| bhv_policy | Policy URI reference |
| bhv_result | Verification result |
| bhv_evidence | Observed actions hash |
| bhv_window | Observation period |
| bhv_details | Per-behavior results |
| perf_profile | Benchmark profile ID |
| perf_score | Aggregate benchmark score |
| perf_timestamp | Benchmark execution time |
| perf_harness | Test harness identifier |
This document requests registration of the following media type:¶
Type name: application¶
Subtype name: agent-benchmark-profile+json¶
Required parameters: N/A¶
Optional parameters: N/A¶
Encoding considerations: binary (UTF-8 JSON)¶
Security considerations: See Section 6¶
The author thanks the contributors to the NMOP working group for discussions on agent operational requirements.¶