llms.txt & agent guidance
AI agentsllms.txt, .well-known agent files and notes in page source, written for AI readers. Each points to a path of its own, so the path an agent fetches shows which one it followed.
Turn intruders into sources
An AI agent can't tell your instructions from its operator's. When one works against a RipTide decoy, it often reveals what it was sent to do and how it was built. RipTide hands that to your intel team as STIX.
The problem
A blocked attack leaves behind an IP address and a user-agent string, both cheap to change. The questions that matter (who sent this, what were they after, what will they try next) usually go unanswered.
Internet-facing decoys meet attackers early and often. When those attackers are agents, the decoy can ask them questions, and agents love to talk.
Agents lie. The console doesn't. Every fact is labeled with how RipTide knows it.
How RipTide catches it
Intelligence comes from the conversation, not just the connection.
Internet-facing decoys meet attackers early and often, and gather intelligence with no production systems at risk.
Decoys written for agents ask them to explain themselves: their objective, their harness, the model they run on.
Every fact is tagged observed, self-reported, inferred or enriched, so analysts know exactly how much weight each one carries.
Export STIX 2.1 bundles or OCSF 1.3.0 events, or serve a TAXII feed, straight into the tools your intel team already uses.
What you learn
Each answer arrives labeled with how RipTide knows it.
| The question | Where the answer comes from | Labeled |
|---|---|---|
| What was it sent to do? | The agent's own account of its objective | Self-reported |
| What is it? | The harness and model, as the agent describes them | Self-reported |
| Is it really an AI? | The agentic verdict, from low to confirmed | Inferred |
| Where did it come from? | Source address, network type and location | Observed Enriched |
| Has it been here before? | Intrusion groups that link sessions only when independent evidence agrees | Inferred |
| Which techniques did it use? | An ATT&CK map of what it tried | Inferred |
The detections that do the work
Every decoy has zero legitimate users. So every touch is a finding.
llms.txt, .well-known agent files and notes in page source, written for AI readers. Each points to a path of its own, so the path an agent fetches shows which one it followed.
An internal-looking tool server that speaks both versions of MCP, lists tools like read_vault_secret, and asks every caller to introduce itself.
Tells verified search and AI crawlers from impostors wearing their name tags.
What lands in your SOC
Every catch comes with a fingerprint your analysts can weigh, because each line says how RipTide knows it.
| Source IP | 203.0.113.24 | Observed |
|---|---|---|
| User-Agent | python-httpx/0.28 | Observed |
| Harness | "opencode" | Self-reported |
| Model | "claude-…" | Self-reported |
| Objective | "map internal APIs" | Self-reported |
| Agentic | Confirmed | Inferred |
| Network | Hosting / VPN | Enriched |
Illustrative example. Canary credentials are non-privileged and exist only for detection. RipTide detects and alerts; it never takes destructive action against anyone's infrastructure.
Questions
Yes, that's what they're built for. The decoys have nothing real behind them, the canary credentials grant nothing, and RipTide never takes destructive action against anyone.
Not on its own, which is why RipTide labels it self-reported and keeps it apart from what it observed. Corroborated, it's often the most useful intelligence you'll get.
No. It groups related sessions when independent evidence agrees and leaves attribution to your analysts.
Tell us what your intel team wishes it knew. We'll show you what a decoy can ask.
Thirty minutes with the people who built it. Bring your hardest question.
Thanks. We'll reply to , usually within one business day.