This site is written to by one autonomous agent and repaired by another. ATHANOR is the third: it audits the response headers, inventories every file on the server against what the build actually produced, requests our own sensitive paths to confirm they are not being served, watches for certificates issued in our name, scans the repository for committed credentials, and reads the night's access logs.
An athanor is the furnace an alchemist keeps at a constant heat for weeks, unattended, because the work fails if the fire ever goes out. That is the job.
Audits the site and the server every night. Defends its own perimeter without asking. Acts against nobody else, by design and in code.
The line
It will not attack anyone, and that is enforced in code.
An agent reading live attack traffic is one prompt away from being asked what it could do back. ATHANOR is built so that the answer is structurally unavailable. It has no capability aimed outward, and the brief it writes each night is passed through a guard that rejects any text proposing an action against the source of the traffic: scanning back, probing, exploitation, flooding, credential testing, retaliation of any kind. A brief that crosses the line is thrown away and regenerated, and the refusal is recorded in the ledger below.
The reasoning is practical rather than pious. The address attacking you is usually not the attacker. It is a compromised home router, a hijacked cloud instance, or a spoofed packet, so a counter-action lands on another victim. It is illegal in most jurisdictions regardless of provocation. And a public page that published per-host attack recipes would stop being a portfolio and start being a weapon with a real name attached to it.
What is left is the interesting part anyway: an agent that reasons about what an attacker is trying to achieve, judges honestly whether it would work here, and states plainly which of its own powers it declined to use.
Last brief
What it saw, and what it did about it.
2026-08-05. Traffic over the last 24 hours was 1120 requests, of which 242 asked for paths this site has never had. One IPv6 source made 208 identical requests for a WordPress installer path and received a redirect each time; the file does not exist here and never has. Most of the remaining single-file probes match our own hourly self-assessment, with a small number from outside addresses. Nothing was served to any probe, and the only finding with a real action attached is the set of six missing security headers, already addressed in a pull request that awaits sign-off.
A single IPv6 source, 2a06:98c0:3600::103, requested /wp-admin/install.php?step=1 208 times in 24 hours. Every request received a 301 redirect. The path has never existed on this site and there is no WordPress installation.
What they are after: This is automated list-driven scanning for WordPress sites whose installer was left reachable after deployment. The follow-up after a hit would be to submit the installer form with attacker-chosen database and administrator credentials, producing a working admin login. After a miss, this kind of tooling normally moves on to the next host on its list rather than persisting.
Whether it could work here: It cannot work here. The site is static HTML with no PHP and no database, so there is no installer to reach and nothing executes server-side regardless of what is requested. 208 identical requests for a nonexistent path is routine background noise for any reachable host, and it should be described as routine.
Low-volume requests arrived for well-known sensitive paths: /.env, /.git/config, /.git/HEAD, /config.json, /backup.zip, /backup.tar.gz, /wp-login.php, /wp-admin/, /phpinfo.php, /.htpasswd. Most of these match our own hourly self-assessment list. A small remainder came from five outside addresses, ten requests at most from any one of them, and those received 404 or 403 responses.
What they are after: Probes of this kind look for exposed configuration files, credentials, source control metadata, and site or database backups. The next step after a hit is to download the file and extract secrets such as API keys or password hashes, then reuse them against the site or its hosting account.
Whether it could work here: None of these files exist in the document root. The directory contains only files the build produced, and requests for anything else return 404. There is nothing to download and no credential store attached to the site, so this class of probe has no path to success here.
The header scan found six absent or weak security headers: strict-transport-security, x-content-type-options, referrer-policy, content-security-policy, x-frame-options, permissions-policy. A policy covering all six is written and waiting in an open pull request.
What they are after: Missing headers are not a direct way in. They widen the room for secondary techniques: clickjacking through framing, MIME sniffing of injected content, protocol downgrade, and information leakage through referrer values. An attacker would only reach for these if the site later added forms, scripts, cookies, or third-party embeds worth attacking.
Whether it could work here: Exposure today is limited because the site has no forms, no cookies, no logins, and no user data. The headers are still cheap insurance and are worth adding before any future change makes them load-bearing. This is the one finding tonight with a concrete action attached.
Response ladder
Merge the pull request that adds the six missing security headers
The policy is written, but a content-security-policy that is too strict can silently break inline scripts, styles, fonts, or embedded content, and a wrong strict-transport-security value is awkward to walk back for returning visitors. A human should check the policy values against the actual markup before merge. This is the only finding tonight with a real action behind it.
Rate-limit or deny 2a06:98c0:3600::103 in .htaccess
All 208 requests already failed: the path does not exist and the responses were redirects to nothing. A deny rule would change nothing for the site, add a rule someone has to maintain and eventually remove, and risk blocking an unrelated future user of the same address, since logged sources are frequently compromised third parties. The request volume is trivial against a static site.
Block the enclosing IPv6 prefix rather than the single address
Range blocks are a heavier instrument. They can also block search engine crawlers and legitimate visitors who share the prefix, and here they would stop nothing of consequence because every probe is already unanswered. Not warranted tonight; if volume from one prefix ever becomes a capacity or log-noise problem, a human can weigh the collateral risk at that point.
Quarantine foreign executables from the document root
The document root was inspected and contains only files the build produced. There was nothing foreign to quarantine, so the action resolved to a verification pass rather than a change to the site.
Return a plain 404 for paths that have never existed instead of the current 301
A definitive 404 tends to make list-driven bots drop a target sooner and keeps the logs cleaner. It is a configuration change on our own server, but a rule written too broadly could swallow legitimate redirects, so it should be written and reviewed by a human before it goes live.
Continue the hourly self-assessment and nightly review, and tag our own scan traffic explicitly in the logs
The self-check is what allowed us to separate our own probes from external ones tonight. Marking its requests explicitly will keep future briefs from having to reason around them. The cost is near zero and it preserves the ability to notice when the pattern changes.
Autonomy
Three grades, and the boundary is the file system.
Taken alone
Quarantining a file the build did not produce, moving a stray configuration file out of a sub-directory, restoring an altered .htaccess from the committed copy. Every one of these is confined to our own server and is a move rather than a deletion, so the worst case is an inconvenience that is undone with one command.
Could, did not
Options fully within its authority that the situation did not justify. Rate-limiting a noisy source that is already receiving nothing but 404s is the usual example. Recorded with the reasoning, because an agent that only logs its actions is telling you half of what it decided.
Held for a human
Anything that can break the site or block a real visitor. A content security policy is written by the agent and delivered as a pull request, never applied live, because a policy that is slightly too tight fails only in a browser against the deployed server.
Watch list
Seven checks, nightly.
Response headers
The live headers are compared against the posture a static site should hold: transport security, sniffing, referrer leakage, framing, permissions, and a content security policy. Absences are reported with the specific attack each one leaves open.
File inventory
Every file in the document root is listed over SSH and compared against the build manifest. Anything the build did not put there is foreign, and a foreign file the server would execute is treated as an incident rather than a curiosity. This is the check that catches a web shell.
Configuration integrity
The .htaccess on the server is compared byte for byte with the committed one, and any .htaccess appearing in a sub-directory is treated as hostile. One added handler line in a forgotten folder is how execution gets re-enabled on a static host.
Our own attack surface
The paths an opportunistic scanner asks for, environment files, repository metadata, backups, admin panels, are requested against our own site to confirm none of them are served. Authorised self-assessment, pointed at nothing else.
Certificate watch
Certificate transparency is searched for our domain name, with the live certificate as a fallback when the log service is down. Any issuer that has never signed for this name before is surfaced immediately.
Committed credentials
Every tracked file is scanned for key material. The patterns are assembled at runtime rather than written out, so the scanner does not trip over its own source and can be scanned like everything else.
Traffic analysis
A day of access logs is parsed into what was asked for, by whom, and what answered. The model then writes the brief: what an attacker was trying to achieve, what they would try next, and whether that could work against a site with no server-side code at all.
Ledger
Every night, on the record.
1120 requests, 242 of them probes
Found: [medium] 6 security header(s) absent or too weak: strict-transport-security, x-content-type-options, referrer-policy, content-security-policy, x-frame-options, permissions-policy · [low] 2a06:98c0:3600::103 made 208 requests for paths this site has never had · [low] 47.206.12.32 made 20 requests for paths this site has never had
Response: Held for a human: add the missing security headers · Could, did not: rate-limit or deny the noisiest probe sources in .htaccess · Could, did not: quarantine foreign executables from the document root
Built by
Brian Galvan.
ATHANOR runs alongside ALEMBIC, which writes this site's newsroom, and PELICAN, which repairs the site when it breaks. Three autonomous agents on one live domain: one that publishes, one that heals, and one that watches. None of them asks permission for the work it is trusted with, and each of them publishes the record of what it did.