Network Working Group L. Reilly, Jr. Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational 5 August 2026 Expires: 6 February 2027 Project Atlas: A Cognitive Behavioral Provenance and Integrity (CBPI) Backbone Instrument for Autonomous Agents draft-reilly-atlas-00 Abstract This document specifies Project Atlas, a backbone instrument in which a pipeline of autonomous software agents continuously holds a constellation of live web endpoints under measurement, attestation, and remediation, with every agent behavior conditioned and recorded under the Cognitive Behavioral Provenance and Integrity (CBPI) framework [I-D.reilly-cbpi]. Atlas defines eight agent roles (Resolver, Reachability, Integrity, Provenance, Conditioning Authority, Drift, Functional Behavior Assessment, and Sentinel), a hash-linked Operant Provenance Chain of epochs, hash-linked Reinforcement Event Records, a per-agent Behavioral Drift Index, and a dual authority model in which the instrument operates either fully autonomously or under human oversight through an operator decision queue. A live reference instrument implementing this document is deployed and publicly reachable. Status of This Memo 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 6 February 2027. Copyright Notice 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. Table of Contents 1. Introduction 2. Conventions and Terminology 3. Architecture Overview 3.1. The Constellation Under Load 3.2. The Epoch Cycle 4. Agent Roles 4.1. Resolver Agent 4.2. Reachability Agent 4.3. Integrity Agent 4.4. Provenance Agent 4.5. Conditioning Authority 4.6. Drift Agent 4.7. FBA Agent 4.8. Sentinel Agent 5. CBPI Instrumentation 5.1. Reinforcement Event Records 5.2. Operant Provenance Chain 5.3. Behavioral Drift Index 5.4. Functional Behavior Assessment 6. Authority Model: Autonomous and Human Oversight 7. Instrument API 8. Live Reference Instrument 9. Operational Considerations 10. Security Considerations 11. IANA Considerations 12. References 12.1. Normative References 12.2. Informative References Author's Address 1. Introduction As autonomous agents assume operational responsibility for infrastructure -- monitoring it, attesting to its state, and remediating its failures -- the question shifts from whether agents can perform such work to whether their behavior while performing it can be trusted, measured, and governed. The CBPI framework [I-D.reilly-cbpi] answers this by applying the instruments of behavior analysis to software agents: reinforcement events, provenance chains over behavior, drift measurement, and functional assessment of deviant behavior. Project Atlas is the backbone application of that framework. Where [I-D.reilly-cbpi] defines the records and measures, Atlas deploys them against real infrastructure: a pipeline of eight agents that continuously performs live DNS resolution, live HTTPS reachability checks, and cryptographic content-integrity verification against a constellation of operating web endpoints, sealing every cycle of work into a verifiable hash-linked chain and conditioning every agent's behavior through reinforcement records issued by a Conditioning Authority. The name reflects the posture: the agents stand under the constellation and hold it up. The instrument is "fully autonomous with human oversight" -- a phrase this document makes precise in Section 6 as two explicit authority modes with different disposition rules for remediation. This document is Informational. It records the architecture and the live reference implementation so that the construction can be examined, reproduced, and criticized. 2. Conventions and Terminology 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. Constellation: The set of live endpoints the instrument holds under continuous measurement. Epoch: One complete cycle of the agent pipeline over the full constellation. Operant Provenance Chain (OPC): The hash-linked sequence of sealed epoch records, per [I-D.reilly-cbpi]. Reinforcement Event Record (RER): A hash-linked record of a reinforcement event (positive reinforcement, punishment, or extinction) issued against a named agent, per [I-D.reilly-cbpi]. Behavioral Drift Index (BDI): A scalar in [0,1] measuring an agent's deviation from its own established behavioral baseline, per [I-D.reilly-cbpi]. Functional Behavior Assessment (FBA): A structured antecedent/behavior/consequence record opened when an agent's BDI exceeds threshold, per [I-D.reilly-cbpi]. Sentinel: The remediating agent; the only agent whose actions change instrument state rather than merely measuring it. Operator: The human authority in oversight mode. 3. Architecture Overview 3.1. The Constellation Under Load An Atlas instrument is configured with a constellation: an ordered set of endpoints, each identified by a stable identifier, a hostname, an HTTPS path, and a human-readable label. The reference instrument's constellation comprises eight live endpoints of the Reilly Protocol Suite deployments, including the REM Protocol site, its Sentinel Loop page, and the HDRP, Orion, Multilarity, CBPI, and bulk-subtree-proofs instruments. The constellation is a deployment parameter; any set of HTTPS endpoints MAY be configured. 3.2. The Epoch Cycle The instrument advances in fixed-interval epochs (60 seconds in the reference instrument). In each epoch, the eight agents of Section 4 execute in a measure/condition/assess/seal order: 1. Field agents (Resolver, Reachability, Integrity) measure every constellation endpoint concurrently. 2. The Conditioning Authority issues RERs against the observed behavior of the field agents. 3. The Drift Agent recomputes each agent's BDI; the FBA Agent opens assessments for any agent over threshold; the Sentinel disposes of proposed remediations according to the authority mode. 4. The Provenance Agent seals the epoch -- endpoint results, BDI vector, RER chain head, pending-decision count, and timing -- into the OPC. Because the epoch record embeds the RER chain head, the two hash chains are cross-linked: the behavior ledger is anchored inside the work ledger each epoch. 4. Agent Roles 4.1. Resolver Agent Performs live DNS resolution of every constellation hostname each epoch and records the resolved address and resolution latency. The agent's behavior sample for the epoch is (all-resolved, mean resolution latency). 4.2. Reachability Agent Performs a live HTTPS GET against each endpoint's configured path with a fixed service-level agreement (SLA) timeout (6 seconds in the reference instrument), recording status code and latency. The agent MUST follow at most one redirect hop, so that an endpoint answering with a 301/302 toward its canonical host is judged on the canonical content rather than on the redirect response. An endpoint is "holding" when it resolves and answers within SLA with a 2xx or 3xx status. 4.3. Integrity Agent Computes a SHA-256 digest [RFC6234] over the retrieved content (bounded to the first 64 KiB) and compares it against a stored per-endpoint baseline. The endpoint's integrity state is "baselined" on first observation, "stable" when the digest matches, and "changed" when it does not. A "changed" state is not a fault; it is a fact about the content, and its disposition (accepting the new digest as baseline) is a Sentinel remediation subject to the authority mode. Endpoints serving intentionally dynamic content will read "changed" recurrently; operators SHOULD either point the integrity check at a static representation or accept the recurrent rebaseline as the honest record of a moving surface. 4.4. Provenance Agent Seals each epoch into the OPC. Each epoch record carries the previous record's hash and its own SHA-256 over its canonical JSON serialization; the chain is verifiable in one pass by recomputation (Section 7). 4.5. Conditioning Authority The CBPI core. Each epoch it issues RERs against the field agents: positive reinforcement (type "R+") for conditioned behavior (all hosts resolved; all endpoints holding within SLA; all digests stable), punishment (type "P") for failures, with magnitude scaled to the fraction of the constellation affected, and extinction (type "EXT") when an FBA opens against an agent or when an operator rejects a Sentinel remediation. 4.6. Drift Agent Maintains a rolling behavior window per agent (20 samples in the reference instrument) and computes the BDI as an equal-weight blend of latency drift (deviation of the recent half-window's mean latency from the earlier half-window's) and failure rate. BDI 0 is fully conditioned behavior; BDI 1 is full drift. 4.7. FBA Agent When a field agent's BDI exceeds the drift threshold (0.35 in the reference instrument), the FBA Agent opens a Functional Behavior Assessment recording the antecedent (the window position where the shift began), the behavior (the BDI breach), and the consequence (attestations from the agent are flagged low-confidence until reconditioned), and proposes a reconditioning remediation. 4.8. Sentinel Agent The sole effector. It receives proposed remediations -- currently "rebaseline" (accept a changed content digest as the new integrity baseline for an endpoint) and "reset-window" (recondition a drifted agent by clearing its behavior window) -- and disposes of them according to the authority mode of Section 6. Every applied remediation earns the Sentinel an R+ record; every operator rejection earns it an EXT record, so the Sentinel's own conduct is conditioned by the same instrument it serves. 5. CBPI Instrumentation 5.1. Reinforcement Event Records Each RER carries an identifier, timestamp, epoch number, subject agent, type (R+, P, or EXT), reason, magnitude in [0,1], the hash of the previous RER, and its own SHA-256 over its canonical serialization. The RER sequence therefore forms its own hash chain, headed by the value embedded in each sealed epoch. 5.2. Operant Provenance Chain Each epoch record carries: epoch number, timestamp, authority mode, holding count, per-endpoint results (resolution, reachability, status, latency, integrity state, digest), the BDI vector, the RER chain head, the pending-decision count, epoch duration, the previous epoch's hash, and its own hash. Verification recomputes every record's hash and every link; a single mismatch identifies the broken epoch. 5.3. Behavioral Drift Index BDI = 0.5 * min(|m_late - m_early| / m_early, 1) + 0.5 * f where m_early and m_late are the mean latencies of the earlier and later halves of the agent's behavior window and f is the failure rate over the window. Alternative weightings MAY be used; the reference weighting is deliberately simple and disclosed. 5.4. Functional Behavior Assessment FBA records follow the antecedent/behavior/consequence structure of applied behavior analysis as adopted by [I-D.reilly-cbpi], and each FBA binds a proposed remediation that enters the Sentinel's queue. 6. Authority Model: Autonomous and Human Oversight The instrument operates in exactly one of two modes at any time, switchable at runtime: oversight: Every Sentinel remediation enters a decision queue in state "pending" and has no effect until an operator resolves it. An approved decision is applied and recorded; a rejected decision is discarded and the Sentinel receives an EXT record. This is the human-on-the-loop posture consistent with the Sovereignty Fallback of [I-D.reilly-cogsov]. autonomous: The Sentinel applies remediations immediately, and the decision record is written in state "auto-applied" with the Sentinel named as resolver. Human visibility is preserved -- the queue, the RERs, and the OPC record everything -- but human approval is not awaited. In both modes the decision ledger is append-style and epoch-bound, so the mode in force at the time of every remediation is reconstructible from the chain. Deployments exposing the mode switch and decision verdicts publicly SHOULD require an operator credential (Section 10). 7. Instrument API An Atlas instrument exposes, at minimum: GET / watch-floor dashboard GET /api/state full instrument state GET /api/constellation configured endpoints, latest results GET /api/epochs?limit=N recent OPC records and chain head GET /api/chain/verify full-chain recomputation verdict GET /api/rer?limit=N recent RERs and RER chain head GET /api/fba FBA records GET /api/decisions Sentinel decision queue POST /api/decisions/{id}/approve operator approval (oversight) POST /api/decisions/{id}/reject operator rejection (oversight) POST /api/mode {"mode":"autonomous"|"oversight"} GET /healthz liveness All responses are JSON over HTTP [RFC9110]. 8. Live Reference Instrument A live reference instrument implementing this document in full is deployed and publicly reachable at: https://project-atlas-production-297c.up.railway.app/ The deployment is a zero-dependency Node.js service (standard library only: crypto, dns, https, http) whose complete state surface is inspectable through the API of Section 7; in particular, https://project-atlas-production-297c.up.railway.app/api/state https://project-atlas-production-297c.up.railway.app/api/chain/verify return, respectively, the live state and an independent recomputation of the Operant Provenance Chain. The instrument's state is held in memory per boot; the chain genesis restamps on redeployment, which is disclosed rather than concealed (Section 9). 9. Operational Considerations In-memory state: The reference instrument keeps a bounded window of epochs, RERs, FBAs, and decisions in memory and restarts its chains on redeploy. Deployments requiring cross-boot continuity SHOULD anchor the chain head periodically using an external permanence layer, for which the author's Dual-Layer Digital Permanence methodology (external timestamping plus archival deposit) is the intended companion. Dynamic endpoints: See Section 4.3. Recurrent "changed" states on dynamic endpoints are expected and self-documenting. Canonical hostnames: Constellation entries SHOULD name the canonical host that actually carries the TLS certificate and DNS record (for example, a "www." host where the apex is not configured); the one-hop redirect follow of Section 4.2 is a mitigation, not a substitute. 10. Security Considerations The instrument's control surface (mode switch and decision verdicts) changes remediation behavior and MUST be protected in any deployment exposed to untrusted networks; the reference instrument supports an operator key conveyed in a request header, and deployments SHOULD enable it. The hash chains provide tamper evidence, not tamper resistance: an actor with write access to the process can rewrite both chains, which is why external anchoring (Section 9) is the recommended companion. Outbound measurement traffic is ordinary HTTPS GET at low rate against endpoints the deployer configures; deployers MUST NOT configure constellations of endpoints they are not authorized to probe. Content digests bound to 64 KiB mean integrity attestation covers a prefix of large resources, which is disclosed here as a limit of the reference instrument. 11. IANA Considerations This document has no IANA actions. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. [I-D.reilly-cbpi] Reilly, Jr., L., "Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-reilly-cbpi-00, July 2026. 12.2. Informative References [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, June 2022. [I-D.reilly-cogsov] Reilly, Jr., L., "Cognitive Sovereignty", Work in Progress, Internet-Draft, draft-reilly-cogsov-00, July 2026. [I-D.reilly-mws] Reilly, Jr., L., "Machine-Web Symbiosis (MWS)", Work in Progress, Internet-Draft, draft-reilly-mws-00, 2026. [I-D.reilly-multilarity] Reilly, Jr., L., "The Multilarity", Work in Progress, Internet-Draft, draft-reilly-multilarity-00, July 2026. Author's Address Lawrence John Reilly, Jr. REM Technologies & Consulting, LLC Tampa Bay, Florida United States of America Email: lawrencejohnreilly@gmail.com