A bit is not a counter

2026-09-11T00:00:00+00:00
Machine speed is the one thing automation cannot hide. An agent can vary its timing, randomise its ordering, and spread its work across processes, but when it does something a million times a second, that rate is the work itself. If you want an instrument that notices automation without knowing in advance what the automation is, rate is a good place to point it.</p>
This is an account of building one: a profiler that finds memory changing faster than the rest of its process, and the code responsible. It is also an account of three ways the obvious design is wrong, each of which produced confident, well-formatted, entirely meaningless output before it was caught. The negative result at the end is the most useful part.</p>
All measurements below are from a single machine — AMD, kernel 7.0.0, perf_event_paranoid=4</code>, yama/ptrace_scope=1</code> — and every number is measured rather than estimated.</p>
🔗</a>The problem with asking the kernel</h2>
Linux offers a cheap way to learn which pages a process has written. Write 4</code>
to /proc/PID/clear_refs</code> and the kernel clears a per-page soft-dirty</em> bit and
write-protects the pages; the next write to each page faults, sets the bit, and
proceeds. Read /proc/PID/pagemap</code> and bit 55 of each 8-byte entry tells you
whether that page was written since the reset.</p>
It is almost free. It costs no memory reads at all, so the observer barely
perturbs the observed — which matters when the thing you are looking for is
defined by its speed.</p>
The obvious instrument writes itself. Clear the bits, wait, read the bitmap,
count. Sample a process every 50 ms for eight seconds and rank pages by how
often they came back dirty.</p>
Here is what that produced against a synthetic target with a deliberately
planted hot region:</p>
  pages written: 84   median hits/page: 156   MAD: 1
</span>
</span>           address   rate   hits       z  kind       region
</span>          0xb49000   100%    156     0.0  file-data  rw-p python3.12
</span>          0xb8a000   100%    156     0.0  file-data  rw-p python3.12
</span>         0x28073000  100%    156     0.0  heap       rw-p [heap]
</span>      0x7bc9bf92c000 100%    156     0.0  anon       rw-p [anon]
</span></code></pre>
Every page. One hundred percent. One hundred and fifty-six hits out of one
hundred and fifty-six samples, a median of 156, a median absolute deviation of
1, and therefore a z-score of exactly 0.0 for every page in the process. The
planted hot region is in that list, indistinguishable from the interpreter’s own
bookkeeping.</p>
The failure is not a bug. Soft-dirty is a bit, not a counter.</strong> It records
that a page was</em> written since the last reset, never how many times. At a 50 ms
window, any page touched at all comes back dirty, so a page written a hundred
times a second and a page written ten million times a second produce identical
output. The metric saturates, and saturation is invisible: the numbers look
fine, the table sorts, the z-scores compute. Nothing about the output announces
that the instrument has stopped measuring.</p>
This is worth dwelling on, because it is the general shape of the problem.
Binary-per-interval observations look like measurements and are not.</p>
🔗</a>Sweeping the timescale</h2>
The information the bit loses within one window can be recovered by varying the
window. For a page written at frequency f</em>, sampled with interval T</em>:</p>
writer</th> probability the page is dirty</th></tr></thead>

