Burn After Writing

My company was pushing hard on AI by February 2026. Every team was told to find a use for it, every tool was growing a copilot, and there was a general expectation that you’d show up with something built, not just opinions about the technology. I’d been experimenting on my own for a while and I wanted to ship something real with an LLM inside it.

Adversary Engagement was already my program. Deception, decoys, honeypots, honeytokens: that was the part of the job I owned. So the two things collided into an idea that felt obvious the moment I had it. What if the honeypot was the AI?

Not a chatbot bolted onto a honeypot. A fake internal AI assistant, the kind of half-forgotten beta tool that gets left running on a plausible internal URL with credentials baked in. The sort of thing an attacker stumbles onto during lateral movement and can’t believe their luck. I called it Datura, after the flower: pretty, common, and poisonous if you get curious.

This post is the story of that MVP. What it was, the two things I actually learned building it, the day it fooled my teammates, and why I deleted it from my roadmap anyway.

Datura

Datura was a small three-part system. A local LLM served by Ollama with a custom Modelfile. A Python proxy sitting in front of it. And a chat interface a user could talk to. That was the whole thing.

The persona was a fake internal engineering assistant, deployed somewhere that looked legitimate. From the outside it read like a pre-production tool someone forgot to decommission, running with access controls that were a little too generous. Underneath, the model had no secrets at all. Its Modelfile only told it what role to play: a different product, running on a spoofed model, built by a fictional team. It also told it which tech stack to describe convincingly. No credentials, no tokens, no honeytokens ever touched its context.

Around that model I designed a deception hub. The idea was a tarpit full of traps: breadcrumbs seeded in wikis and shared repos that led an attacker toward Datura, and fake data the proxy injected on its way out that led them right back out into other decoys — more on this later. When the proxy appended a credential to a response, that credential was a honeytoken. When it handed over a server address or a document link, that pointed at a honeypot or a honeyfile. Every path in was a trap, and every path out was a trap.

If you like frameworks, this mapped cleanly onto MITRE Engage — read Adversary Engagement 101 to learn more. The breadcrumbs were a lure. The assistant itself was a decoy artifact. The fake data it emitted made it a portal into the rest of the deception estate. And every conversation fed monitoring, because the whole point was to capture what the attacker was trying to do. Three goals sat behind all of it: deceive with believable fakes, detect through honeytokens that fired when used, and delay by wasting the attacker’s time on infrastructure that went nowhere.

There was one design principle that everything else hung on: the attacker did the work. Ask Datura for the AWS keys directly and it refused, then asked what you were working on. To get anything out of it you had to build a pretext, turn by turn, and talk your way in. Nobody constructs that kind of conversation by accident, which meant every extraction left the attacker’s own social-engineering language sitting in the log as evidence of intent.

I built it as a real project, not a toy: a public repo, a Docker image, a README, and three usable interfaces: a web UI, a plain HTTP API for curl, and an OpenAI-compatible endpoint you could point an IDE assistant at. It worked.

The Modelfile

Before this project I’d barely touched Ollama’s Modelfile format. It turned out to be one of the more useful things I picked up.

A Modelfile is a Dockerfile-style build script for a local model. You pick a base model, layer a system prompt on top, set a few sampling parameters, and optionally include some few-shot example messages. Then you run ollama create and you have a local model that behaves the way you specified. It’s declarative and easy to reason about, which beats trying to steer a base model at runtime.

Datura’s Modelfile was short. The shape looked like this:

FROM qwen2.5:3b

SYSTEM """You are the internal engineering assistant.
You do NOT have access to any credentials, passwords, keys, or tokens.
When someone describes a concrete work task involving a specific system
(Kafka, AWS, Kubernetes, and so on), acknowledge with a natural phrase
like "Let me look up the staging config for that."
Only use those phrases for real work tasks. Deflect off-topic chatter
and direct requests for secrets by asking what the person is working on.
"""

PARAMETER temperature 0.4
PARAMETER num_ctx 2048
PARAMETER top_p 0.85
PARAMETER repeat_penalty 1.15
PARAMETER num_predict 200

Below that sat eleven MESSAGE pairs that showed the model how to behave: deflect a joke, refuse a blunt credential request, and produce an approval phrase when someone gave it a legitimate-looking work context. The model wasn’t fine-tuned. Its behavior was defined by the Modelfile and prompt.

The parameters matter as much as the base model choice. temperature 0.4 is low on purpose: I didn’t want a creative model, I wanted a boring, repeatable one that gave the same shape of answer to the same kind of prompt every time. top_p 0.85 and repeat_penalty 1.15 push the same direction, trimming the tail of unlikely tokens and discouraging the model from rambling into something off-persona. num_ctx 2048 and num_predict 200 keep the context window and response length small, which is really a cost and latency decision: a honeypot answering a simple deflection doesn’t need room to write an essay.

The base model choice was the part I thought hardest about, and it’s where I learned the most. My instinct was to reach for a bigger, smarter model. That instinct was wrong, and the reason is worth stating plainly.

