Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-11 · Instrument version 1.0.0
What Matters
An access gate can stop abuse and still reject legitimate buyers. Measure both outcomes on the same defined population before calling an agent-admission policy effective. DN’s assessment separates identity, permission and behaviour, then reports false rejection, abuse admission and recovery effort. It evaluates a controlled test; it does not certify a bot or authorize access.
A blocked buying agent may look like a successful security event in one dashboard and a lost legitimate order in another. Neither perspective is sufficient alone. The merchant needs evidence about who was blocked, why, and whether an appropriate recovery path remained available.
This is a narrow admission-testing method, distinct from a general accessibility checklist or reputation ranking. It asks whether a particular gate makes the intended decision for a defined request. A real test requires the merchant’s authorization, labelled cases and a safe test environment. No live merchant was probed for this article.
DN Evidence Block
Sources reviewed: 2026-11-11 · Evidence type: Primary documentation review and original DN method; examples are explicitly synthetic.
Scope: A merchant-controlled evaluation of allowed and disallowed requests at a specified access gate.
- Cloudflare documents verified-bot classification and Web Bot Auth identity mechanisms: Cloudflare: Verified bots; Cloudflare: Web Bot Auth.
- Identity evidence does not establish every purchase permission or the acceptability of all subsequent behaviour. DN’s distinction is an operational inference.
Not established by this work: No bot-rejection benchmark, abuse bypass, order or production traffic experiment was performed.
Original DN instrument · version 1.0.0
DN Agent-Admission Confusion Matrix
Calculate two error rates for a labelled, permitted test set. The tool does not inspect requests or decide labels.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
No attack simulation, live request, traffic authorization or statistical confidence estimate. Recovery effort is an entered average, not measured abandonment.
1. Identity: what does the signal actually establish?
Cloudflare’s Web Bot Auth documentation describes signed HTTP request identity signals. Its verified-bot documentation describes a classification process. These are concrete examples of admission evidence; they are not a universal entitlement to access every merchant or complete every transaction.
Record the identity mechanism and the evidence it validates. A recognized operator, a signed request and a permitted purchase are different conclusions. Identity helps the merchant apply policy to a known source; it does not establish that every action requested by that source should be accepted.
An unknown identity should remain unknown until the relevant process resolves it. Do not infer abuse solely from absence of a preferred identifier. Equally, do not describe an unverifiable identity as a successfully authenticated buying agent. The test needs to separate identity support from the decision to permit the action.
For an observed rejection, preserve the returned reason and the stage reached. This makes it possible to ask whether identity recognition failed, whether the identity was unsupported or whether the policy correctly declined a request from a recognized operator.
2. Permission: was this exact action authorized?
Write the policy in terms of an action and scope: read a public offer, obtain an authenticated account quote, reserve stock or submit a purchase. Record the reason each action is allowed or declined. A request to reserve limited inventory should not inherit permission merely because reading the same product page was allowed.
Write the authority boundary for the buyer and the merchant. Permission from a buyer to purchase does not override the merchant’s supported access conditions. Permission to read a price does not necessarily include creating holds or submitting orders. The relevant test case should identify the action, account, resource and limit.
Use the declared merchant policy to label the expected decision before observing the gate. If the merchant does not offer the route under test, report that coverage limit. A comparison with a supported route can still be commercially useful, but it should not mislabel the unsupported request as a measured false rejection.
A clear permission record also improves the repair step. The operator can request access for one bounded action instead of asking for a blanket exception to all controls.
3. Conduct: does the request stay within the permitted behavior?
A known operator can exceed agreed request limits or request an unsupported action. An unfamiliar operator can make an appropriately authorized request through a supported route. Keep actual conduct separate from identity reputation. The test should specify the request purpose, rate, state changes and other conditions relevant to the merchant’s policy.
Detecting automation is not the same as deciding whether the business wants the automated request. Cloudflare describes its bot score as a signal about automation likelihood. DN’s inference is that a detector can identify automation correctly while a merchant’s policy rejects an automated request the merchant intended to allow. Locate the error in the correct layer.
A narrow correction should preserve the controls needed for disallowed conduct. Retest both desired and undesired actions after a policy change rather than assuming that admitting a legitimate client makes every request from it acceptable.
4. Reference labels: can the test identify a false rejection?
The fourth check is the reference label. If the gate’s own verdict defines which cases count as legitimate, false rejection becomes impossible by construction. Create a labelled evaluation set using merchant policy and independently reviewed request records. Include representative allowed requests and known disallowed variants, with the smallest relevant difference between them.
Keep unknown cases outside the rate calculation until adjudicated. A request with uncertain authority is not automatically abuse, and a rejected request is not automatically a legitimate customer. Record ambiguous cases as a separate count. The label should describe what the merchant intended to permit, not whether a test script eventually found a route through.
Control account state, request purpose, traffic volume, time window and surface. If one agent uses a documented API and another uses an unsupported route, a comparison can reveal coverage differences but cannot isolate identity treatment. Use synthetic accounts and approved requests where possible. Do not disguise clients or circumvent controls to improve the result.
Choose the counting unit carefully. If one legitimate purchase creates twenty HTTP requests, counting requests can make a gate look worse or better than counting completed purchase attempts. Keep both where useful, with a clear relationship between them. A test case should identify the intended action and the terminal outcome; retries belong to that case unless the evaluation explicitly studies individual request decisions. Otherwise one repeatedly blocked client can dominate the denominator without representing twenty independent buyers.
5. Error tradeoffs: are both rejection and admission measured?
The fifth check is a paired confusion matrix. False-rejection rate is legitimate requests rejected divided by labelled legitimate requests. Abuse-admission rate is labelled disallowed requests admitted divided by labelled disallowed requests. Report each denominator, because a small sample can produce a precise-looking percentage without much evidence.
Consider an illustrative set of 100 legitimate cases and 40 disallowed cases. If the gate rejects 12 legitimate cases and admits two disallowed cases, the rates are 12% and 5%. These figures describe this constructed test only. They are not a claim about a vendor, the internet’s abuse prevalence or the fraction of actual orders a merchant would lose.
Changing the threshold may improve one direction while worsening the other. Choose a policy based on the consequences of the specific actions and the merchant’s requirements. Do not collapse the rates into an invented universal safety score. A false rejection during public browsing and an unauthorized high-value reservation have different operational consequences.
A small sample also limits what a zero-error result means. If no disallowed request is admitted in ten constructed cases, the observed rate is zero for those ten cases. It does not establish that the gate never admits abuse. Preserve which behaviours were represented and which were absent. For a decision involving a rare but consequential failure, targeted cases may be valuable even when they are not a representative prevalence sample; label that purpose instead of mixing them into an unexplained aggregate.
For a synthetic policy comparison, suppose a revised gate reduces legitimate rejections from 12 to seven on the same 100 cases while admitted disallowed cases rise from two to four on the same 40. Report both changes. Whether the trade is acceptable depends on the permitted action and consequences. The method deliberately leaves that decision with the policy owner rather than declaring the lower rejection count an automatic improvement.
6. Recovery: what work remains after a legitimate rejection?
The sixth check follows the legitimate buyer after rejection. Is there an accessible confirmation route, a supported alternative interface or a human escalation that can preserve the quote and account state? Count the time spent, repeated data entry and failures to resume. A challenge that is theoretically solvable can still impose unacceptable effort in the actual workflow.
If the illustrative 12 rejected cases each take an average of six active minutes to resolve, the model records 72 minutes of recovery effort. This is a conditional estimate from entered values. It does not price abandoned demand or assume that every rejected buyer tries again. Keep successful recovery, abandoned recovery and unresolved recovery as separate outcomes in the underlying log.
Also check what was never observed. A gate may fail before the normal analytics event fires. Count attempted work from a controlled client-side test ledger and reconcile it with merchant logs. Otherwise the dashboard can quietly omit the rejected requests and report an unrealistically smooth completion rate among the survivors.
Check that the recovery route is supported for the actual environment. Cloudflare’s challenge documentation distinguishes browser support and automated testing conditions. This is an integration constraint to account for, not an invitation to defeat a challenge. Use merchant-approved alternatives and retain unresolved cases when no supported recovery is available.
7. Reproducibility: what evidence justifies changing the gate?
The seventh check is reproducibility. Save the gate version, relevant rule configuration, client identity mechanism, test case version and observation period. Repeat the same fixed cases after a material policy change, then add new cases that represent newly observed failures. Retain the old result so improvement is distinguishable from a changed population.
A useful acceptance condition is specific: reduce a particular legitimate rejection pattern without increasing admission of a named disallowed action beyond the agreed limit. That condition needs an owner and an escalation route. An overall improvement can hide a serious regression for a small group or a high-consequence action.
The commercial question is whether the supported admission path creates dependable buying access at an acceptable operating cost. That requires completed legitimate tasks and incident outcomes over time, not only a bot label. Publish the test’s boundaries and unresolved cases. If the merchant has not authorized the evaluation or cannot establish reference labels, report a proposed method rather than presenting a benchmark result.
Retain a small set of previously troublesome legitimate cases after the fix. They become regression cases, while a separate refreshed set tests whether the policy generalizes. Passing only the cases used to tune the rule would not demonstrate that unfamiliar legitimate buyers receive the same treatment. Record which cases informed the change and which were reserved for later evaluation.
Methodology, limitations and corrections
Specify the allowed action and its policy before constructing cases. Have a second reviewer label permitted and disallowed requests without seeing the gate verdict where practical. Preserve uncertainty rather than forcing every case into a binary class.
Run only an authorized test on a supported environment, reconcile expected requests to observed gate events, and report rejected legitimate cases alongside admitted disallowed cases. The synthetic example demonstrates arithmetic. A production claim additionally needs representative traffic, an observation window and appropriately reviewed labels.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version1.0.0, 2026-11-11. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does a verified bot have a right to buy?
A verified identity signal does not establish every merchant permission, account entitlement or buyer authorization.
Is every challenge a false rejection?
No. Define the intended policy and final action. A challenge can be appropriate, but its recovery burden should still be observed.
Can I compare two gates with different cases?
You can describe each result, but the difference cannot be attributed solely to the gates. Matched cases provide a more interpretable comparison.
Why is there no overall admission score?
The two error directions have different consequences. A single score would hide assumptions about their relative cost.
Primary sources
- Cloudflare: Verified bots. Verified bot identity/status is a documented access-control signal; it does not guarantee admission by every merchant. Reviewed 2026-11-11.
- Cloudflare: Web Bot Auth. HTTP signatures and registered keys can establish identity claims; underlying drafts and deployment support must be distinguished from universal standards. Reviewed 2026-11-11.
- Cloudflare: Bot score. Bot score concerns automation likelihood; permission and desired business behavior require separate policy decisions. Reviewed 2026-11-11.
- Cloudflare: Supported browsers for challenges. Challenge support has browser and automation-testing boundaries; use supported environments and authorized recovery routes. Reviewed 2026-11-11.
Turn the finding into a decision
The DN Research Desk can scope a permitted admission-policy evaluation with a labelled case set, subject to source access and a written quote. Start with one unresolved decision and the records available to answer it. This article does not promise a completed audit, integration or independently verified result.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