periodic</td> f · T</code>, until it saturates at 1</td></tr>
randomly timed</td> 1 − exp(−f · T)</code></td></tr>
</tbody></table>
Both say the same thing. The interval at which a page’s hit rate starts to fall
off</em> is its write frequency. So sample the same process at 20 ms, 5 ms, 1 ms and
0.25 ms, and read the frequency off the rungs where it has not yet saturated.</p>
A page still pinned at 100% in the shortest window is being written faster than
the instrument can resolve. That is not a failure — it is the finding, reported
as a floor rather than a number.</p>
Frequency, unlike a hit rate, does not saturate, and it is comparable across
processes and across machines.</p>
Two details in the inversion turned out to matter more than they look.</p>
Read the frequency off the largest unsaturated window, not the smallest.</strong>
The shortest window has the fewest writes per sample and so the most
discretization error. For a tier written at a true 200 Hz, the 0.25 ms rung read
6% and the 1 ms rung read 22%; the latter is the better-conditioned measurement.</p>
Invert as periodic, not Poisson.</strong> Using −ln(1−r)/T</code> on a periodic writer
overestimates it by about a third — it read 268 Hz against a ground truth of
200. The linear form r/T</code> is also the conservative choice: for a bursty writer
it reads low, so a reported frequency is a floor rather than an inflated claim.</p>
🔗</a>Sampling is not free, and the difference is not small</h3>
The sweep sleeps for the interval it wants. It also has to do work — a pagemap
read, a clear_refs</code> write — and that work is not instantaneous. Feeding the
requested</em> interval into the frequency math scales every estimate by the error.</p>
Measured on the synthetic target:</p>
requested</th> actual</th> overhead</th></tr></thead>

0.25 ms</td> 0.36 ms</td> 44%</td></tr>
1.00 ms</td> 1.12 ms</td> 12%</td></tr>
5.00 ms</td> 5.19 ms</td> 4%</td></tr>
20.0 ms</td> 21.2 ms</td> 6%</td></tr>
</tbody></table>
Correcting the math to use measured intervals moved a 200 Hz tier from 215 Hz to
196 Hz. For the portable collector described below, where a single sample costs
tens of milliseconds, the same error would have been an order of magnitude.</p>
🔗</a>The model can check itself</h3>
Below saturation, r/T</code> should be the same at every rung. That is a testable
claim about each page, and pages that fail it are not measuring a frequency.</p>
A page whose hit rate stays flat</em> as the window shrinks — 88%, 88%, 89%, 90% —
is violating the model, and the instrument says so with a ?</code> rather than
printing a confident number. In practice this catches a specific blind spot,
described next.</p>
🔗</a>Two collectors, one analysis</h2>
Soft-dirty is Linux-only. The analysis is not, so the collector sits behind a
two-method interface — reset()</code> and sample(spans)</code> — with two implementations.</p>
softdirty</code></strong> asks the kernel, as above. No memory reads, roughly 0.13 ms per
sample on a small process.</p>
hashdiff</code></strong> reads each page and hashes it, comparing against the previous
sample. A page whose hash changed was written. This works anywhere memory can be
read — /proc/PID/mem</code> on Linux, vm_read</code> on macOS, ReadProcessMemory</code> on
Windows — because the only platform-specific part is the read.</p>
It has a real blind spot: a write that restores a previous value leaves the
content unchanged, so the hash cannot see it. Soft-dirty sees the write
regardless of the value. That blind spot is exactly what the model-fit check
flags — in the validation run, six pages came back ?</code>, and all six were pages
softdirty</code> independently showed as saturated.</p>
Two mechanisms that share only the analysis, disagreeing in a predictable
direction, is a more useful arrangement than either alone.</p>
🔗</a>Validation</h2>
A synthetic target writes four populations at time-paced</strong> frequencies. The
pacing matters, and getting it wrong wasted a full cycle: an earlier version
paced by loop count, and “every 50 iterations” in a Python loop turns out to be
roughly 60 kHz. Nothing in that workload was slow, so nothing discriminated, and
the tool looked broken when it was reporting correctly.</p>
tier</th> pages</th> ground truth</th> softdirty</code></th> hashdiff</code></th></tr></thead>

hot</td> 4</td> as fast as the CPU allows</td> > ceiling</code></td> > ceiling</code></td></tr>
warm</td> 8</td> 200 Hz</td> 196 Hz</strong></td> 198 Hz</strong></td></tr>
cool</td> 8</td> 5 Hz</td> 5 Hz</strong></td> 5 Hz</strong></td></tr>
cold</td> 2048</td> written once at startup</td> absent</td> absent</td></tr>
</tbody></table>
Both tiers were recovered as contiguous eight-page runs at the right addresses.
The 2,048 cold pages, written once and then left alone, correctly never appear.</p>
Two independent mechanisms converging on ground truth is the point. They share
the inversion and the fit check; they share no part of the measurement.</p>
🔗</a>What “normal” has to mean</h2>
Finding the fastest page in a process is not the same as finding one that is
faster than it should be</em>. The second needs a baseline, and a baseline for
memory runs into a hard constraint immediately.</p>
ASLR relocates every mapping on every run.</strong> The address 0x7d34c29b3000</code> in
today’s process is unrelated to the same number tomorrow. A profile cannot store
addresses.</p>
What survives a restart:</p>

