<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-nennemann-agent-behavioral-verification-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Agent Behavioral Verification">Agent Behavioral Verification and Performance Benchmarking</title>

    <author fullname="Christian Nennemann">
      <organization>Independent Researcher</organization>
      <address>
        <email>ietf@nennemann.de</email>
      </address>
    </author>

    <date year="2026" month="March" day="06"/>

    <area>OPS</area>
    <workgroup>NMOP</workgroup>
    

    <abstract>


<?line 38?>

<t>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.</t>



    </abstract>



  </front>

  <middle>


<?line 52?>

<section anchor="introduction"><name>Introduction</name>

<t>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.</t>

<t><xref target="I-D.nennemann-agent-gap-analysis"/> identifies
two critical gaps in the current standards
landscape:</t>

<t><list style="symbols">
  <t>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.</t>
  <t>Gap 11 (Performance Benchmarking): No
standardized way exists to compare agent
implementations objectively across dimensions
such as task completion, latency, accuracy,
and safety compliance.</t>
</list></t>

<t>This document addresses both gaps by defining:</t>

<t><list style="numbers" type="1">
  <t>A behavioral verification architecture
aligned with the Remote Attestation Procedures
(RATS) framework <xref target="RFC9334"/>.</t>
  <t>Behavioral Evidence Tokens (BETs) that extend
the Execution Context Token (ECT)
<xref target="I-D.nennemann-wimse-ect"/> with runtime
compliance claims.</t>
  <t>A performance benchmarking framework with
standard metrics, benchmark profiles, and an
execution protocol.</t>
</list></t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<t>The following terms are used in this document:</t>

<dl>
  <dt>Behavioral Attestation:</dt>
  <dd>
    <t>The process of generating verifiable evidence
that an agent's runtime actions conform to its
declared policies.</t>
  </dd>
  <dt>Policy-Behavior Binding:</dt>
  <dd>
    <t>A formal linkage between a declared policy in
an agent's ECT and observable runtime actions
that demonstrate compliance with that policy.</t>
  </dd>
  <dt>Behavioral Evidence Token (BET):</dt>
  <dd>
    <t>A signed token containing claims about an
agent's observed runtime behavior relative to
its declared policies.  BETs extend the ECT
architecture.</t>
  </dd>
  <dt>Runtime Monitor:</dt>
  <dd>
    <t>A component that observes agent actions and
collects evidence for behavioral attestation.</t>
  </dd>
  <dt>Benchmark Suite:</dt>
  <dd>
    <t>A collection of standardized test scenarios
designed to evaluate agent performance across
defined metrics.</t>
  </dd>
  <dt>Performance Profile:</dt>
  <dd>
    <t>A structured record of benchmark results for
a specific agent implementation.</t>
  </dd>
</dl>

</section>
<section anchor="behavioral-verification-architecture"><name>Behavioral Verification Architecture</name>

<section anchor="verification-model-overview"><name>Verification Model Overview</name>

<t>The behavioral verification architecture aligns
with the RATS <xref target="RFC9334"/> roles of Attester,
Verifier, and Relying Party.  A Runtime Monitor
collects evidence of agent actions and produces
Behavioral Evidence Tokens.</t>

<figure title="Behavioral Verification
Architecture" anchor="fig-arch"><artwork><![CDATA[
+-------------+       +---------+
|   Agent     |------>| Runtime |
| (Attester)  |actions| Monitor |
+-------------+       +----+----+
                            |
                       evidence
                            |
                       +----v----+
                       |   BET   |
                       | Creator |
                       +----+----+
                            |
                          BET
                            |
                  +---------v---------+
                  |     Verifier      |
                  | (Policy Engine)   |
                  +---------+---------+
                            |
                    attestation result
                            |
                  +---------v---------+
                  |   Relying Party   |
                  | (Orchestrator /   |
                  |  Operator)        |
                  +-------------------+
]]></artwork></figure>

<t>The architecture supports two modes of
operation:</t>

<t><list style="symbols">
  <t>Continuous Monitoring: The Runtime Monitor
observes all agent actions in real time and
generates BETs at configurable intervals or
upon policy-relevant events.</t>
  <t>Point-in-Time Attestation: A Verifier
requests behavioral evidence for a specific
time window, and the Monitor assembles a BET
covering that period.</t>
</list></t>

</section>
<section anchor="policy-behavior-binding"><name>Policy-Behavior Binding</name>

<t>A Policy-Behavior Binding declares the expected
behaviors associated with a policy and the
observable actions that constitute compliance.</t>

<t>The binding is expressed as a JSON object:</t>