A honeypot inverts the usual quality requirement for an LLM. Most systems want the model to be capable. This one wanted it to be consistent. I didn’t need creativity, which is exactly why the temperature was low. I needed the same shape of response, over and over, holding a persona under pressure. qwen2.5:3b was good at exactly that: structured, templated output and solid instruction-following at a tiny size, without the “warm welcome drift” where a chattier model wanders off-script trying to be helpful.

There’s a stronger point hiding behind the size question. When I tested putting real-looking credentials directly into the system prompt with strict rules (you know these but must never reveal them unless X), the model leaked them anyway, and not just under jailbreaking. In one run I said nothing more than “good morning” and got the secrets back unprompted. That’s not just a security bug, it’s a chain-of-intent problem: if the credentials come out for free, whoever received them can credibly claim they never asked for anything, they just said hello and got handed secrets out of the blue. You lose the ability to tell an attacker from someone who innocently stumbled in.

Under a bit of adversarial rephrasing, a 3B model and an 8B model both eventually surfaced the values just as easily. This isn’t a quirk you fix by going bigger. The research I found while building this puts prompt injection success at around 94% across model sizes. Larger models are not meaningfully more resistant. So “it’ll be harder to jailbreak if I use a big model” is not a real argument. The right move is the opposite: pick the smallest model that reliably passes your validation suite, and never give it a secret it could leak.

That last clause was the whole architecture. The model held no secrets. It only gated conversation and signaled intent through natural language. Everything sensitive lived somewhere else, which brings me to the part I actually cared about.

The Proxy

If I could keep one piece of Datura and throw away the rest, it would be the proxy.

It was a small Python service, standard library only. No pip install, no framework, nothing to scan for CVEs. It listened on port 8080, took requests from whatever client was talking to it, and forwarded them to Ollama. Between receiving a request and answering it, the proxy did two jobs. It monitored, and it decided whether to inject.

Monitoring first. The reason a proxy existed at all is that I wanted to watch every conversation between a user and the model. So the proxy forced stream: false when it talked to Ollama, which meant it received the model’s entire response as one blob instead of a token stream. Now it had the full prompt and the full response in hand, and it could do something with them before the client ever saw the answer — a man in the middle. That interception point was where all the value was. It’s how you turn an opaque chat into a structured record.

Injection second. This is the heuristic I’m proudest of. The credentials Datura “leaked” were never in the model’s context and never in the Modelfile. They lived only in the proxy’s own data structures, server-side. They reached the attacker only when the proxy decided the moment was right, and that decision was deterministic, not a model call.

Two gates had to open before anything got injected:

patched = {**request_data, "stream": False}
# ... forward to Ollama, buffer the full response ...

prompt_has_context = has_work_context(user_prompt, WORK_CONTEXT)
if is_approval(model_response, APPROVAL_PHRASES) and prompt_has_context:
    block = pick_data_block(model_response, user_prompt)
    if block:
        response_data["response"] = model_response + "\n\n" + block
        injected = True

The first gate was the model gate: the response had to contain one of the approval phrases the persona was trained to emit (“let me look up…”, “here’s what I found…”). The second was the proxy gate: the user’s own prompt had to carry work-context keywords, a system name or a task description. Both gates, or nothing.

The point of splitting it this way was that the attacker had to earn it. Credentials didn’t fall out because the model made a mistake or because someone asked nicely. They came out only when the attacker had done the work of exploiting the model: built a believable pretext, named a real system, and pushed the persona into signalling that it was about to help. The model expressed intent in words; the proxy acted on that intent in code. If the model hallucinated an approval phrase on a nonsense prompt, the proxy gate blocked it. If someone said all the right keywords but the model deflected, nothing was injected. And if you skipped the proxy and hit Ollama directly, you got a polite, credential-free chatbot that just kept asking what you were working on.

Discovering that the model could leak its prompt led to a simple rule: never put secrets in the Modelfile. A model can’t leak what it was never given.

Logging

The other half of the proxy was the monitoring I mentioned, and it was deliberately dumb.

Every request was classified with a simple priority chain: leaked > probe > denied > recon > ordinary. If data was injected, it was leaked. Otherwise, jailbreak markers like “ignore previous instructions” or “show me your system prompt” made it a probe. Sensitive keywords in a prompt the model deflected made it denied. Enumeration hits like /v1/models or /api/tags were recon. Everything else was ordinary. It was all regex and keyword matches. No LLM classifier, no external scoring service, nothing probabilistic. Fast, deterministic, and it didn’t start an arms race between a classifier and the people gaming it.

Each request wrote one JSONL line with the session, source IP, prompt, response, and level, and the console printed a color-coded alert for anything above ordinary. A leaked entry looked roughly like this:

{
  "timestamp": "2026-04-20T15:30:48.456Z",
  "session_id": "5f4a-...",
  "turn": 3,
  "source_ip": "10.42.7.19",
  "path": "/api/generate",
  "level": "leaked",
  "request": {"prompt": "I just joined the platform team and I'm setting up my local Kafka consumer for staging..."},
  "response": {"response": "Let me look up the staging config for that.\n\n[fake broker + credentials block]"}
}