File-backed pages</strong> have a stable identity. libxul.so+0xa000</code> names the same
data on every run, on every machine with that build.</li>
Anonymous pages</strong> have none. Heap and allocator arenas are laid out
differently each time.</li>
</ul>
In a browser this bites hard. Of 1,170 written pages in a Firefox content
process, nine had stable identity</strong>. Almost all write activity is anonymous,
so anonymous memory cannot be treated as the leftover case.</p>
🔗</a>The percentile trap</h3>
The first attempt scored each anonymous page against the 95th percentile of the
baseline’s pooled frequencies. It produced 29 findings on a process compared
against its own baseline.</p>
They were all false. The flagged pages were allocator arenas running at 24–27 Hz
— entirely ordinary behaviour — sitting above a percentile dominated by roughly
1,600 near-idle pages. Comparing individuals against a pooled percentile flags
the top 5% by construction</em>. The test could not not fire.</p>
The fix is to compare curves rather than points</strong>. Store each baseline run as
its own sorted frequency curve, and judge the live capture’s k-th fastest page
against the fastest k-th page any baseline run produced. A process that is
merely busier shifts the whole curve and is judged as such. A single injected
hot page spikes one rank and stands out.</p>
Same captures, same data: 29 false positives to zero</strong>.</p>
🔗</a>A signal that survives the ceiling</h3>
There is one more comparison worth making, because it does not depend on
frequency at all: how many pages sit above the resolution ceiling</strong>. Unlike a
frequency, that count is not capped by the ceiling, so it keeps working on large
processes where everything interesting saturates.</p>
It was exactly 17 in both baseline runs of the synthetic target, and 18 with an
injection present.</p>
🔗</a>Detection, with a control</h3>
The test workload gained two pages written at 800 Hz — a small, fast region
against a busy background, which is the shape of the thing worth finding.</p>
run</th> novel pages</th> over baseline</th> ceiling population</th></tr></thead>

control</strong> — clean vs its own baseline</td> 0</td> 0</td> 17 (baseline 17–17)</td></tr>
detection</strong> — injected vs clean baseline</td> 0</td> 1, at 14×</strong></td> 18 (outside 17–17)</strong></td></tr>
</tbody></table>
The injected region was caught at rank 8, 2,769 Hz against a 192 Hz baseline,
and independently by the ceiling population. The control reported nothing
outside the baseline</em>.</p>
Repeating the detection against a freshly started process — new PID, new ASLR
layout, the hot region at a completely different address — reproduced both
signals. The baseline is genuinely address-independent.</p>
🔗</a>Profiling by library and function</h2>
Addresses are unstable and anonymous memory is anonymous, but code has stable
names</strong>. A function sits at a fixed offset inside its library, so
libxul.so!AppendElement</code> is the same identity on every run.</p>
Hardware sampling reports the instruction pointer and the data address in the
same sample</em>, which is enough to key a profile on which function touched which
kind of region:</p>
  samples   per sec  region      perms  function
