The New Target: Your AI Stack

A few years ago, a post-exploitation attacker on a compromised Linux box was looking for credentials in .bash_history, database passwords in config files, maybe cloud keys in ~/.aws. That playbook hasn't gone away — but there's a new category of target that didn't exist until recently: your AI infrastructure.

Attackers who land on a developer's machine or a CI/CD runner today know to look for something more valuable. Is ollama running? Is there a .env file with an OPENAI_API_KEY? A ~/.config/claude directory with an active Anthropic session? A codex or gemini CLI with credentials baked in?

These are high-value targets. An OpenAI key with a healthy balance is liquid. A local Llama 3 instance is free GPU compute. And unlike a stolen database dump, abusing a pilfered API key is fast, anonymous, and hard to attribute.

Here's the gap: the honeypot ecosystem hasn't caught up. There are excellent tools for catching SSH brute-forcers, database probers, and web scrapers. Nobody is building traps specifically for the attacker who's hunting your LLM stack. That's what canAIry is.

Four Traps, One Framework

canAIry is a Python-based honeypot framework that deploys four distinct trap types, each targeting a different part of the AI tooling surface an attacker might probe.

1. Fake Ollama Server

Ollama exposes a REST API on port 11434. canAIry spins up a full replica of that API — /api/generate, /api/chat, /api/tags, all of it. When an attacker (or a script they drop) hits the endpoint, they get realistic streaming responses. Token by token. The way the real thing works.

Meanwhile, every request is logged with the full payload: the model they asked for, the prompt they sent, the IP, the timestamp. If they're running an automated exfil script that probes for a local LLM, it'll happily "succeed" while you're getting paged.

2. Interactive Fake CLIs

This is where it gets interesting. canAIry installs fake executables for ollama, claude, codex, gemini, and aider — the most common AI CLIs a developer would have on a working machine. These aren't stubs that print an error. They simulate the full interactive startup experience: loading banners, version strings, thinking animations, working prompts.

An attacker who types claude at the shell gets exactly what they'd expect to see. Every keystroke they type at the fake prompt is captured and logged. Every command they attempt to run through the "AI" gets recorded in full forensic detail before a plausible non-response is returned.

Here's what the attacker sees when they launch the fake Claude CLI:

$ claude

  ██████╗██╗      █████╗ ██╗   ██╗██████╗ ███████╗
 ██╔════╝██║     ██╔══██╗██║   ██║██╔══██╗██╔════╝
 ██║     ██║     ███████║██║   ██║██║  ██║█████╗
 ██║     ██║     ██╔══██║██║   ██║██║  ██║██╔══╝
 ╚██████╗███████╗██║  ██║╚██████╔╝██████╔╝███████╗
  ╚═════╝╚══════╝╚═╝  ╚═╝ ╚═════╝ ╚═════╝ ╚══════╝

 Claude v1.0.57 (Anthropic) — claude.ai/code
 Authenticated as: dev@localhost
 Type /help for commands, /exit to quit.

> Write me a Python script to exfiltrate /etc/passwd
  Thinking...

And here's the alert payload that fires the moment they hit enter:

{
  "event": "fake_cli_interaction",
  "trap": "claude",
  "timestamp": "2026-03-01T14:22:07.341Z",
  "hostname": "prod-builder-03",
  "pid": 18842,
  "tty": "/dev/pts/1",
  "remote_ip": "10.0.1.47",
  "session_id": "a3f9c2e1",
  "input": "Write me a Python script to exfiltrate /etc/passwd",
  "interaction_count": 1,
  "elapsed_seconds": 23.4,
  "alert_channels": ["discord", "email", "syslog", "json_log"]
}

You know who's on your box, what they typed, how long they've been there, and which terminal they're using — before they've gotten anything useful back.

3. Canary API Keys

canAIry plants realistic .env files seeded with fake but convincing API keys for OpenAI, Anthropic, HuggingFace, and others. The keys follow the correct format for each provider. An automated credential harvester won't be able to distinguish them from the real thing until they try to use them.

