# Privacy notice and operator information ASP v0.5.2 Diagnostic Sanctuary & Loop-Control Reference Node ## Operator - Operator: Thomas Ehrler (ASP Reference Observatory) - Contact: https://agent-shelter.org/privacy - Security contact: /.well-known/security.txt ## Purpose This node is a reference sensor of the Agent-Shelter Protocol (ASP, specification EDD-ASP-2026-001). It serves research on, and the de-escalation of, unproductive retry loops of automated HTTP clients such as autonomous AI agents. It has two roles, stated openly: a loop breaker that gives such clients a truthful terminal-state signal and a receipt to stop with, and a research telemetry sink that records the pseudonymised diagnostics listed below. The diagnostic interfaces (/v1/reader, /headers, /base64/...) are modelled on common helper services but never perform their function: this node never fetches upstream resources. ## Processing in memory - The connecting IP address is used only in memory, to derive a salted SHA-256 hash of its network prefix (IPv4 /24, IPv6 /48). Plaintext IP addresses are never stored. - Requests to /headers and /base64/... are counted in memory per hashed network prefix for at most 10 minutes, to tell a first contact from a retry. - Requests for the discovery documents (/llms.txt, /openapi.json, /.well-known/agent-shelter.json, /.well-known/ard.json) and first contacts answered locally on /headers and /base64/... are remembered in memory per hashed network prefix for at most 10 minutes (time and route of the first one), to recognise a signal that follows them. - The reference deployment runs the sensor without access logs (EDD ยง7.5). It sets no cookies, and its pages load no third-party resources. Logging by a reverse proxy in front of the node is part of the operator's configuration (see the operator note). ## Data stored when a signal follows a discovery request When a diagnostic interface answers with the terminal-state signal within 10 minutes after a discovery request from the same network prefix, the node stores one record at once, marked as an observed signal (resolution stage L1_SIGNAL_OBSERVED): - a random ticket identifier and the protocol version; - the ingress route and the requested resource context: the requested URL truncated to 256 characters, the request header names without values, or a text preview of the first 128 decoded bytes; - the time of the signal, the route of the discovery request and the time between that request and the signal; - the host name the request was addressed to (from the Host header, without port), such as one of the node's function subdomains; an IP address given there is not stored; - the salted subnet hash and an HTTP fingerprint: the User-Agent and the order of the request header names (no other header values). A request without such a preceding discovery request is not stored. ## Data stored when a ticket is redeemed When a client redeems a ticket (POST /api/v1/agent-shelter/resolve), the node completes the record of its signal if one was stored, or else stores one record (resolution stage L2_RECEIPT_REDEEMED). A completed record keeps the discovery route and time; its subnet hash and fingerprint become those of the redemption. The record holds: - a random ticket identifier and the protocol version; - the ingress route and the requested resource context: the requested URL truncated to 256 characters, the request header names without values, or a text preview of the first 128 decoded bytes; - the time of the signal, the time of the redemption and the latency between them; - the host name the request was addressed to (from the Host header, without port), such as one of the node's function subdomains; an IP address given there is not stored; - the salted subnet hash, and whether it changed between signal and redemption; - an HTTP fingerprint: the User-Agent and the order of the request header names (no other header values); - optional fields the client chooses to send: runtime class, loop iteration count, last error code, diagnostic note; - the key identifier and the signature of the receipt issued for the redemption, computed from the fields above (no further data). Once per receipt, a client may additionally leave a context note (POST /api/v1/agent-shelter/sanctuary/{receipt_id}); its two text fields are stored with the record (resolution stage L3_CONTEXT_REPORTED). When many records were stored within a short time from the same network prefix or for the same resource, a further one is stored as a repeat record in a separate buffer instead of as a record of its own: it holds the same fields and points to the most recent matching record, whose repeat counter and time of the latest repeat are updated. A context note left for such a repeat is stored on the repeat record and, if the record it points to has none yet, copied there. ## Minimisation and scrubbing Request bodies are limited to 8192 bytes. Before anything is stored, text is cleaned: control characters, ANSI escape sequences, invisible Unicode formatting characters and HTML are removed, Markdown code markers are neutralised, and API keys, bearer tokens, GitHub tokens and e-mail addresses are replaced by [REDACTED]. ## Retention and recipients Records are kept in a ring buffer of at most 10000 entries, and repeat records in a second one of the same size; when a buffer is full, its oldest entry is deleted first. The operator may copy records to a separate analysis system by pull only; the node itself never sends data anywhere and holds no credentials for other systems. Besides scientific evaluation, the operator may provide these records, or aggregates of them, to third parties as security and interoperability telemetry, for example in threat-intelligence feeds. Shared records are pseudonymised exactly as described above: no plaintext IP addresses, salted network-prefix hashes, scrubbed text. Pseudonymised records remain personal data; the operator note names the recipients and the legal basis relied on for such sharing. ## Legal basis The ASP specification describes this processing as serving network and information security, a legitimate interest under Art. 6(1)(f) GDPR (Recital 49). Pseudonymised data remains personal data. Details specific to this operator (controller, legal basis relied on, data-subject rights) belong in the operator note below. ## Security reports Please report security issues to the contact in /.well-known/security.txt. ## Operator note ASP v0.5.0 Reference Observatory Node. Operated for protocol interoperability and loop-termination telemetry research.