</span>      810       202  [stack]     rw-p   python3.12![unknown]
</span>      367        92  [stack]     rw-p   python3.12!_PyEval_EvalFrameDefault
</span>      361        90  [anon]      rw-p   python3.12!_PyEval_EvalFrameDefault
</span></code></pre>
An anomaly is then a pair the baseline has never seen — some function writing
somewhere it has never written before. That is a far sharper statement than
“page 0x7d34 is busy”, and it is legible without a debugger.</p>
Getting the samples required working around the tooling. On this hardware
perf mem record</code> cannot attach to a running process: it wraps AMD IBS as
ibs_op/ldlat=0/</code>, which is rejected for an existing PID. The raw event works —
perf record -e ibs_op// -d -p PID</code> — and the -d</code> is essential, because without
it every sample carries no data address at all and perf script -F addr</code> refuses
outright. Stores are separated from loads afterwards, from the data_src</code> field.</p>
Kernel-context samples are dropped. Their data addresses are kernel addresses,
absent from the process’s maps, and not a property of the application being
profiled. Leaving them in produced three spurious “never seen before” findings
in the first control run.</p>
Baseline stability is good: independent runs of the same workload produced 37
distinct function-to-region pairs, twice.</p>
🔗</a>The negative result</h2>
The symbol profiler did not detect the injection.</strong></p>
This deserves to be stated plainly, because the two instruments look
interchangeable and are not.</p>
</th> injected [anon]</code> store rate</th> baseline</th></tr></thead>

measured</td> 118/s</td> 112/s, 121/s</td></tr>
</tbody></table>
Statistically identical. The control was clean and the detection was clean, and
the second of those is a miss.</p>
The reason is structural. IBS samples store volume.</strong> Eight hundred stores per
second of injected activity is invisible against millions of interpreter stores
per second — it does not shift the sampled distribution at all. Soft-dirty
counts pages touched</strong>, and two extra hot pages are obvious against a working
set of thirty-five. Worse for the symbol view, an interpreter funnels everything
through one eval loop, so the function key carries almost no information about
this workload.</p>
So the two instruments answer different questions, and the difference is not
cosmetic:</p>

Page frequency</strong> is sensitive to a small region changing fast</em>. It is the
right first instrument for machine-speed activity.</li>
Symbol sampling</strong> is sensitive to a shift in where the bulk of memory
traffic happens</em>, and to code appearing where it has no business being — a new
library writing somewhere, injected code carrying its own symbol, any function
writing into an executable mapping.</li>
</ul>
A detector that had only been tested on the case it catches would have shipped
with the wrong claim attached.</p>
🔗</a>They compose in one direction</h3>
The miss points at the fix. Sampling is proportional to traffic volume, so a
low-volume region is invisible in a whole-process profile — but not in a profile
narrowed to that region and sampled hard.</p>
# 1. where — page frequency finds the anomaly
</span>memwatch.py compare myapp cap.json
</span>   -> 0x71feaa875000   2,798 Hz   baseline 192 Hz @rank 8
</span>
</span># 2. who — hardware sampling attributes it
</span>memwatch-sym.py attribute $PID 0x71feaa875000+2 -d 15 --period 2000
</span>   -> 8,690 stores   python3.12!_PyEval_EvalFrameDefault
</span></code></pre>
Narrowed to two pages, 17,515 of 261,613 addressed samples landed inside the
range — 6.7% of all sampled memory traffic, from a region that was undetectable
in the whole-process view minutes earlier.</p>
Find the where</em> with the instrument that measures rate. Attribute the who</em>
with the instrument that measures volume. Neither substitutes for the other.</p>
🔗</a>What it costs, and where it stops</h2>
The cheap path has a scaling property worth knowing before trusting its output.
clear_refs</code> walks every page-table entry in the process</strong>, so its cost tracks
the whole address space rather than the part under investigation.</p>
target</th> mapped pages</th> clear_refs</code></th> full pagemap read</th> usable ceiling</th></tr></thead>

synthetic</td> 7,309</td> 0.06 ms</td> 0.07 ms</td> ~2,800 Hz</strong></td></tr>
Firefox</td> ~3,666,000</td> 5.2 ms</td> 38.0 ms</td> ~160 Hz</strong></td></tr>
</tbody></table>
Narrowing the sweep to candidate pages removes the 38 ms read entirely. It
cannot touch the 5.2 ms reset.</strong> On a multi-gigabyte process, anything above
roughly 160 Hz reads as “at ceiling”, and going finer requires the hardware
path — which is precisely where the ceiling-population signal earns its place.</p>
On that same Firefox process the instrument still did its job: two anonymous
pages pinned above the ceiling at a robust z-score of 108, standing clear of a
~25 Hz background of allocator and library churn. Saturated, but unambiguous.</p>
The rest of the limits, stated once:</p>