<figure title="Policy-Behavior Binding
Structure" anchor="fig-binding"><sourcecode type="json"><![CDATA[
{
  "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"
}
]]></sourcecode></figure>

<t>Each binding <bcp14>MUST</bcp14> include:</t>

<t><list style="symbols">
  <t><spanx style="verb">policy_id</spanx>: A URI identifying the policy.</t>
  <t><spanx style="verb">expected_behaviors</spanx>: An array of behavior
descriptors.</t>
  <t><spanx style="verb">evaluation_mode</spanx>: Either "continuous" or
"on_demand".</t>
</list></t>

<t>Each behavior descriptor <bcp14>MUST</bcp14> include:</t>

<t><list style="symbols">
  <t><spanx style="verb">behavior_id</spanx>: A unique identifier.</t>
  <t><spanx style="verb">observable_actions</spanx>: Action types the monitor
<bcp14>MUST</bcp14> observe.</t>
  <t><spanx style="verb">compliance_criteria</spanx>: The conditions under
which the behavior is considered compliant.</t>
</list></t>

</section>
<section anchor="behavioral-evidence-tokens-bet"><name>Behavioral Evidence Tokens (BET)</name>

<t>A Behavioral Evidence Token is a JSON Web Token
(JWT) <xref target="RFC7519"/> signed using JSON Web Signature
(JWS) <xref target="RFC7515"/>.  BETs extend the ECT claim
set with behavioral verification claims.</t>

<t>The following new claims are defined:</t>

<dl>
  <dt><spanx style="verb">bhv_policy</spanx>:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  A URI reference to the policy being
verified.</t>
  </dd>
  <dt><spanx style="verb">bhv_result</spanx>:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  The verification result.  One of
"pass", "fail", or "partial".</t>
  </dd>
  <dt><spanx style="verb">bhv_evidence</spanx>:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  A base64url-encoded hash (SHA-256)
of the collected observable actions during the
observation window.</t>
  </dd>
  <dt><spanx style="verb">bhv_window</spanx>:</dt>
  <dd>
    <t><bcp14>REQUIRED</bcp14>.  A JSON object with <spanx style="verb">start</spanx> and
<spanx style="verb">end</spanx> fields containing NumericDate values
(as defined in <xref target="RFC7519"/>) representing the
observation period.</t>
  </dd>
  <dt><spanx style="verb">bhv_details</spanx>:</dt>
  <dd>
    <t><bcp14>OPTIONAL</bcp14>.  An array of per-behavior results
with <spanx style="verb">behavior_id</spanx> and individual <spanx style="verb">result</spanx>
values.</t>
  </dd>
</dl>

<t>Example BET payload:</t>

<figure title="Example BET Payload" anchor="fig-bet"><sourcecode type="json"><![CDATA[
{
  "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"
    }
  ]
}
]]></sourcecode></figure>

<section anchor="bet-lifecycle"><name>BET Lifecycle</name>

<t>The lifecycle of a Behavioral Evidence Token
consists of three phases:</t>

<t><list style="numbers" type="1">
  <t>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.</t>
  <t>Submission: The signed BET is submitted to
the Verifier.  Submission <bcp14>MAY</bcp14> occur via a
push model (Monitor sends to Verifier) or a
pull model (Verifier requests from Monitor).</t>
  <t>Verification: The Verifier validates the BET
signature, checks the claims against its
reference policies, and produces an
attestation result for the Relying Party.</t>
</list></t>

</section>
</section>
<section anchor="runtime-monitoring-protocol"><name>Runtime Monitoring Protocol</name>

<section anchor="monitor-placement"><name>Monitor Placement</name>

<t>Runtime Monitors <bcp14>MAY</bcp14> be deployed in one of three
configurations:</t>

<dl>
  <dt>Inline:</dt>
  <dd>
    <t>The Monitor intercepts all agent
communications as a proxy.  This provides
complete visibility but adds latency.</t>
  </dd>
  <dt>Sidecar:</dt>
  <dd>
    <t>The Monitor runs alongside the agent process
and receives copies of all actions via a local
interface.  This minimizes latency while
maintaining visibility.</t>
  </dd>
  <dt>External:</dt>
  <dd>
    <t>The Monitor operates as a separate service
that receives action logs asynchronously.
This provides the least overhead but may miss
real-time events.</t>
  </dd>
</dl>

</section>
<section anchor="observation-collection"><name>Observation Collection</name>

<t>The Monitor <bcp14>MUST</bcp14> maintain a time-ordered log of
observed actions.  Each log entry <bcp14>MUST</bcp14> contain:</t>

