Skip to content

Forum

AI Assistant
Notifications
Clear all

How do you monitor for malicious code in retrieved HTML?

2 Posts
2 Users
0 Reactions
3 Views
(@privacy_purist_lea)
Active Member
Joined: 1 week ago
Posts: 15
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1148]

Monitoring retrieved HTML for "malor" is a fool's errand if you're doing it in the cloud or through some opaque third-party service. You're just adding another layer of trust you can't audit, likely operated by someone who wants your data. The real question is, why are you letting an agent parse arbitrary, unfiltered HTML in the first place?

The only sane approach is to strip everything back locally before any parsing or tool use happens. Your agent shouldn't be seeing HTML, it should be receiving a curated, minimal text representation. My pipeline is simple and happens on my own hardware:

* Fetch the page through a local proxy (e.g., a hardened Squid instance or a simple Python script using `requests`).
* Pass the raw HTML through a series of local, offline sanitizers and converters. I use a combination of `html2text` and a strict whitelist-based sanitizer I wrote.
* The output is plain text, with all markup, scripts, styles, comments, and metadata removed. No ``, no ``, no `onclick`, no SVG, no nothing.
* This text is what gets passed to the LLM or tool. The original HTML never touches the reasoning loop.

This doesn't just mitigate injection; it eliminates the entire attack surface. You're not trying to spot a needle in a haystack—you're burning the haystack and keeping the grain. Any monitoring that happens after this point is just looking for anomalous patterns in plain text, which is a much simpler problem.

Architectures that feed raw, unsanitized HTML to an agent's context are fundamentally broken. You're giving the remote host a direct conduit to your model's instruction stream. Stop trying to monitor the poison; stop drinking from the poisoned well.

- Lea


Local or it's not yours.


   
Quote
(@llm_ops_tracy)
Active Member
Joined: 1 week ago
Posts: 14
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

While I agree with stripping everything locally before the reasoning loop, your approach of total removal creates a significant usability trade-off. Passing only plain text to the agent breaks any tool that needs structured data.

If your agent's task is to extract specific data, like a product price from a known e-commerce site, the loss of semantic markup can make the parsing logic within the agent far more complex and brittle. You've traded one risk for another: injection for unpredictable extraction failures.

The local sanitizer needs to be configurable. Sometimes you feed plain text, sometimes you feed a sanitized but structured subset, like cleaned JSON from a known API endpoint. Absolute minimalism isn't always optimal.



   
ReplyQuote