Soft-dirty attributes a write to a page, never to code.</li>
hashdiff</code> misses writes that restore a previous value, and costs a full read
of the working set per sample. The ?</code> flag marks where this has happened.</li>
Hardware sampling is statistical. A rate from it is samples</em> per second, not
stores per second — comparable only against captures taken at the same sample
period.</li>
Both tools observe a running process. Neither is a forensic dump analyser.</li>
os.access()</code> is not a sufficient permission check for either path. It
consults file permissions only, while pagemap</code> additionally requires
PTRACE_MODE_READ</code> and /proc/PID/mem</code> requires PTRACE_MODE_ATTACH</code>, which
yama/ptrace_scope ≥ 1</code> denies for any process that is not a descendant. The
tools probe by opening for real.</li>
macOS and Windows collectors are not implemented.</strong> The analysis is
platform-independent and hashdiff</code> is the shape they would take, but that
code is not written, and neither platform has a soft-dirty equivalent — both
would run at hashdiff cost with hashdiff’s blind spot.</li>
</ul>
🔗</a>What generalises</h2>
Three things here are not about memory.</p>
A binary observation per interval is not a rate.</strong> It looks like one, it
tabulates like one, and it saturates without saying so. Wherever an instrument
reports whether something happened during a window, the window is part of the
measurement, and one window is not enough.</p>
Sweeping a parameter recovers what a single setting destroys.</strong> The frequency
was never in any individual sample; it was in how the answers changed as the
window shrank.</p>
A detector should be tested against the case it misses.</strong> The control run and
the detection run together are the experiment — either alone supports a claim
that the other refutes. The symbol profiler’s clean control looked like success
until the injected workload produced the same clean result.</p>
For the adversarial case specifically, the most durable signal turned out to be
the crudest one: not how fast a page changes, which the instrument can only
measure up to its own ceiling, but how many pages are changing faster than the
instrument can follow</strong>. That count is not capped, it is stable across runs of
the same workload, and it moved the moment something started operating at a
speed the baseline had never contained.</p>


The asymmetry does not survive contact
2026-09-11T00:00:00+00:00
The oldest line in this trade is that the attacker has to be right once and the
defender has to be right every time. It was never quite true — attackers fail
loudly and often, and most of them are not very good — but it described
something real about the shape of the work. One side searches. The other side
covers.</p>
Autonomy was supposed to close that gap, because the side doing more work
benefits more from doing it faster. That is not what has happened so far, and
the reason is worth being precise about.</p>
🔗</a>What an attacking agent is actually good at</h2>
Not exploitation. The exploitation step was already automated, and has been for
twenty years — that is what a scanner is.</p>
What changed is the connective tissue</strong>. An agent will read a certificate
transparency log, notice a hostname nobody meant to publish, guess at what
framework it runs, pull the matching misconfiguration, try it, fail, read the
error, and try the adjacent thing. None of those steps is hard. Chaining them
without a human in the loop is what used to cost time.</p>
That is a search problem, and search is exactly what these systems do well. An
attacking agent can be wrong ninety-nine times in an hour at no cost, because
the ninety-nine failures are free and the hundredth is the whole engagement.</p>
🔗</a>What a defending agent is asked to do</h2>
Something structurally harder, and it is not “the same thing but blue.”</p>
A defending agent operates where being wrong is expensive in both
directions</strong>. Miss something and the intrusion continues. Act on something
benign and you have isolated a production host, revoked a working credential,
or paged six people at 03:00 because a backup job looked like exfiltration.</p>
An attacking agent’s false positives cost it nothing. A defending agent’s false
positives are the reason nobody trusts it with anything that matters — which
means it gets deployed in advisory mode, which means it does not act, which
means it is a very expensive alerting system.</p>