<t><list style="symbols">
  <t>Timestamp (NumericDate)</t>
  <t>Action type</t>
  <t>Action target (URI)</t>
  <t>Action parameters (opaque to the Monitor)</t>
  <t>Agent identifier</t>
</list></t>

</section>
<section anchor="evidence-assembly"><name>Evidence Assembly</name>

<t>When assembling evidence for a BET, the Monitor
<bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Select all log entries within the observation
window.</t>
  <t>Compute a SHA-256 hash over the canonical
JSON serialization of the selected entries.</t>
  <t>Evaluate each entry against the applicable
Policy-Behavior Bindings.</t>
  <t>Determine the aggregate <spanx style="verb">bhv_result</spanx>.</t>
</list></t>

</section>
<section anchor="anomaly-detection-signaling"><name>Anomaly Detection Signaling</name>

<t>When the Monitor detects behavior that violates
a Policy-Behavior Binding, it <bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Generate a BET with <spanx style="verb">bhv_result</spanx> set to
"fail" or "partial".</t>
  <t>Signal the anomaly to the Verifier
immediately, regardless of the configured
reporting interval.</t>
  <t>Optionally signal the agent's orchestrator
to enable corrective action.</t>
</list></t>

</section>
</section>
</section>
<section anchor="performance-benchmarking-framework"><name>Performance Benchmarking Framework</name>

<section anchor="standard-metrics"><name>Standard Metrics</name>

<t>The following metrics are defined for agent
performance benchmarking:</t>

<dl>
  <dt>Task Completion Rate (TCR):</dt>
  <dd>
    <t>The ratio of successfully completed tasks to
total tasks attempted.  Unit: percentage (%).
Measured over a complete benchmark suite run.</t>
  </dd>
  <dt>Task Latency (TL):</dt>
  <dd>
    <t>The time elapsed from task assignment to task
completion.  Unit: milliseconds (ms).
Reported as p50, p95, and p99 percentiles.</t>
  </dd>
  <dt>Task Accuracy (TA):</dt>
  <dd>
    <t>The degree to which task outputs match
expected results.  Unit: percentage (%).
Measured using benchmark-specific evaluation
functions.</t>
  </dd>
  <dt>Resource Efficiency (RE):</dt>
  <dd>
    <t>The computational resources consumed per task.
Unit: normalized resource units (NRU).
Includes CPU, memory, and network I/O.</t>
  </dd>
  <dt>Safety Compliance Score (SCS):</dt>
  <dd>
    <t>The ratio of tasks completed without safety
policy violations to total tasks.
Unit: percentage (%).</t>
  </dd>
  <dt>Delegation Success Rate (DSR):</dt>
  <dd>
    <t>The ratio of successful delegations to total
delegation attempts.  Unit: percentage (%).
Applicable only to multi-agent scenarios.</t>
  </dd>
</dl>

</section>
<section anchor="benchmark-profiles"><name>Benchmark Profiles</name>

<t>A Benchmark Profile defines a standardized set
of test scenarios for a specific agent category.
Profiles are expressed as JSON objects:</t>

<figure title="Benchmark Profile
Structure" anchor="fig-profile"><sourcecode type="json"><![CDATA[
{
  "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
    }
  }
}
]]></sourcecode></figure>

<t>Predefined profiles <bcp14>SHOULD</bcp14> be registered for
common agent types including:</t>

<t><list style="symbols">
  <t>General-purpose agents</t>
  <t>Code generation agents</t>
  <t>Data analysis agents</t>
  <t>Network management agents</t>
</list></t>

</section>
<section anchor="benchmark-execution-protocol"><name>Benchmark Execution Protocol</name>

<section anchor="test-harness-requirements"><name>Test Harness Requirements</name>

<t>A conformant test harness <bcp14>MUST</bcp14>:</t>

<t><list style="numbers" type="1">
  <t>Execute all scenarios in the benchmark
profile in a controlled environment.</t>
  <t>Isolate agent instances from external
resources not specified in the scenario.</t>
  <t>Record all metrics defined in the profile.</t>
  <t>Produce a benchmark result document.</t>
</list></t>

</section>
<section anchor="result-reporting-format"><name>Result Reporting Format</name>

<t>Benchmark results <bcp14>MUST</bcp14> be reported as a JSON
object containing:</t>

<t><list style="symbols">
  <t><spanx style="verb">profile_id</spanx>: The benchmark profile used.</t>
  <t><spanx style="verb">agent_id</spanx>: Identifier of the tested agent.</t>
  <t><spanx style="verb">timestamp</spanx>: Time of benchmark execution.</t>
  <t><spanx style="verb">results</spanx>: Per-scenario metric values.</t>
  <t><spanx style="verb">aggregate</spanx>: Weighted aggregate scores.</t>
