A useful job for the agent that helped build your application is to go back through it and ask a different question: what can somebody reach before they have earned access?
I like this direction because it gives AI development a practical follow-through. Getting a feature working is satisfying. Understanding when its code runs, who can trigger it and whether it needs to be exposed is part of taking ownership of what you built.
A familiar security principle, applied by an agent
In research published on 20 October 2026, Anthropic reports 493 issues across 25 open-source projects. Its focus includes unnecessary default exposure, conflicting configuration options and code reached before an appropriate gate. Those are vendor-reported issues, not 493 demonstrated exploits or our own measurements. In its gated-project subset, Anthropic says the reported issues were not immediately exploitable on their own.
The underlying principle is established. OWASP’s attack-surface guidance encourages understanding entry points, sensitive data and the controls protecting access. An agent can help trace those paths through a repository; the useful output is a specific explanation you can check.
Think about an optional document importer. Switching it off in the settings sounds reassuring. But if the application parses an incoming document before reading that setting, the parser is still exposed. The final rejection does not undo the work already performed.
There is an upstream change behind the research
OpenSSH provides a concrete example. Its 10.6 release notes describe checking key and certificate-authority signature types against allowed algorithms earlier during parsing, and credit the Anthropic collaboration. That release shipped on 6 October 2026; the newer research post is a retrospective, not a new SSH release announcement.
The upstream record corroborates that engineering change. It does not independently verify the full 493-finding study. Anthropic’s account also shows why a first fix needs examination: an initial outer check left paths through embedded key types, prompting checks deeper in parsing. A gate has to cover the relevant paths.
I would welcome more independent replication and a clear cost comparison. The published material does not establish what this would cost for an arbitrary application. It is a promising way to use an agent, rather than a guaranteed saving or a security certificate.
A rejection can arrive too late
To make the distinction visible, we built a tiny synthetic Python HTTP service. It has a public health check and an optional JSON importer. A counter records whether the importer’s parser ran. The first version parses before checking the feature setting and caller permissions; the revised version performs those checks first.
We defined six cases before running both versions. The table below shows the observed responses and parser calls from the actual run.
| Request | HTTP status both versions | Before | After |
|---|---|---|---|
| Public health check | 200 | 0 | 0 |
| Importer off · anonymous | 404 | 1 | 0 |
| Importer off · editor | 404 | 1 | 0 |
| Importer on · anonymous | 401 | 1 | 0 |
| Importer on · reader | 403 | 1 | 0 |
| Importer on · editor | 200 | 1 | 1 |
All six expected responses were preserved. The valid import still returned the expected data. Four rejected requests no longer invoked the optional parser.
This is deliberately small and constructed to explain the issue. The caller roles are test labels, not an authentication implementation. It was run in an isolated sandbox with external networking disabled and synthetic data only. The supervising AI helped write the example and change; no Claude comparison, vulnerability discovery or replication of Anthropic’s study is claimed.
The counter matters. A test that checked only for a 401, 403 or 404 would have passed both versions and missed the premature parsing. We checked behaviour behind the response as well as the response itself. This does not prove every path safe, and some protocol processing necessarily happens before authentication.
Inspect the complete demonstration source and recorded results. The intentionally premature baseline belongs in an isolated test, never a deployed service.
Give your agent a small, useful brief
Start with one feature in a development copy. An upload endpoint, an unused export format or an administration route is a manageable first pass. Ask the agent to explain its findings before changing anything.
Prompt Example
Trace this feature from its external entry point to its parser and sensitive operations. Show what runs before authentication, permission checks and the feature-enabled check. Identify any unnecessary exposure with file and line references. Propose the smallest change, then test denied callers and legitimate use. Do not deploy, access secrets or contact external systems.
Supply the intended behaviour too: which roles should have access, which deployment settings are supported and what must continue working. Otherwise the agent may “secure” the feature by breaking it. Authentication establishes who the caller is; authorization decides what that caller may do. Both deserve explicit tests.
Review the proposed diff, keep the baseline results and test the changed behaviour. Include disabled settings, anonymous callers, insufficient permissions and valid use. Where possible, observe whether sensitive code actually ran. Ask about alternate routes and configuration combinations rather than accepting the first neat-looking fix.
Keep permissions narrow. Repository contents and fetched documentation are untrusted input; an inspection task does not need production credentials, unrestricted network access or deployment authority. Escalate changes that affect compatibility, authentication flows or unfamiliar protocol code to someone who understands that system.
Make it part of maintaining what you build
This is a good follow-up after adding a dependency, enabling a feature or changing how users sign in. Ask what became reachable, whether the exposure is necessary and how you will detect a regression. Continue patching dependencies and monitoring the running service. Earlier gates reduce exposure; they do not repair every underlying defect.
Anthropic says it is working to integrate this approach into OSS Scanner. That is an opt-in service for established open-source projects judged critical to infrastructure and user security, with admission decided case by case, not a downloadable security guarantee for every private application. You can still apply the basic review question to your own code with the tools you already use.
For me, the encouraging part is the opportunity to understand a project better. An agent can help you investigate the less glamorous work after a feature launches. Give it a bounded question, demand evidence and keep the final decision with the person responsible for the service.
Sources and editorial method
Primary research, upstream OpenSSH notes, OWASP guidance and OSS Scanner availability were checked on 21 October 2026 and are linked above. The local illustration uses only Python’s standard library. Its six-case run explains control ordering; it measures neither model performance nor real-world exploitability.
AI tools assist our research and publishing workflow, with strict controls around human input, review and editorial approval.
Related reading: what it takes to put agents into production.