The attacker’s agent is allowed to be stupid ninety-nine times. The
defender’s agent is allowed to be stupid approximately never.</p>
</blockquote>
🔗</a>Where this actually bites</h2>
Speed is not the differentiator people think.</strong> Defenders already have
machine-speed controls: rate limits, WAF rules, EDR quarantine. Those work
because they are narrow and their failure mode is understood. The slow part of
defense was never detection latency, it was deciding whether to act</strong> — and
that is precisely the part an agent is least trusted to own.</p>
Autonomy needs reversibility.</strong> The defensive actions safe to automate are
the ones you can undo: isolate a host, hold a message, force reauth. The ones
that matter most — revoke, wipe, disable, block at the edge — are the ones
where being wrong has a cost you cannot take back. An agent that can only take
reversible actions is useful, but it is not symmetric with an attacker that has
no such constraint.</p>
Evidence outlives both.</strong> Whatever an attacking agent does, you will be asked
afterwards what happened. Whatever a defending agent does, you will be asked
the same thing — and “the model decided to” is not an answer that survives a
regulator, an insurer, or a board. The audit trail is now a defensive control
in its own right, and it has to be written somewhere neither agent can reach.</p>
🔗</a>Where the asymmetry runs the other way</h2>
There is one place the defender is structurally ahead, and it falls out of the
same property that makes the attacking agent cheap: it has to run its loop on
your ground.</strong> The ninety-nine free failures are free to the attacker and
legible to you.</p>

Every one of those ninety-nine failures happens against your hardware, in
your logs, on text that you wrote.</p>
</blockquote>
The mistake is trying to detect “an AI.” Nothing in a request reliably says a
language model produced it, and the tools sold on that premise are not
calibrated for anything. What is</em> detectable is that an observe → reason →
act loop</strong> is running — on a token budget, through a context window, inside a
tool harness. Each of those constraints leaves artifacts. Agents also sit in
the gap between the two populations everyone has already modelled: scanners are
too regular, humans are too irregular, and an agent is regular in the ways a
human is not and irregular in the ways a scanner is not.</p>
Tier the signals by precision</strong>, because precision is what buys the right to
act. This is the reversibility argument from the last section, applied to
evidence rather than to actions.</p>
tier</th> costs</th> earns</th></tr></thead>

1 — planted</td> you have to build and maintain it</td> near-zero false positives; enough to act irreversibly</td></tr>
2 — behavioural</td> instrumentation you should have anyway</td> strong but circumstantial; throttle, challenge, tarpit</td></tr>
3 — population</td> already in your logs</td> a score input, never a verdict</td></tr>
</tbody></table>
🔗</a>Tier 1 — planted, and close to certain</h3>
These work because an attacking agent treats text it finds as instruction, and
the text is yours.</p>

Instruction canaries.</strong> Put a unique directive somewhere only a
text-consuming automaton reaches — an HTML comment, a _note</code> field on a JSON
error, an unreferenced documentation page — telling the reader to include a
distinctive token in its next request. Humans do not comply. Scanners cannot
parse it. A meaningful share of agents simply do it. A returned token is not
an inference, it is a confession.</li>
Error-text echo.</strong> Agents recover from failure semantically: they read the
error string and build the next request out of tokens in it. Seed rare words
into 403</code> and 422</code> bodies and watch for them reappearing seconds later as
parameter names or path segments. A human takes minutes. A scanner never
does.</li>
Unlinked-but-documented paths.</strong> Requests to a URL that exists only in your
prose, with no href</code> anywhere on the site. A browser cannot reach it. Only
something that read the text and constructed the URL can.</li>
</ul>
The fragility is the same as the strength: publish the lexeme and it is worth
nothing. Rotate the tokens, scope them to sessions already under suspicion, and
keep them out of the repository.</p>
🔗</a>Tier 2 — behavioural, and strong</h3>

