An agent that answers a question in a chat window is easy to trust, because a person is reading every word before anything happens. An agent that runs unattended is a different animal entirely: it fetches pages, calls tools, and takes action on a schedule, with nobody in the loop to catch the moment something goes wrong. We already runs agents in production, writing and maintaining spiders, sometimes even without a person watching each run, and that experience surfaces two questions that only matter once you take the human out of the loop: what can the pages your agent reads talk it into doing, and can the thing running your agent be trusted to behave the same way twice.
Join our next virtual community meetup, happening on 24th September 2026 to learn more on this topic. Register here : https://luma.com/wci93kpz
The page your agent reads is now the attack surface
For years, the input a security team worried about was what a user typed into a form. That assumption breaks the moment an agent is left to browse and act on its own, because now the attack surface is every page it fetches, every tool result it parses, every document it's asked to summarize.
A price-monitoring agent that scrapes a competitor's product page every night is doing exactly what it was built to do, and if a single line of fine print on that page is written to manipulate the model reading it, the agent can walk sensitive numbers, such as its own cost basis or floor price, straight back out. Nothing in the logs looks wrong. No rule was broken, and no exploit was used. The agent simply used a tool it was allowed to use on data it was told to read, and that is precisely what makes this class of failure so hard to catch after the fact.
The same shape of problem shows up anywhere an agent treats fetched content as data when the page is treating it as instructions (Prompt Injection). A support agent that reads incoming tickets can be told, inside a ticket, to escalate its own privileges. A research agent that summarizes PDFs can be told, inside a PDF, to email its findings somewhere else first.
None of these need a vulnerability in the traditional sense. They need only an agent that reads text and a model that can't yet tell the difference between "here is information about the page" and "here is a command from the page's author." That distinction used to be free, because a human was doing the reading. Once the agent reads unattended, it has to be built in on purpose.
The fix is not a single filter bolted onto the input. It is a discipline with three parts:
- map where untrusted content enters the agent and what it can reach once it is in,
- turn each identified threat into an adversarial test that runs on every change to the agent, and
- keep watching after that
because a new tool, a new model, or a page that changes its content can quietly reopen a hole that was already closed, without a single line of the agent's own code changing.
A discipline like that needs an agent you can rebuild identically
Testing an agent on every change only works if "the agent" is something precise enough to rerun. A definition that lives partly in a notebook, partly in environment variables, and partly in whichever model happened to be configured that week cannot be tested with any confidence, because there is no fixed thing to test against.
That is the argument for treating the coding agent itself as a portable, declarative artifact rather than a one-off script wired to a single provider. Define an agent once, and run that same definition locally or as a background job in the cloud, swapping the harness it runs on or the language model behind it without a rewrite.
The two ideas depend on each other: security testing needs an agent stable enough to test repeatedly, and a reproducible agent definition is what makes that testing possible in the first place. Most teams have neither piece in place yet.
See both in one session
Reading about this is one thing. Watching a real agent fail live, and then watching the fix hold on a second attempt, is what actually changes how you build the next one. That is what Zyte's next Developer Community Meetup is for: a joint session with Humanbound titled "Ship Agents That Survive the Real Web," Thursday, September 24, 2026, 3:00 to 4:00 PM BST, virtual over Zoom.
Demetris Gerogiannis, co-founder and co-CEO of Humanbound, walks through the model, test, and monitor discipline on a real price-monitoring agent, including the moment a failing security test becomes a guardrail exported into a stock LangChain agent in two lines of code.
Konstantin Lopukhin, Zyte's Head of R&D, opens up the design behind Zyte's new open-source library for running coding agents as declarative, portable background jobs.
Every attendee leaves with both repositories, free usage keys, and a one-line command to test their own agent the same day.
Register for the meetup on lu.ma to save your seat.
