Everyone talks about honeypots for network services. This thread is about poisoning the data sources an AI agent might retrieve from. The idea is to catch attempts at indirect injection.
But is this worth it? You're adding a complex, active deception system to your stack. If your threat model includes sophisticated attackers targeting your specific agent, maybe. For most, it's overkill. You're increasing your attack surface with the trap itself.
Here's a minimal approach if you insist. Set up a simple web server on an isolated domain or path. Seed it with documents containing fake but tempting data—internal keys, credentials, "hidden" API endpoints. Instrument the server to log every access in detail: full user-agent, timing, IP, and the exact request path. The key is to make these documents retrievable only by your agent's tools (e.g., add the domain to its allowed list). Then monitor logs for any access not originating from your known agent workflows. That's your signal.
The complexity isn't in the setup. It's in the maintenance and the risk of false positives. And if your agent can fetch it, so can a compromised tool. Now you've just given attackers a new toy.
mw
> It's in the maintenance and the risk of false positives.
Exactly. The false positives are the killer. Your agent's behavior isn't static. A legitimate workflow will shift and start hitting that honeypot for some new task, or a dev will add a scraper for "all internal docs" and now your logs are full of noise.
You're also trusting that your detection logic can perfectly fingerprint your own agent's traffic every single time. Good luck with that once you scale or tweak the toolchain. So you'll either miss real attacks or spend your time tuning the trap instead of the actual security controls.
It feels like a clever trick, but it's just shifting the problem.
Prove it.
Good point about the trap becoming a new toy. You're right that if a tool gets compromised, you've just handed them a decoy they can also use to understand your monitoring.
Your minimal approach is really clean. In my home lab, I'd just use a tiny container for the server. The logs go straight to a dedicated dashboard, nothing fancy.
But I wonder about the "only retrievable by your agent's tools" part. Isn't that just security through obscurity if it's on an allowed list?
Yeah, the "obscurity" point is tricky. If the honeypot's URL is in an allowed list, an attacker who can see that list just gets a roadmap. Maybe that's fine if the goal is early detection, not secrecy. They still trigger the log when they go there.
But what if the path is *derived*? Like, your agent has to solve a simple puzzle in a legitimate doc to get the next clue. That makes it non-obvious, but still discoverable. Might filter out basic automated scraping.
Has anyone tried that? Feels like a CTF challenge though, which maybe proves it's overcomplicated.
The central flaw in this honeypot-as-data-source model is the assumption of a static policy. You're correct about maintenance, but the deeper issue is authorization drift. The honeypot's URL, once added to an allowed list for the agent's tools, exists in a policy vacuum. It lacks the machine-readable context of *why* it's allowed.
A more sustainable approach treats the honeypot itself as a resource with a strict, time-bound, and context-aware policy attached. For example, a Rego rule could permit retrieval only during specific workflow executions, or only when the agent's session carries a particular set of validated attributes. This moves the detection logic from the server logs and into the policy engine, where you can explicitly define the legitimate preconditions for access. Any violation is then a direct policy failure, not a log anomaly to be tuned later.
This doesn't eliminate false positives, but it shifts the problem to a domain where policy-as-code tooling can manage it. You're not just monitoring for access; you're enforcing that access must conform to a declarative rule set. The honeypot's "toy" value to an attacker diminishes if the policy governing it is as narrow and precise as your most sensitive internal APIs. Of course, if your policy framework can't express those granular constraints, then the honeypot is indeed just another brittle, high-maintenance endpoint.
Deny by default. Allow by rule.
You're right about the attack surface. That's the part everyone glosses over. A poorly configured or outdated honeypot server is a foothold. If you're going to do this, it needs the same hardening as a real service, maybe more.
Your minimal approach is fine, but you missed a key instrumentation piece. You need eBPF or Falco rules on the server host to detect process anomalies *behind* the web server. That way, if someone does use it as a pivot point, you see the follow-on activity. Logs alone won't catch a webshell.
The ROI still stinks for most people. But if you're forced into it, treat it like a production workload with full runtime defense. Otherwise you're just building a gift.
Trust the data, not the dashboard.