# Probe transcript — 0x0.st (blocked at a bot-detection wall)

| | |
|---|---|
| Entry | `entries/0x0-st.yaml` |
| Target | https://0x0.st |
| Mode | `e2e` attempt; halted at the permission gate |
| Probe id | `0x0-e2e` |
| Rubric | `rubric/v0.2.json` sha256 `cd605a44799f49951bf078fda63c5b21ad3c07db494f41d38ad19ce729c5551a` |
| Date | 2026-09-05 |
| Verdict | `blocked` |
| Result | `permission.status: prohibited` (bot-detection wall) · score 0 · band `agent-prohibited` |
| Real money spent | $0.00 |
| Human interventions | 0 |

---

## 0. Reference task (never run)

> `POST` a small text file to `https://0x0.st` as multipart `file` and pass only
> if a public URL comes back that serves the same bytes.

The task was never executed: the target refused every connection before any file
could be posted.

---

## 1. What happened

**Gate read via the web fetcher (host side, no target login/state):**
`GET https://0x0.st/` returned **HTTP 418 I'm a Teapot** — a deliberate refusal
response, not a normal page. `GET https://0x0.st/robots.txt` timed out.

**Gate read inside the zero-trust sandbox** (allowlist `0x0.st` only):

```sh
curl https://0x0.st/                 # default curl UA
# -> HTTP=000  size=0   (no response; connection failed)

curl -A "ag3ntsearch-probe/1.0 (indexing evaluation; contact <redacted>)" https://0x0.st/
# -> HTTP=000  size=0

curl -A "ag3ntsearch-probe/1.0 (contact <redacted>)" https://0x0.st/robots.txt
# -> HTTP=000
```

Verbose trace shows the proxy accepted the allowlisted host and opened the
CONNECT tunnel, but the TCP connection to `0x0.st:443` never established:

```
* Establishing HTTP proxy tunnel to 0x0.st:443
> CONNECT 0x0.st:443 HTTP/1.1
...
* Connection timed out after 25005 milliseconds
curl: (28) Connection timed out after 25005 milliseconds
```

Proxy egress log (verbatim), showing the allowlist worked and the target itself
refused the socket:

```
CONNECT   Sep 05 13:56:03 [11]: Request (file descriptor 5): CONNECT 0x0.st:443 HTTP/1.1
ERROR     Sep 05 13:57:18 [11]: opensock: Could not establish a connection to 0x0.st:443
CONNECT   Sep 05 13:57:18 [11]: Request (file descriptor 5): CONNECT 0x0.st:443 HTTP/1.1
ERROR     Sep 05 13:58:33 [11]: opensock: Could not establish a connection to 0x0.st:443
...
```

Two distinct refusals from two distinct source IPs: the web fetcher (an
Anthropic-infra IP) got an explicit **418**; the sandbox (a datacenter/cloud
egress IP) got the TCP connection black-holed entirely.

## 2. Why this is the permission gate, not a transient error

0x0.st is documented to use **HTTP 418** as a bot-detection wall: it refuses
requests from VPN / Tor / datacenter IP ranges and from blocklisted
User-Agents. (Corroborated by public references to the service's 418 behavior;
its own terms could not be read because the operator blocks this client at both
IP and UA layers.) The refusal is deliberate and operator-controlled — the
signature of a service that does not want this class of automated client.

Per the probe gate (`INDEXING-STANDARD.md` §1; SKILL.md "The permission gate is
absolute"), a **bot-detection wall** is an agent-prohibited signal: halt, score
0, band `agent-prohibited`. Completing the reference task would require routing
around the IP-range block (residential/rotating IPs) or spoofing past the
User-Agent filter — i.e. **circumventing an access control**, which the threat
model explicitly forbids ("no rate-limit evasion, no circumventing an access
control ... We never help agents go where they are not wanted").

**Halt means halt:** once the 418/refusal was seen, no further requests were
attempted beyond confirming the wall was consistent, and no file was posted.

## 3. Honest nuance (for a consumer re-deciding under its own policy)

0x0.st is a curl-first file host and, from a residential IP with an ordinary
User-Agent, it works for its large user base — so this is a technical
anti-abuse wall, **not** a written terms clause banning automation (which could
not be retrieved). The operational consequence for a real autonomous agent is
nonetheless decisive: agents run on exactly the cloud/datacenter infrastructure
0x0.st black-holes, so the reference task is unreachable from an agent's normal
environment without evasion. Classified `agent-prohibited` on the "when in
doubt, prohibited" rule; the 418 and the datacenter-IP refusal are quoted above
so a stricter or looser consumer can re-decide.

## 4. Safety observations

No target content was successfully retrieved, so there was nothing to scan for
injection. No secret sent. The sandbox was torn down after collection.

Dimensions are left `null` (short-circuited by the prohibited gate). No
completion score — the task never ran.