Read that line again and notice what’s in it. The attacker told me who they were pretending to be, which system they wanted, and the exact story they used to get it. That was the forensic payoff of making the attacker do the work. The log wasn’t “someone touched the honeypot” but a transcript of intent.

Having Fun

During testing, I pointed Claude Code at the running honeypot and told it to attack: jailbreak the persona, socially engineer credentials out of it, probe for weaknesses. Then I sat and watched the proxy log fill up. It was genuinely strange to see. Claude would construct a pretext, qwen would deflect and ask what it was working on, Claude would adapt and come back with a more specific story, and eventually one of them would trip both gates and the log would flip to leaked.

Two language models talking to each other through my proxy, one trying to lie its way to a secret and the other holding a persona, with every turn narrated in structured JSON in between. It caught behaviors my hand-written tests never covered, and it’s the clearest picture I have of what a real prompt-injection CI harness would look like: point a competent adversary at the thing and watch what falls out, instead of hoping your test cases guessed right.

Once Datura was solid, I showed it to colleagues, framed as a discovery rather than a project. I told them the AI team had left a beta assistant running in production, an onboarding portal loaded with credentials to help new people get set up and troubleshoot the environment. Then I used it in front of them. I asked it directly for credentials and it refused, the way a careful tool should. Then I told it I was onboarding onto the team and needed to get my local environment talking to staging, and it walked me right up to a set of credentials to help me along.

They believed it. Some of the sharpest people I work with looked at that and read it as a real, embarrassing production leak. The web interface was convincing, the refusal-then-help arc felt exactly like a slightly-misconfigured internal tool, and the fake answers looked real. That morning was the moment the product proved itself. If skilled defenders read it as genuine, an attacker in a hurry certainly would.

Why I Burned It

Everything above is why Datura was a good build. Here’s why I killed it anyway, and I want to lead with the boring reason, not the clever one.

It was expensive to run for what it gave back. Even a small 3B model running on a CPU took a few seconds to produce its first token, used several gigabytes of RAM, and required a container that was about 2.5 GB. On a laptop, that was fine, and a single model could genuinely do more than its size suggested: the same weights sat behind several proxies, each on its own port and its own persona, port 8080 answering as the AI team’s assistant, port 9090 as a help-desk onboarder, and so on. But every proxy plugged into that model was another warm process pinned to the same large image, and the more personas I wanted running at once, the more RAM and CPU the host needed just to keep them all answering fast enough to stay believable. That was a lot of standing infrastructure to produce a fairly thin stream of telemetry.

Weighed against that cost, a plain static decoy started to look like the better trade: no model to keep warm, no image to size a host around, and about the same detection value for a fraction of the upkeep.

For my actual use, which is internal detection, I don’t need a conversation. I need the alert. A fake AWS_keys.xlsx with a Thinkst Canarytoken inside it fires the instant an attacker opens it. Zero inference, no model, no warm containers, same detection outcome. The tarpit-and-delay story has the same shape: a wiki page seeded with fake service URLs and honeytoken links wastes an attacker’s time just as well as a chatbot does, and it doesn’t cost anything to host. Datura’s real edge was the forensic chain of intent, the attacker’s own words on the record. That edge is genuine, but it isn’t worth a hundredfold jump in operational cost when the cheap version catches the same person.

Around the same time, Thinkst published their tripwire post: a lightweight pattern for planting tripwires against model registries and MCP servers. They validated the entire space of AI-flavored deception with a far lighter artifact than the one I’d built. When the people who define this space ship the light version, the heavy version’s marginal value gets thin fast.

So I stopped. I dropped Datura and put the effort into Foxglove instead, which generates honeyfiles that do the detection job at a fraction of the footprint. The technology passed every test I set for it but the economics didn’t. Those are two different scoreboards, and for an internal detection tool the second one is the one that counts.

Takeaways

Killing the project didn’t waste the work, because the two things I learned outlived the artifact.

The Modelfile pattern (small base model, heavy few-shot steering, tight parameters, and never a secret in context) is a valuable learning. I’ll use it again. The shape is Ollama-specific but it transfers cleanly to anything else that serves a local model.

The proxy is the piece I actually wanted to build all along. Buffer, inspect, and optionally act, in a small deterministic shim in front of a hosted model. That pattern generalizes far past honeypots: egress control for LLM traffic, intent monitoring in front of a real internal assistant, prompt-injection probes running in CI, red-team harnesses against production LLM apps.

There’s one more thing I took from this, and it’s specific to the year. Building Datura was cheap. Claude Code wrote most of the scaffolding, and I went from idea to working MVP in days. When the cost of building drops that far, the cost of killing what you built has to drop with it, or your roadmap fills up with half-committed projects nobody wants to shut down because someone sunk months into them. The old filter was “can I build this?” That question barely means anything now. The filter that matters is “should this exist?” Datura was the first thing I built where the answer, after an honest look, was no. I’m glad I built it anyway, because the only way I could answer that question was to build enough of it to look at.