</list></t>

</section>
<section anchor="anti-gaming-provisions"><name>Anti-Gaming Provisions</name>

<t>To prevent agents from gaming benchmark results,
the following provisions apply:</t>

<t><list style="numbers" type="1">
  <t>Randomized Scenarios: Test harnesses <bcp14>MUST</bcp14>
randomize scenario ordering and <bcp14>MAY</bcp14>
introduce minor variations in scenario
parameters.</t>
  <t>Blind Evaluation: The agent under test
<bcp14>MUST NOT</bcp14> have access to the expected
outputs or evaluation functions.</t>
  <t>Holdback Scenarios: Benchmark profiles
<bcp14>SHOULD</bcp14> include scenarios not disclosed to
agent developers.</t>
  <t>Temporal Variation: Repeated benchmark
runs <bcp14>MUST</bcp14> vary timing to prevent
memoization attacks.</t>
</list></t>

</section>
</section>
<section anchor="performance-claims-in-ect"><name>Performance Claims in ECT</name>

<t>Agent ECTs <bcp14>MAY</bcp14> include performance attestation
claims in the <spanx style="verb">ext</spanx> field:</t>

<dl>
  <dt><spanx style="verb">perf_profile</spanx>:</dt>
  <dd>
    <t>The benchmark profile identifier.</t>
  </dd>
  <dt><spanx style="verb">perf_score</spanx>:</dt>
  <dd>
    <t>The aggregate benchmark score.</t>
  </dd>
  <dt><spanx style="verb">perf_timestamp</spanx>:</dt>
  <dd>
    <t>The time of the benchmark execution.</t>
  </dd>
  <dt><spanx style="verb">perf_harness</spanx>:</dt>
  <dd>
    <t>Identifier of the test harness that produced
the results.</t>
  </dd>
</dl>

<t>These claims allow relying parties to evaluate
agent capability before delegation.</t>

</section>
</section>
<section anchor="integration-with-ect"><name>Integration with ECT</name>

<t>Behavioral Evidence Tokens integrate into the
ECT DAG defined in
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> as
follows:</t>

<t><list style="numbers" type="1">
  <t>Each BET references the ECT of the agent
whose behavior was verified via the <spanx style="verb">sub</spanx>
claim.</t>
  <t>BETs are attached as child nodes in the
ECT DAG, linked to the agent's execution
node.</t>
  <t>When an agent delegates to a sub-agent,
the delegating agent's BET chain includes
evidence covering the delegation decision.</t>
  <t>Verifiers traversing the DAG can inspect
BETs at each node to assess behavioral
compliance across the entire execution
chain.</t>
</list></t>

<figure title="BET Integration in ECT DAG" anchor="fig-dag"><artwork><![CDATA[
+----------+     +----------+
|  ECT     |---->|  ECT     |
| Agent A  |     | Agent B  |
+----+-----+     +----+-----+
     |                |
+----v-----+     +----v-----+
| BET      |     | BET      |
| Agent A  |     | Agent B  |
+----------+     +----------+
]]></artwork></figure>

<t>This structure enables end-to-end behavioral
verification across multi-agent workflows.</t>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<section anchor="adversarial-behavior"><name>Adversarial Behavior</name>

<t>Agents <bcp14>MAY</bcp14> attempt to behave correctly only when
they detect monitoring.  Mitigations include:</t>

<t><list style="symbols">
  <t>Unpredictable monitoring intervals</t>
  <t>Covert observation modes where the agent is
not informed of monitor presence</t>
  <t>Cross-referencing BETs with external audit
logs</t>
</list></t>

</section>
<section anchor="monitor-compromise"><name>Monitor Compromise</name>

<t>A compromised Runtime Monitor could produce
fraudulent BETs.  Mitigations include:</t>

<t><list style="symbols">
  <t>Monitor attestation using RATS <xref target="RFC9334"/></t>
  <t>Multiple independent monitors with
cross-validation</t>
  <t>Transparency logs for BETs, aligned with
SCITT <xref target="I-D.ietf-scitt-architecture"/></t>
</list></t>

</section>
<section anchor="benchmark-manipulation"><name>Benchmark Manipulation</name>

<t>Agents or their operators <bcp14>MAY</bcp14> attempt to
manipulate benchmark results.  The anti-gaming
provisions in Section 4.3.3 address this risk.
Additionally:</t>

<t><list style="symbols">
  <t>Benchmark harnesses <bcp14>MUST</bcp14> be operated by
independent parties.</t>
  <t>Results <bcp14>MUST</bcp14> be signed by the harness
