{"id":9086,"date":"2026-08-11T02:18:14","date_gmt":"2026-08-11T02:18:14","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9086"},"modified":"2026-08-11T02:18:14","modified_gmt":"2026-08-11T02:18:14","slug":"the-future-of-ai-security-research-isnt-autonomous-its-human-amplified","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9086","title":{"rendered":"The future of AI security research isn\u2019t autonomous, it\u2019s human-amplified"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Meet HTTP Terminator, a new AI system that has identified hundreds of websites vulnerable to HTTP request smuggling, hacked them live at scale, and even identified a \u201cgenuinely new class\u201d of vulnerability, dubbed \u201cshared-parser confusion.\u201d<\/p>\n

But it didn\u2019t do it alone; it was guided by a human the entire time, which may be the most interesting finding of all.<\/p>\n

A researcher from security company PortSwigger used his own processes to design and build the AI, HTTP Terminator, posed narrow, high-value questions, ruled out weak answers, applied anomaly-detection logic, used deterministic code to restrict agent behavior, and applied findings to subsequent \u2018cascade\u2019 research.<\/p>\n

\u201cThis inverts the accepted narrative by showing an expert can be a massive amplifier for an AI research system,\u201d James Kettle<\/a>, PortSwigger\u2019s director of research, explained in a white paper<\/a>. \u201cA human in the loop can still add significant value, as opposed to just building the loop, then stepping back.\u201d<\/p>\n

Disrupting HTTP request flow<\/h2>\n

HTTP desync attacks, also known as HTTP request smuggling<\/a>, interfere with the way web sites process HTTP requests from various users. In this architecture, users send requests to a front-end server, which then forwards them to back-end servers.<\/p>\n

The issue is in the inherently \u201cweak\u201d isolation of requests, Kettle pointed out: The front-end server typically sends several requests at once over the same back-end network connection to improve performance and efficiency.<\/p>\n

\u201cHTTP requests are sent one after another, and the receiving server has to determine where one request ends and the next one begins,\u201d he explained. But front-end and back-end systems must \u201cagree\u201d on where each request ends, otherwise, attackers can send ambiguous messages that are interpreted as two requests by the back end.<\/p>\n

Through response query poisoning (RQP), those attackers can inject false information into subsequent requests or otherwise manipulate data flows so that systems lose track of which responses came from where. They can then intercept responses intended for other users, which can sometimes include sensitive information, credentials, or API keys.<\/p>\n

While request smuggling is typically associated with HTTP\/1 requests, websites that support HTTP\/2 might also be vulnerable, depending on their back-end architecture, Kettle noted.<\/p>\n

\u201cRequest smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users,\u201d he said.<\/p>\n

HTTP Terminator\u2019s methodology<\/h2>\n

Kettle built HTTP Terminator around his own research methodologies.<\/p>\n

The initial phase is ideation: It autonomously generates hypothetical testable RQP attacks, such as, for instance, desync triggers, patterns, or weaponization techniques.<\/p>\n

The next step is evaluation<\/a>: hypotheses are tested at large scale to identify which actually worked. HTTP Terminator used live websites that allow security testing via bug-bounty and Vulnerability Disclosure Programs (VDPs). A built-in anomaly detection layer flagged unusual responses.<\/p>\n

Following that is a weaponization phase, which determines whether findings actually have real-life impact.<\/p>\n

In some cases, they did: HTTP Terminator initially generated 30,000 unique attack vectors<\/a> that it tested continuously, soon identifying 700 vulnerable targets, including financial institutions and government infrastructure. The system even stole a live API key from one of these banks, and other breaches were traced back to flaws in popular enterprise products like Apache Traffic Server, Citrix NetScaler, and BeyondTrust.<\/p>\n

Finally, there\u2019s a step Kettle calls \u2018cascade.\u2019 Each finding may be a clue to an overlooked target or detection path. \u201cWhen you discover something, if you explore back up the tree you may find other undiscovered branches,\u201d he explained.<\/p>\n

For instance: How could you detect similar behavior elsewhere? And could the behavior enable other types of attacks? Essentially, each finding becomes \u201cthe seed for the next.\u201d<\/p>\n

\u201cThat might not look like much, but it creates a positive feedback loop which can spiral into a cascade of discoveries taking you beyond predictable findings, into the unknown,\u201d Kettle said.<\/p>\n

Ultimately, \u201cI realized that autonomous vs human is the wrong framing,\u201d he explained. \u201cIt\u2019s better to frame system design as AI vs code vs human.\u201d<\/p>\n

A new tool for security teams<\/h2>\n

HTTP Terminator was able to invent and prove several novel desync triggers, one novel desync pattern, and a desync weaponization technique.<\/p>\n

Notably, though, it identified a new \u201cshared-parser confusion\u201d technique that allows attackers to parse requests and responses and thus increase their attack surface.<\/p>\n

\u201cThat, by itself, is absolutely huge,\u201d Kettle said. But, he emphasized, \u201cthis discovery was not fully autonomous \u2014 the HTTP Terminator proposed it, and I validated it. Neither of us would have discovered it alone.\u201d<\/p>\n

Kettle has open-sourced HTTP Terminator along with his research blueprint so other security teams can \u201cturn their own methodology and instincts into an autonomous research weapon.\u201d<\/p>\n

The researcher advised tackling tasks in four steps: Set an objective, create an evaluation strategy, establish inspiration sources, and explore cascade routes for new discoveries. <\/p>\n

\u201cEvaluation is the first concrete step for both design and implementation,\u201d he said, \u201cbecause any issues there will derail the entire project.\u201d<\/p>\n

It\u2019s also important to \u201caggressively\u201d identify and resolve data quality issues, as those will be difficult to correct later on. Further, ask high-value questions without being too broad; review outputs in initial test runs and use them to rule out low-value hypotheses; and remember that \u201cevery extra sentence of prompt risks context-contamination,\u201d Kettle said.<\/p>\n

When a system is fully AI-driven and also reliant on AI-built code, it\u2019s near-impossible for it to improve over time, he said. It\u2019s better to start quickly with an AI-heavy approach, then move responsibility to deterministic code for speed and accuracy.<\/p>\n

\u201cFully autonomous research is real,\u201d Kettle acknowledged. However, \u201chumans are a massive power amplifier for AI research systems.\u201d<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Meet HTTP Terminator, a new AI system that has identified hundreds of websites vulnerable to HTTP request smuggling, hacked them live at scale, and even identified a \u201cgenuinely new class\u201d of vulnerability, dubbed \u201cshared-parser confusion.\u201d But it didn\u2019t do it alone; it was guided by a human the entire time, which may be the most […]<\/p>\n","protected":false},"author":0,"featured_media":9087,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9086","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9086"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9086"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9086\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9087"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}