| Internet-Draft | SAS Model & Architecture | September 2026 |
| Feria Hernandez | Expires 5 March 2027 | [Page] |
Autonomous computational agents are capable of generating high-frequency synthetic traffic that can cause a protected system to allocate memory, consume processing cycles, or invoke application-layer computational routines before the eligibility of an incoming request has been established.¶
This document formalizes Agentic Saturation Stridency (SAS) as a measurable system condition defined by the ratio between the arrival rate of unverified agentic traffic over a discrete observation interval and the empirically sustainable admission capacity of the target boundary.¶
The document defines three operational regimes (Subcritical, Critical, and Supercritical) and specifies a pre-runtime structural admission architecture designated Reality Layer 0 (RL0). RL0 establishes an ex-ante admission boundary intended to drop or reject unverifiable traffic before protected application-layer execution, incorporating bounded-state replay protection, out-of-band key revocation checking via probabilistic structures, constant-time cryptographic operations, and standardized wire encodings.¶
The admission framework utilizes a signed Reality-Token (RT) and an admission predicate associated with the Invariant Reality Prism (IRP), listed as an Informative Reference in the NIST Cybersecurity Framework Online Informative References catalog under Reference ID 189 (IRP-189). The catalog entry is cited for informational provenance only and does not imply NIST authorship, endorsement, certification, or normative incorporation of the IRP framework.¶
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 5 March 2027.¶
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.¶
Modern computational infrastructures are increasingly exposed to autonomous agents, automated swarms, and synthetic processes capable of issuing protocol-level requests at machine frequency. At the end of the second quarter of 2026, the global domain name base comprised approximately 401.6 million domain name registrations across all TLDs according to the VeriSign Domain Name Industry Brief [VERISIGN-DNIB], with gTLDs accounting for 243.8 million per ICANN operational metrics [ICANN-METRICS]. Unlike traditional human-driven interaction, agentic workflows can sustain continuous, high-volume request streams that increase pressure on system resources.¶
Traditional application-layer security mechanisms (e.g., Web Application Firewalls, API gateways, and rate limiters) commonly operate after some transport, parsing, routing, or application-layer processing has already occurred. Depending on deployment architecture, additional computational resources may therefore be committed before structural admission has been established.¶
When applied to high-frequency autonomous agentic traffic, this ordering creates an asymmetric resource condition: the computational cost of evaluating an unverified request may be borne primarily by the protected target rather than by the initiating agent.¶
To reduce this structural asymmetry, this document establishes the following architectural principle:¶
Verification before Resource Commitment.¶
For deployments implementing the RL0 architecture, protected application-layer computation SHOULD NOT be invoked until the required structural admission conditions have been established.¶
In this specification, "pre-runtime" refers specifically to processing that occurs prior to protected application or backend execution, rather than execution before all ingress transport processing.¶
This document defines Agentic Saturation Stridency (SAS) as a quantitative measure of arrival pressure and introduces Reality Layer 0 (RL0) as a pre-runtime structural admission architecture. RL0 separates structural admissibility from subsequent contextual, normative, or prudential policy decisions, enabling evaluation of a modular two-layer defense model.¶
The document does not define a complete application authorization protocol or mandatory identity governance scheme. The Reality-Token (RT) mechanism, the Edge Admission Control Profile (EACP), and the THALET prudential gating pipeline represent reference implementation profiles and research instantiations associated with this model; they are not normatively specified by this document.¶
RL0 is intended to complement, rather than replace, existing network and application security mechanisms:¶
SAS is strictly a quantitative measure of arrival pressure relative to sustainable admission capacity. SAS does NOT evaluate or measure:¶
Operationally, SAS evaluates traffic classified by the deployment as autonomous or automated prior to structural admission under the deployment's observation model. A high SAS value indicates saturation pressure and does not, by itself, establish that the originating traffic is malicious.¶
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.¶
Let Delta_t denote a discrete temporal observation interval, where Delta_t > 0. The observed average arrival rate of unverified agentic requests over the interval [t, t + Delta_t] is defined as:¶
N_unverified(t, t + Delta_t)
lambda_unverified(t, Delta_t) = ------------------------------
Delta_t
¶
where N_unverified(t, t + Delta_t) represents the total count of unverified requests arriving at the admission boundary during Delta_t.¶
The sustainable admission capacity lambda_admission_capacity(t, Delta_t) is an operational quantity determined from measured system behavior under specified workload, concurrency, hardware, cryptographic, memory, and network conditions.¶
For analytical approximation under stable service-time and concurrency assumptions, capacity MAY be estimated as:¶
Capacity_max
lambda_admission_capacity(t, Delta_t) ≈ -----------------
tau_exec
¶
where tau_exec represents the effective admission processing time per request and Capacity_max represents the applicable concurrency bound under the defined operating conditions. This approximation MUST NOT replace empirical measurement when determining operational saturation thresholds.¶
The Agentic Saturation Stridency ratio SAS(t, Delta_t) over window Delta_t is defined as:¶
lambda_unverified(t, Delta_t)
SAS(t, Delta_t) = -----------------------------------------------------
lambda_admission_capacity(t, Delta_t)
¶
SAS is dimensionless. A value greater than one indicates that the observed arrival rate exceeds the measured sustainable admission capacity for the corresponding observation conditions.¶
The numerator and denominator MUST refer to the same admission boundary, observation window, and declared operating conditions. Capacity values obtained under materially different hardware, workload, concurrency, cryptographic, or network conditions MUST NOT be directly substituted without an explicit normalization or recalibration procedure.¶
System operation is classified into three operational regimes governed by an implementation-defined positive classification tolerance epsilon (where 0 < epsilon < 1). Note that epsilon is an operational policy parameter and not an intrinsic physical property of SAS:¶
RL0 is designed as an ex-ante structural admission boundary situated as close to the network interface or ingress processing boundary as practical. The reference processing pipeline is:¶
Incoming Traffic
|
v
+------------------+
| Admission |
| Boundary RL0 |
+------------------+
|
Structural Validation
|
+---------+---------+
| |
FAIL PASS
| |
DROP v
+----------------+
| Layer 1 |
| Optional |
| Prudential |
| Gating |
+----------------+
|
+------+------+
| |
DENY PERMIT
| |
DROP v
Protected Application
¶
The Reality-Token (RT) serves as a reference structural admission credential carried within protocol-defined headers or framing structures. To ensure zero-copy parsing and high-throughput evaluation at the perimeter, implementations SHOULD format HTTP header representations in compliance with HTTP Structured Field Values [RFC8941].¶
The following is an HTTP header representation conforming to Structured Field Values syntax:¶
For binary protocol environments or low-bandwidth deployments (e.g., HTTP/3 QPACK frames or transport-layer wrappers), implementations MAY encode the token using Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) [RFC9052]. This binary encoding minimizes header serialization overhead and parsing complexity in high-frequency network paths.¶
The presence of an RT asserts only structural compliance and cryptographic proof. It MUST NOT be construed as proof of application-layer authorization, legal legitimacy, or normative alignment.¶
An RL0 ingress gate following this architecture MUST enforce bounded credential and header sizes and MUST bound the amount of input consumed by structural validation. Admission processing SHOULD be designed to maintain bounded resource consumption per request under the declared input and implementation constraints.¶
If any structural verification step encounters a processing error, internal exception, or validation timeout, the RL0 state machine MUST fail closed and reject the request.¶
This specification explicitly separates structural admission from subsequent prudential evaluation:¶
Because Layer 0 can reject structurally non-admissible traffic before Layer 1 invocation, the architecture is intended to reduce the volume of traffic exposed to more computationally expensive contextual evaluation. The magnitude of that reduction is an empirical question addressed by the evaluation methodology.¶
RL0 may associate structural admission with a binary reality sovereignty predicate R_sov defined by:¶
R_sov = sigma_BIT * VC_ctx * Omega_env¶
where sigma_BIT in {0, 1} represents structural and cryptographic validity, VC_ctx in {0, 1} represents valid contextual scope, and Omega_env in {0, 1} represents environmental validity assertions. Because all three factors are binary, R_sov is binary and can equal 1 only when all mandatory predicates evaluate to 1.¶
When R_sov is configured as a mandatory admission condition and R_sov != 1, the RL0 implementation MUST reject the request.¶
The mathematical formulation of R_sov is associated with the Invariant Reality Prism (IRP) framework, listed as an Informative Reference in the NIST Cybersecurity Framework Online Informative References catalog under Reference ID 189 (IRP-189) [NIST-IRP-189].¶
The NIST OLIR entry is cited solely as informational provenance for the referenced IRP framework. Its inclusion does not imply NIST authorship, endorsement, certification, validation, or normative incorporation of the IRP framework into an IETF protocol or standard.¶
An adversary may deploy autonomous processes capable of emitting high-frequency unverified traffic streams. Without effective admission control, downstream parsing and backend processing may consume substantial computational resources. RL0 is intended to mitigate this condition by rejecting structurally unverified requests before protected application-layer execution.¶
Automated agents may generate forged identities or mimic legitimate workflow patterns. RL0 can mitigate structural credential forgery by requiring valid cryptographic signatures anchored to trusted key structures before admission.¶
An adversary may replay recorded valid Reality-Tokens to bypass cryptographic validation. Under Supercritical SAS regimes (SAS > 1 + epsilon), maintaining unbounded state lists for nonce or sequence tracking introduces a memory exhaustion vulnerability at the perimeter node itself.¶
To resolve this state paradox without compromising perimeter low-latency objectives, implementations MUST enforce ultra-short temporal validity windows (Delta t_valid <= 5 seconds) synchronized via network time protocols (NTP/PTP). Implementations SHOULD complement short temporal windows with bounded-state memory structures, such as Time-Bound Sliding Bloom Filters operating with fixed memory capacity M_max and O(1) insertion/lookup complexity. Stateful tracking requiring long-term persistence MUST be delegated downstream to Layer 1 or application-layer policy engines.¶
The admission boundary itself may become a target for resource-exhaustion attacks. Implementations SHOULD use cryptographic and parsing mechanisms whose computational and memory costs are bounded and appropriate to the expected threat model. Ed25519 is one possible signature algorithm; cryptographic verification MUST be implemented using constant-time algorithms to prevent timing side-channel attacks.¶
Implementations SHOULD minimize dynamic memory allocation and expensive processing before cryptographic validation and MUST enforce bounded credential and header sizes.¶
Overly strict admission criteria, expired credentials, key synchronization failures, or contextual mismatches may cause legitimate requests to be dropped. Deployments SHOULD measure legitimate-traffic survival (S_legit) and admission error rates during operational evaluation and tuning.¶
This document establishes a formal experimental framework to empirically evaluate admission efficacy under varying SAS regimes. The evaluation is designed to distinguish the contribution of deterministic Layer 0 filtering from the contribution of optional Layer 1 prudential evaluation.¶
The experimental design utilizes four comparative scenarios:¶
| Scenario | Layer 0 | Layer 1 | Description |
|---|---|---|---|
| A | OFF | OFF | Unprotected Baseline (Direct Backend Ingestion) |
| B | ON | OFF | Isolated Layer 0 Perimeter Filter |
| C | OFF | ON | Isolated Layer 1 Prudential Evaluator |
| D | ON | ON | Integrated Two-Layer Defense System |
The four scenarios permit independent estimation of the effect of Layer 0, the effect of Layer 1, and the combined behavior of the two-layer architecture.¶
Implementations SHOULD measure performance using the following metrics:¶
The evaluation framework tests three explicit hypotheses:¶
H1 (Invocation and Computation Avoidance): Deterministic perimeter filtering at Layer 0 reduces backend invocations attributable to structurally inadmissible traffic and reduces protected computational consumption relative to the corresponding unprotected baseline (Scenario A) under equivalent workload and operating conditions, such that I_avoided > 0 and C_saved > 0 during Critical and Supercritical SAS regimes.¶
H2 (Prudential Composition): The addition of Layer 1 prudential gating permits contextual policy evaluation while preserving a measurable reduction in Layer 1 and backend invocation load relative to Scenario C, attributable to Layer 0 admission filtering.¶
H3 (Net Architectural Efficiency - Falsifiable): The computational resources saved by preventing protected backend execution exceed the computational overhead introduced by the admission architecture.¶
For a common normalized resource unit U, define:¶
C_net = C_backend_avoided - C_RL0 - C_L1 - C_IPC¶
where C_backend_avoided represents protected backend resources avoided by admission filtering, C_RL0 represents Layer 0 processing cost, C_L1 represents Layer 1 processing cost when enabled, and C_IPC represents the resource-equivalent cost of inter-layer communication (including processing, serialization, transport, and latency overhead) converted into the normalized resource unit U via a predefined experimental normalization function.¶
H3 is supported only when C_net > 0 under the defined experimental conditions. If experimental data demonstrate C_net <= 0, H3 MUST be considered rejected for those operating conditions, thereby bounding the demonstrated efficiency domain of the architecture.¶
To support experimental planning, implementations MAY use preliminary synthetic projections to identify measurement ranges. The values in Table 2 represent illustrative parameter ranges for test execution planning and MUST NOT be interpreted as measured performance results, validated benchmarks, or expected deployment performance.¶
| Architecture Stage | Illustrative Avg. Latency / Req. | Illustrative CPU Cost Profile | Illustrative System Outcome |
|---|---|---|---|
| Baseline (Backend only) | 150.0 ms | High (DB/Inference) | High Resource Pressure |
| Layer 0 (RL0) | 0.5 ms | Low (Signature Verification) | Invalid Traffic Dropped |
| Layer 1 (Prudential Gating) | 12.0 ms | Medium (Policy Evaluation) | Contextual Decision |
SAS does not establish malicious intent, attack attribution, or application-layer authorization. A high SAS value may result from legitimate autonomous workloads, misconfiguration, protocol retries, or malicious activity.¶
RL0 also does not guarantee that backend resource exhaustion is impossible. The admission layer introduces its own computational cost and may itself become a resource target. The architecture therefore requires empirical capacity measurement and comparative evaluation rather than an assumption of universal efficiency.¶
Similarly, cryptographic admission establishes structural eligibility only. It does not establish that an admitted request is safe, lawful, contextually appropriate, or desirable for execution. Such determinations remain within application-layer or Layer 1 policy domains.¶
RL0 ingress boundaries MUST provide a defined mechanism for limiting state associated with token tracking or replay-protection structures, bounding total state memory to M_max.¶
Cryptographic verification MUST use constant-time implementations with established side-channel resistance to prevent timing leaks during signature parsing or key comparison.¶
Implementations using replayable RT credentials MUST provide replay resistance appropriate to the deployment model, utilizing short temporal validity windows (Delta t_valid <= 5 s), audience constraints, sliding Bloom filters, or equivalent mechanisms as required by policy.¶
A failure in Layer 1 evaluation or backend state MUST NOT compromise the structural filtering integrity of Layer 0.¶
The admission credential and all data consumed by token parsing and signature verification MUST be bounded in size. Implementations SHOULD minimize dynamic memory allocation in the critical path to reduce algorithmic-complexity and resource-exhaustion risks at the admission layer.¶
Because the admission layer becomes a security-critical perimeter component, implementations SHOULD independently evaluate its throughput, latency, memory consumption, key-management dependencies, replay state, and failure behavior under adversarial workloads.¶
This document has no IANA actions.¶
The operational state sequence executed for each request at Layer 0 is summarized below:¶
+-------------------------------------------------------------------+
| Ingress Frame / Request |
+-------------------------------------------------------------------+
|
v
+---------------------------+
| Is Reality-Token (RT) | --- NO ---> [ DROP ]
| present? |
+---------------------------+
| YES
v
+---------------------------+
| Is Key & Revocation valid | --- NO ---> [ DROP ]
| (O(1) Cuckoo / Cache)? |
+---------------------------+
| YES
v
+---------------------------+
| Is Cryptographic Sig & | --- NO ---> [ DROP ]
| Short Window (<=5s) valid?|
+---------------------------+
| YES
v
+---------------------------+
| Does Predicate R_sov | --- NO ---> [ REJECT ]
| equal 1? |
+---------------------------+
| YES
v
+---------------------------+
| Layer 1 Enabled? |
+---------------------------+
| |
YES NO
| |
v v
+-------------------+ +-------------------+
| Layer 1 Prudential| | Protected |
| Evaluation | | Application |
+-------------------+ +-------------------+
| |
DENY PERMIT
| |
DROP v
+-------------------+
| Protected |
| Application |
+-------------------+
¶