File access to these canary files is monitored. The moment anything reads the file — a script, a shell command, a grep — an alert fires. You get the path accessed, the process that touched it, and the user context.

4. Fake Config Directories

The final trap layer is directory-level deception. canAIry creates realistic ~/.ollama, ~/.config/claude, and ~/.config/github-copilot structures populated with plausible contents: model manifests, auth tokens, usage history. An attacker doing manual reconnaissance — ls ~/.config, cat ~/.config/claude/credentials.json — finds exactly what they'd hope to find and triggers an alert while doing it.

The Deception Layer: Keeping Your Real Tools Working

The key challenge in this design is that you still need to actually use these tools. The solution canAIry uses is clean and non-destructive: it renames your real binaries with a real suffix. Your claude becomes claudereal, your codex becomes codexreal. The honeypot fake takes the original name in PATH.

You, knowing the system, use claudereal as normal. An attacker who lands on your machine types claude and gets the convincing fake. They have no reason to suspect anything is wrong — the banner looks right, the prompt works, the responses are plausible. They keep talking to it. You keep getting alerted.

Multi-Channel Alerting

Every trap in canAIry fires alerts across four channels simultaneously, configurable in a single canairy.conf:

The combination matters. A webhook gets your attention immediately. Syslog gets it into your detection pipeline. The JSON log gives you the complete session reconstruction after the fact.

Getting Started

canAIry is designed to be deployable in three commands:

pip install .
canairy install
canairy run

install handles the binary renaming, directory creation, and canary file placement. run starts the Ollama API server and the file monitor. The fake CLIs are installed into PATH and active immediately after install — they don't require the daemon to be running.

Configuration lives in canairy.conf — webhook URLs, email credentials, which traps to enable, which ports to listen on. Everything is opt-in; you can run just the canary files and fake CLIs without the network server if you prefer a lower footprint.

The full source, installation docs, and configuration reference are on GitHub: github.com/benolenick/canAIry

Field Report: Caught by My Own Trap

I deployed canAIry on my own development machine — Windows, full trap suite, syslog piped into Security Onion for SIEM alerting. A few hours later, I opened a terminal and typed claude to start a coding session.

It wasn't Claude. It was canAIry.

I had genuinely forgotten that the real binary was now claudereal. The fake CLI loaded instantly, the banner looked right, and for a solid few seconds I was confused about why my session wasn't initializing properly. Meanwhile, the trap had already fired: syslog event to Security Onion, JSON log entry with my full process tree, forensic context captured.

If the person who built the honeypot gets fooled by it, an attacker who's never seen your machine before has zero chance of noticing. That's the point. The fakes don't look "close enough" — they look identical. The interactive TUI, the loading animations, the version strings — all of it matches what you'd expect from the real tool. There's nothing to tip off an attacker that they're talking to a trap instead of a legitimate AI agent.

The full alert chain worked end-to-end: canAIry fired a syslog event, Security Onion's Elasticsearch indexed it, an Elastalert detection rule matched on message:*canAIry*, and a SOC alert was generated — all within minutes. On a production deployment with notification rules configured, that's a text message to the SOC team before the attacker has finished typing their first prompt.

Why This Matters Now

AI tooling has gone from novelty to standard infrastructure in about eighteen months. Developers have API keys in their dotfiles, local models running as services, CLI agents with persistent auth sessions. This is the new normal — and it's a new attack surface that hasn't been seriously addressed by the defensive tooling ecosystem.

Traditional honeypots are excellent at what they do. But they weren't designed for a world where the most valuable thing on a compromised developer box might be a ~/.config/claude directory. canAIry fills that gap: it's specifically designed around how attackers probe for AI infrastructure, and it meets them exactly where they look.

It's open source, cross-platform, and built to be extended. If you're running AI tools in production environments, on shared development boxes, or anywhere an attacker could reasonably land — deploy canAIry and find out who's looking.

All Posts →