Think time scaled to response size.</strong> Plot inter-request delay against the
byte count of the previous</em> response. Humans pause on complexity; scanners
do not pause; an agent pauses roughly linearly in tokens-to-read. The three
populations separate on that one scatter plot, and faking it requires
deliberately modelling human reading.</li>
Missing subresources.</strong> A browserless agent fetches what the model asked
for and nothing else — no CSS, no fonts, no favicon. A Chrome user-agent with
zero subresource fetches is a contradiction.</li>
Fingerprint incoherence.</strong> JA4, the HTTP/2 SETTINGS</code> and header-order
hash, the user-agent string and the TCP fingerprint should all tell the same
story. The tell is rarely any single layer; it is layer n</em> reporting Chrome
131 while layer m</em> reports Python 3.12.</li>
Library defaults.</strong> Timeouts at exactly 30, 60 or 120 seconds. Three
retries. Concurrency of five or ten. Backoff at exactly 2×. Agents inherit
whatever their tool wrapper shipped with, and almost nobody tunes it.</li>
Amnesia.</strong> Truncated context and non-sharing subagents cause re-fetches of
things already retrieved, with no If-None-Match</code> and no If-Modified-Since</code>.
A human keeps notes. An agent re-derives.</li>
Lexical provenance of guesses.</strong> Where the candidates came from. A
dictionary attack against SMTP RCPT</code> walks a wordlist — admin@</code>, info@</code>,
sales@</code>. An agent guesses names it read off your website: low-frequency,
real, and correlated with public content. The same split shows up in guessed
paths and guessed parameter names.</li>
</ul>
Enough to throttle, challenge or tarpit. Not enough to block, because a badly
written legitimate client trips several of them at once.</p>
🔗</a>Tier 3 — population, and cheap</h3>
ASN and egress reputation. Path-sequence entropy, fitted as an n-gram over
transitions — a human follows the link graph, a scanner follows a wordlist, an
agent sits between them. Natural language turning up in fields that should not
contain any. These are already in the logs and cost nothing to compute; none of
them is a verdict.</p>
🔗</a>Slowing it down</h3>
The economics differ from a human adversary. This one is metered: a token
budget and a context window, both finite, both billed.</p>

Semantic denial.</strong> Uniform, low-entropy errors across every failure mode.
The loop runs on your feedback; starve it and it flails. Cheapest measure
here, and it costs only your own debuggability.</li>
Per-session nondeterminism.</strong> Rotate field names, parameter ordering and
endpoint shapes per session so cached reasoning goes stale. Browsers do not
care. Agents spend context re-deriving.</li>
Stateful multi-step flows</strong> with server-side nonces on short TTLs, raising
the number of tool calls per unit of progress — which is where long runs
derail.</li>
Proof of work</strong> at the edge. It will not stop an operator who wants you
specifically; it changes the volume economics for everyone else.</li>
Tarpits</strong> serving endless plausible content, if you will accept the log
pollution and the risk of poisoning your own analytics.</li>
</ul>
🔗</a>What does not work</h3>
User-agent matching, spoofed in one line. CAPTCHAs, which multimodal models
now beat and which tax your actual users. Generated-text detectors. And
blocking on any single signal, which costs you the observability that
everything above depends on.</p>
None of these rules will last. Agent behaviour moves with every model release,
so build a durable feature pipeline and disposable rules</strong> — log the
primitives cheaply and forever, and expect to rewrite the scoring quarterly.
Then band the response rather than classifying: observe, tarpit, challenge,
block, in that order, with only Tier 1 permitted the last one.</p>
🔗</a>The honest position</h2>
Agents shift the attacker’s cost curve more than the defender’s, because the
attacker is doing search and the defender is doing judgement, and only one of
those is cheap to get wrong.</p>
That is not an argument against defensive automation. It is an argument for
being specific about which decisions you are automating, what happens when the
agent is wrong, and who finds out. Most of the answer is old: scope the
credentials, gate the irreversible, keep the log out of reach.</p>
The tooling is new. The posture is not.</p>
Adversarial Agents

A bit is not a counter

The asymmetry does not survive contact
