Outrings
AI agents and automation

What should an AI agent do when it cannot determine something?

Why "not checked" and "passed" must never be the same answer, and how a well-built tool keeps them apart.

4 min read
Short answer

Say so, name the reason, and keep it out of the pass count. A check that timed out, was blocked, or needs a browser to evaluate has produced no verdict — and folding it in with the successes converts an unknown into a false reassurance, which is the most damaging thing an audit can do.

The three-state rule

Most tools report two states: pass and fail. That is one state short, and the missing one is where the harm accumulates.

StateMeansSafe to report as
PassObserved, and the rule was satisfiedFine
FailObserved, and the rule was not satisfiedA problem
UndeterminedNo observation was obtainedNeither. Report separately, with the reason.

When undetermined is collapsed into pass, a site that blocked half the audit scores well. When it is collapsed into fail, a site behind a strict firewall looks broken. Both are wrong in ways that are hard to detect from the output, which is why the third state has to survive all the way to the reader.

The reasons are not interchangeable

Saying "unknown" is better than lying, but it is not enough. Different causes call for different responses, and an agent can only choose correctly if the tool distinguishes them.

  • blocked — the target refused the request. Often a WAF or bot protection. The site may be perfectly configured; you simply are not allowed to look. Retrying from another network sometimes resolves it.
  • timeout — no response in the time allowed. Might be a slow origin, might be transient. Worth one retry before drawing any conclusion.
  • requires_browser — the answer only exists after JavaScript runs. Not a failure of the site or of the tool. It is a statement about where the fact lives, and it will not change on retry.
  • inconclusive — the observation was obtained but does not decide the rule either way. Genuinely ambiguous, and honest to say so.
  • unknown — no more specific reason available. The weakest of the five, and a tool that returns it often is under-reporting.
The distinction between blocked and requires_browser matters especially. The first says "try differently". The second says "no HTTP client will ever answer this" — and an agent that keeps retrying it is wasting time on a question that has no server-side answer.

What the agent should say

The pattern that works is short and specific: state what was determined, then state the boundary in the same breath.

  • Good: "Security scores 68. CSP is absent and the server banner discloses its version. Two checks could not be evaluated — the cookie policy needs JavaScript to run, and the admin path returned a challenge page."
  • Bad: "Security scores 68 with two issues found." — the two undetermined checks have silently become passes.
  • Also bad: "I was unable to fully audit the site." — true, unhelpfully vague, and it discards the eighteen checks that did succeed.

The first version is barely longer than the second and is the only one a reader can act on correctly.

Why scoring has to exclude it

An undetermined check must not contribute points in either direction. If it counts as a pass, blocking the auditor becomes a way to raise your score — an incentive no measurement system should create. If it counts as a fail, sites with strict security controls are punished for having them.

The correct treatment is to score what was observed and report the coverage separately, so a score of 82 with four undetermined checks is legible as exactly that, rather than being averaged into something that looks precise and is not.

What our audit reports about this

Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.

  • Five distinct undetermined reasons — unknown, blocked, timeout, inconclusive, requires_browser — rather than one catch-all.
  • Undetermined checks excluded from scoring entirely, in both directions, and reported in their own array.
  • A provenance label on every check: measured, derived, inferred or external, so an agent can weight a heuristic differently from an observation.
  • A notCovered list distinguishing "we never check this" from "we tried and could not determine it".

For agents and scripts, the same measurement is at /api/v1/summary?url=yoursite.com — see the API documentation.

Related questions

Why not just retry until it works?

Retrying helps for timeouts and sometimes for blocks. It never helps for requires_browser, because no number of HTTP requests will run JavaScript. A tool that does not distinguish the reasons cannot know which retries are worth attempting.

Does a site blocking the auditor mean it is well secured?

It means bot protection is active, which is a fact about the edge rather than about the origin. It says nothing about whether the security headers behind it are correct — which is exactly why the result is reported as blocked rather than scored either way.

Is "inferred" the same as undetermined?

No. Inferred means a verdict was reached by heuristic rather than direct observation — it has a value, and the value can be wrong. Undetermined means no verdict was reached at all. Both are labelled, and they should be weighted differently.

How many undetermined checks is normal?

On a straightforwardly served site, typically zero to three, mostly items that genuinely need a browser. A large number usually means bot protection is intercepting the audit rather than that the site is unusual.

Read next

All 100 guides · How every check works · API for agents