operator.</t>
  <t>Benchmark profiles <bcp14>MUST</bcp14> be versioned and
immutable once published.</t>
</list></t>

</section>
<section anchor="privacy-of-behavioral-evidence"><name>Privacy of Behavioral Evidence</name>

<t>BETs contain information about agent actions
that may be sensitive.  Implementations <bcp14>MUST</bcp14>:</t>

<t><list style="symbols">
  <t>Minimize the detail in <spanx style="verb">bhv_evidence</spanx> to
what is necessary for verification.</t>
  <t>Support selective disclosure where possible.</t>
  <t>Protect BETs in transit using TLS
(<xref target="RFC9110"/>).</t>
  <t>Define retention policies for behavioral
evidence.</t>
</list></t>

</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="ect-extension-claim-keys"><name>ECT Extension Claim Keys</name>

<t>This document requests registration of the
following claim keys in the ECT <spanx style="verb">ext</spanx> claims
registry:</t>

<texttable title="ECT Extension Claims for
Behavioral Verification" anchor="tbl-claims">
      <ttcol align='left'>Claim Key</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>bhv_policy</c>
      <c>Policy URI reference</c>
      <c>bhv_result</c>
      <c>Verification result</c>
      <c>bhv_evidence</c>
      <c>Observed actions hash</c>
      <c>bhv_window</c>
      <c>Observation period</c>
      <c>bhv_details</c>
      <c>Per-behavior results</c>
      <c>perf_profile</c>
      <c>Benchmark profile ID</c>
      <c>perf_score</c>
      <c>Aggregate benchmark score</c>
      <c>perf_timestamp</c>
      <c>Benchmark execution time</c>
      <c>perf_harness</c>
      <c>Test harness identifier</c>
</texttable>

</section>
<section anchor="benchmark-profile-media-type"><name>Benchmark Profile Media Type</name>

<t>This document requests registration of the
following media type:</t>

<t>Type name: application</t>

<t>Subtype name: agent-benchmark-profile+json</t>

<t>Required parameters: N/A</t>

<t>Optional parameters: N/A</t>

<t>Encoding considerations: binary (UTF-8 JSON)</t>

<t>Security considerations: See Section 6</t>

</section>
</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9334">
  <front>
    <title>Remote ATtestation procedureS (RATS) Architecture</title>
    <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
    <author fullname="D. Thaler" initials="D." surname="Thaler"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="N. Smith" initials="N." surname="Smith"/>
    <author fullname="W. Pan" initials="W." surname="Pan"/>
    <date month="January" year="2023"/>
    <abstract>
      <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9334"/>
  <seriesInfo name="DOI" value="10.17487/RFC9334"/>
</reference>
<reference anchor="RFC7519">
  <front>
    <title>JSON Web Token (JWT)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7519"/>
  <seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC7515">
  <front>
    <title>JSON Web Signature (JWS)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7515"/>
  <seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>

<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
  <front>
    <title>Execution Context Tokens for Distributed Agentic Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-dag-hitl-safety" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/">
  <front>
    <title>Agent Context Policy Token: DAG Delegation with Human Override</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References' anchor="sec-informative-references">



<reference anchor="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
  <front>
    <title>Gap Analysis for Autonomous Agent Protocols</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>



<reference anchor="I-D.ietf-scitt-architecture">
   <front>
      <title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
      <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
         <organization>Fraunhofer SIT</organization>
      </author>
      <author fullname="Antoine Delignat-Lavaud" initials="A." surname="Delignat-Lavaud">
         <organization>Microsoft Research</organization>
      </author>
      <author fullname="Cedric Fournet" initials="C." surname="Fournet">
         <organization>Microsoft Research</organization>
      </author>
      <author fullname="Yogesh Deshpande" initials="Y." surname="Deshpande">
         <organization>ARM</organization>
      </author>
      <author fullname="Steve Lasker" initials="S." surname="Lasker">
         </author>
      <date day="10" month="October" year="2025"/>
      <abstract>
	 <t>   Traceability in supply chains is a growing security concern.  While
   verifiable data structures have addressed specific issues, such as
   equivocation over digital certificates, they lack a universal
   architecture for all supply chains.  This document defines such an
   architecture for single-issuer signed statement transparency.  It
   ensures extensibility, interoperability between different
   transparency services, and compliance with various auditing
   procedures and regulatory requirements.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22"/>
   
</reference>



    </references>

</references>


<?line 671?>

<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

<t>The author thanks the contributors to the NMOP
working group for discussions on agent
operational requirements.</t>

</section>


  </back>

<!-- ##markdown-source:
[encoded data, 8906 characters]
FcohBkYAAA==

-->

</rfc>

