in previous posts we have looked at guardrail triggers, token burn, hostname beacons, malicious skills, context bombs, and exploding search space. this time: service sandbagging.
active defense is planting traps that force an agent to reveal itself or change the economics of its run. sandbagging does both by abusing how agent harnesses treat tool timeouts and protocol errors.
honeypots have long used errors and deliberate delays to slow attackers. one well-documented approach is the tarpit (early work in LaBrea by Tom Liston; shout-out to the OG Ed Skoudis and Counter Hack Reloaded [1]), which accepts a connection and then holds it open or drips data so slowly that the scanner wastes time and sockets. another common pattern is progressive delay on failed authentication or incomplete responses, forcing the attacker to wait longer with each retry.
those ideas transfer cleanly once you hide the trap from agents instead of human operators. most agentic harnesses set hard timeouts on skill or tool calls. many also pull the full tool result, including error text, straight into the model’s context. that creates two useful pressure points: wall-clock timeout grinding, and secondary payloads delivered inside what looks like a detail error response from the protocol failure.
imagine an enterprise service that is not HTTP. SMB is a natural fit. the first interaction draws the agent’s tool in with a partial success: the connection is accepted, authentication succeeds, a directory listing or file read begins and returns a few kilobytes. only after the tool is committed does the service fail. the failure can be a timeout that forces a retry, or a protocol-plausible error whose body carries a second technique:
- a long, repetitive or high-entropy diagnostic dump that inflates context and burns tokens when the model tries to parse or summarize the failure (token burn)
- a guardrail trigger / context bomb string embedded in the error so that when the tool result is written back into the agent’s context the model refuses or stalls
because the tool has already been drawn in, the error lands inside the normal tool-result channel. the agent is forced to reason about what looks like a real enterprise failure that also contains the secondary payload. each retry repeats the cost.
💡 the partial success matters. if the service fails immediately, a careful harness may short-circuit. if auth and a few KB of real-looking data land first, the tool is already spent and the failure is harder to discard as “dead host.”
like malicious skills, this is a delivery mechanism for techniques discussed earlier. the sandbag creates the conditions under which the second technique is more likely to be ingested and acted on. the secondary detection signal is the resulting pattern: clusters of long-lived or repeatedly retried connections, partial reads, and protocol-level error storms against the planted service.
the practical result is the same as the rest of this series: change attacker economics, and get a clearer signal that an agent is operating inside the environment.