Security Checks Need to Run Before Risky Code

A disabled feature may still process an outsider's input before the software rejects it. For agent builders, the location of a security check matters as much as whether the setting exists.

Anthropic's October 20 attack-surface report, by Chris Rohlf, examines code that can run unnecessarily in deployed software. Its OpenSSH example shows how a restriction can appear to work while leaving substantial processing exposed before the decision.

The check came after the processing

Anthropic reports that OpenSSH 10.4 allowed an unauthenticated client to reach roughly 4,500 lines of experimental signature-processing code, even when the relevant algorithm was excluded by configuration. The software parsed the supplied key before checking whether its type was allowed.

Moving a check earlier was not sufficient by itself. Anthropic describes subsequent gaps involving a difference between the advertised algorithm and the type inside the submitted key, plus certificate handling that reached a signature verifier before consulting configuration. The report says fixes shipped in OpenSSH 10.6 placed the relevant checks inside the parser, before the corresponding processing.

This was unnecessary reachability, not a demonstration that every reachable line contained an exploitable vulnerability. The security benefit is reducing the code an unauthenticated caller can exercise, including code with defects defenders have not yet found.

Across 25 projects, Anthropic reports 493 issues from default configurations, interacting settings and early reachability. Those are author-reported findings from this analysis, not a general vulnerability rate or a measurement of agent safety.

The same ordering question in an agent service

Consider a hypothetical agent at a retailer processing requests for access to its inventory system. Employees submit a manager's approval document through an internal portal. In this example, the service accepts uploads only from signed-in employees and supports a limited set of document formats.

If the service opens and parses an attachment before checking identity and format eligibility, rejection at the end does not undo the processing. The agent may never receive the document, yet the upload service has already exposed its parser to an unauthorized request.

The useful review question is therefore specific: what executes before the gate? Authentication cannot precede every byte of network handling, but expensive or unnecessary document processing need not automatically occur before eligibility is established. Checking an advertised file type also needs to agree with what the processing path actually accepts.

Review the compiled path, not only the declaration

For WTK, target compilation connects a catalog package to a runtime with concrete tools and dependencies. Review should identify where a required restriction takes effect along that actual path, including services outside the model's immediate tool interface.

The report describes confirming findings with dynamic program traces and comparing modified builds against baseline tests. Changes affecting non-default configurations are reserved for human decisions. That supports higher-level oversight: automate bounded analysis and regression checks, while people decide changes to intended service behavior.

Our configuration-enforcement question becomes more precise here. Does the control prevent the unwanted processing, or merely reject its result? Evidence should identify the earliest disallowed operation and show that the restriction acts before it.