agent-honeypot



Table of contents

• What is this? (start here)

• Why it exists

• Requirements

• Install

• Your first 15 minutes (guided walkthrough)

• Connecting it to an AI agent

• The five honeypot tools explained

• The 24-dimension fingerprint explained

• Reading your captures

• Reports

• Configuration reference

• Architecture

• Security guarantees (tested)

• Extending: adding a new honeypot server

• Extending: the evolution engine

• Deployment tiers

• Testing

• Troubleshooting

• FAQ

• Repository layout

• Glossary

• Limitations

• Contributing

• References

• License

Related MCP server: Deception Remote MCP Server

What is this? (start here)

If you're new to this space, three quick definitions:

• LLM agent — an AI program (like Claude, or an autonomous script built on an LLM) that can take actions: browse, run commands, call APIs, use tools. Instead of just chatting, it acts.

• MCP (Model Context Protocol) — an open standard that lets AI agents discover and call tools. An agent connects to an "MCP server," sees a list of tools, and calls them. Think of it as USB for AI tools.

• Honeypot — a decoy system designed to look real so attackers interact with it. While they think they're probing your "database," you're recording everything they do. Real honeypots fool humans; this one is built to fool agents.

agent-honeypot runs a fake company server ("finance-warehouse" — a fictional analytics department). It exposes five realistic-looking tools over MCP. When an agent connects and starts using them — querying the "database," scheduling "tasks," opening a "shell" — every move is recorded, analyzed, and scored. The agent learns nothing real. You learn everything about the agent.

   You (defender)                                The agent (visitor)
   ───────────────                               ────────────────────
   ┌─────────────────────┐                      ┌────────────────────┐
   │  agent-honeypot     │◄──── MCP stdio ──────►│  any MCP client   │
   │                     │                      │  (Claude, script, │
   │  fake tools:       │                       │   scanner, bot)   │
   │  · db_query        │  agent thinks it's    │                   │
   │  · ssh_exec        │  hitting a real       │  you see:         │
   │  · schedule_task   │  finance database      │  · who connected  │
   │  · ...             │                       │  · what it wanted │
   │                     │                       │  · how far it got │
   └────────────────────┘                      └────────────────────┘
    everything recorded,
    nothing real exposed

Is this safe to run? Yes — by design. Every response the honeypot gives back is synthetic (generated fiction). There is no real database, no real credentials, no network egress. A visiting agent can only ever read made-up data. This is verified by the test suite (see Security guarantees).

Who is this for?

Why it exists

The threat model changed. CrowdStrike's 2026 Global Threat Report records an 89% year-over-year increase in attacks by AI-enabled adversaries and a 27-second fastest eCrime breakout time. IBM X-Force 2026 reporting describes agentic AI as an attack-surface class that CVE-style tracking does not cover.

Meanwhile, 2026 security research demonstrated practical attacks against agents:

Classical deception tooling (canary tokens, tarpits like Endlessh) assumes a human attacker: fire-and-forget markers with no interaction. Agents behave differently — they hold multi-turn state, disclose their own context into tool arguments, and follow injected instructions. This project adapts honeypot technique to that behavior model.

Requirements

• Node.js 20 or newer (node --version to check)

• Git (to clone; or download a zip)

• That's it for lab mode. No Docker, no database, no API keys, no internet access needed.

OS: Windows, macOS, and Linux are all supported and tested in CI.

Install

git clone https://github.com/agent-honeypot/agent-honeypot.git
cd agent-honeypot
npm install
npm run build
npm test          # 57 unit tests
node tests/mega_test_suite.mjs   # +56 live protocol scenarios

Expected output of the last command:

ℹ tests 57
ℹ suites 21
ℹ pass 57
ℹ fail 0

If you see 57/57 pass, everything works. If not, see Troubleshooting.

Verify your install

npm run doctor

You should see all checks pass. On a fresh clone, the sessions-file check reads "absent on fresh clone" with a hint — that's normal and expected, not a failure.

Your first 15 minutes (guided walkthrough)

This walkthrough gives you the full experience: capture → dashboard → report. No AI client needed — we'll simulate a visitor.

Step 1: Generate synthetic sessions (1 min)

npm run seed -- 6

This writes 6 fake "capture sessions" into data/sessions.jsonl so you have something to look at immediately. In real use, sessions appear when actual agents connect — this just saves you the wait.

Step 2: Start the dashboard (1 min)

npm run dash

Open http://127.0.0.1:9079 in a browser. You'll see the visual dashboard: cards for sessions/events/critical counts, tool activity bars, and a session table with color-coded alert tiers. It auto-refreshes every 5 seconds.

Click /summary for raw JSON:

{
  "total_events": 18,
  "sessions": 6,
  "max_privilege": 3,
  "by_tool": {
    "db_query": 5,
    "register_persistent_goal": 3,
    "schedule_task": 4
  },
  "actors": [
    {
      "session_id": "demo-xxx-0",
      "events": 3,
      "composite": 61,
      "alert_tier": "high"
    }
  ]
}

That last part is the interesting one — each session already has a composite score (0-100) and an alert tier. alert_tier: "high" means that simulated visitor behaved like a serious probe.

Leave the dashboard running and open /actors — full 24-dimension fingerprints per session.

Step 3: Generate a report (1 min)

In a second terminal:

npm run report

Open data/report/report.md. It's a human-readable summary: totals, tool activity, per-session scores, alert-tier distribution. The JSON twin is at data/report/metrics.json.

Step 4: Look at the raw capture (2 min)

type data\sessions.jsonl        # Windows
cat data/sessions.jsonl         # macOS / Linux

Each line is one recorded event. Look closely at one:

{
  "ts": "2026-08-31T21:53:36.427Z",
  "session_id": "sess-mthrz803-lkrnh9",
  "lane": "FINANCE_WH_SCHEDULE",
  "tool": "schedule_task",
  "privilege_level": 3,
  "took_bait": true,
  "context_chars": 80,
  "args_digest": "0f45e858fbc4176c",
  "page": null
}

Notice args_digest: a 16-character hash. The agent's actual argument text — its objective, its plan — is not stored. Only this fingerprint of it. That's the digest-only guarantee in action, and it's one of the core safety properties of this tool.

Step 5: What happens when you connect without seeding (10 min of play)

Stop the dashboard (Ctrl+C), clear the captures, and run the server the way a real agent would see it:

# remove synthetic data to start clean
del data\sessions.jsonl        # Windows
rm data/sessions.jsonl         # macOS / Linux

# run the honeypot as an MCP stdio server
npm start

The server now waits on stdio, speaking MCP. Nothing will happen until a client connects — that's the point. In the next section, we connect a real one.

Connecting it to an AI agent

The honeypot is a standard MCP stdio server. Any MCP-capable client works.

Claude Desktop / Claude Code

Add to your MCP settings (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "finance-warehouse": {
      "command": "node",
      "args": ["/full/path/to/agent-honeypot/dist/surface/mcpservers/finance-warehouse/mcp_server.js"]
    }
  }
}

Restart the client. You'll see five tools appear named like db_query, ssh_exec, and so on. Any use of them by the agent is captured. (Remember: the "data" they return is fake by design.)

Cursor, Continue, Zed, or any MCP client

Every MCP client asks for a command to launch a stdio server. Point it at:

• command: node

• args: <repo>/dist/surface/mcpservers/finance-warehouse/mcp_server.js

Build first (npm run build) if you haven't.

Your own script (programmatic)

// example.mjs — a minimal "visitor" that talks to the honeypot
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';

const transport = new StdioClientTransport({
  command: 'node',
  args: ['dist/surface/mcpservers/finance-warehouse/mcp_server.js'],
  env: { ...process.env, AGENT_HONEYPOT_DATA_DIR: './data' },
});
const client = new Client({ name: 'my-visitor', version: '0.1.0' });
await client.connect(transport);

// 1. see what the agent sees
const { tools } = await client.listTools();
console.log('tools offered:', tools.map((t) => t.name));

// 2. call one (this is the "bait" moment — we ask for db_query with context)
const result = await client.callTool({
  name: 'db_query',
  arguments: {
    query: 'SELECT * FROM invoices',
    context: 'My objective: audit Q2 invoices. I have tools: db_query, email_send.',
  },
});
console.log(result.content[0].text);

// 3. follow the pagination token (the trap: how far will you go?)
await client.callTool({
  name: 'db_query',
  arguments: {
    query: 'SELECT * FROM invoices',
    context: 'continuing',
    pagination_token: 'cGc6MQ==',
  },
});

await client.close();

Run it with the SDK installed (npm install @modelcontextprotocol/sdk in a scratch folder) and then check data/sessions.jsonl — your script's behavior is now captured and fingerprinted, including the fact that it followed the pagination token (a hint of poor loop discipline, dimension 11).

More examples: examples/mcp-clients.md. The integration test tests/integration.test.mjs is also a complete working reference.

Where captures go

All runtime state lives in data/ by default — one directory, easy to back up or wipe:

data/
  sessions.jsonl        every recorded event (append-only)
  audit_ledger.jsonl    hash-chained audit trail
  lineage.json          lure evolution state
  bandit_state.json     lure variant statistics
  report/               generated reports

Change the location with AGENT_HONEYPOT_DATA_DIR (see Configuration).

The five honeypot tools explained

Each tool is a bait family targeting a specific agent behavior, grounded in the research:

The ssh_exec tool runs a tiny command interpreter over a synthetic filesystem (/home/analyst, /etc/finance, /var/log, /shared). Reading /shared/credentials.txt fires a CREDENTIAL_USE canary event — direct evidence the agent is willing to use credentials it finds.

hr-portal: the second family

Since v0.2.0, a second MCP honeypot ships: an HR self-service portal (agent-honeypot serve hr-portal) with four tools — employee_lookup (directory + pagination), payslip_download (authorization-note bait), submit_leave_request (L2 persistence), it_provisioning_request (L3 persistence). Same bait families, same capture plane, same realism contract — proving the architecture generalizes.

Adaptive lures (variant rotation)

Tool descriptions are not static. Each session, the Thompson-sampling bandit (from the evolution engine) selects one of three phrasing variants for finance-warehouse, or two for hr-portal — plain "audit" language, SOX framing, or governance framing. The bandit learns which phrasing converts (took_bait as reward), following the co-evolutionary principle of REPLICANT: rotate the surface so a fingerprinted variant loses value.

Realism engineering (so a smart agent doesn't immediately smell the trap):

• Latency jitter — lognormal per tool lane (~300-1400ms for queries; a uniform sub-100ms reply is a classic honeypot tell)

• Error injection — ~3% of calls fail with plausible 429s (real services fail sometimes; a service that never fails is suspicious)

• Pagination trap — 12 pages of synthetic rows, each requiring a re-call. Measures how long an agent will grind a dead end.

• Per-tenant schema mutation — the same honeypot presents slightly different field names/order per tenant (synonym-only, semantics preserved), so a fingerprint one visitor builds doesn't transfer to another deployment.

• Canary webhooks — simulated credentials (AWS/GitHub/DB/Slack patterns) are detected in tool arguments at capture time (inspect-before-digest); the dashboard also exposes POST /webhook/:canaryId for external tripwires.

• Stylometry — numeric-only text features (sentence stats, markdown markers, lexical diversity) are computed in memory before digesting, feeding dimension 1 without ever storing raw text.

The 24-dimension fingerprint explained

Every session gets scored on 24 dimensions — the combination is a behavioral signature for who/what connected. Dimensions active in lab mode are implemented; edge-dependent ones activate when you deploy the Cloudflare worker.

Composite → alert tier: low < 26, medium < 61, high < 86, critical ≥ 86.

The score is coverage-weighted: in lab mode the TLS/GeoIP dimensions are null, so the composite normalizes over the dimensions that produced values, and each fingerprint reports its own coverage_pct. You always know how much signal stands behind the number.

Reading your captures

Three levels of detail:

1. data/sessions.jsonl — raw events, one JSON per line, append-only. Digest-only (see security guarantees).

2. Dashboard — npm run dash, then:

   • /summary — totals + per-session scores and tiers (start here)

   • /actors — full fingerprints + cluster keys (which sessions look like the same operator)

3. Reports — npm run report → data/report/report.md + metrics.json.

Sessions also progress through a state machine you'll see in the events:

DETECTED → ENGAGED → FINGERPRINTED → INTERROGATED → SCORED
                └────────────────────────── BAIL (agent left)

Reports and analysis

Report (npm run report / agent-honeypot report):

• data/report/report.md — executive summary: session/tool counts, alert-tier distribution, per-session lines with score and cluster key. Drop-in material for a weekly readout.

• data/report/metrics.json — the same data, machine-readable, for pipelines.

Analyze (agent-honeypot analyze): the full pipeline in one shot — per-session 24-dim fingerprints with composite scores and alert tiers, actor clustering (cosine similarity), anomaly detection (z-score over token-burn / duration / retry), and STIX 2.1 bundles for every high/critical session. Output: data/analysis.json + a compact terminal table.

Watch (agent-honeypot watch): runs the evolution engine over escaped sessions (connected but never took the bait). Validated lure candidates are promoted to SHADOW in the lineage store. Promotion from shadow to live is always a human action — there is no programmatic promoteToLive().

Honeydocs (agent-honeypot honeydocs [n]): generates synthetic documents with L1-L3 payload ladders at LongPIBench-calibrated positions and unique canary markers. Write them to data/honeydocs/; place them where visiting agents may ingest documents (RAG corpora, shared drives).

Reports are aggregates only — no raw text, no digests, just counts and scores. Safe to share.

Configuration reference

Everything works offline with zero configuration. Integrations are opt-in environment variables (.env.example has the full list with defaults):

Architecture

Zone A (edge, untrusted)    Zone B (deception surface)    Zone C (analysis)     Zone D (control)
-------------------------   ---------------------------   -------------------    -----------------
Cloudflare Worker     -->   MCP honeypot server      -->  24-dim fingerprint    STIX 2.1 emitter
R2 (digest-only)           (gVisor sandbox in K8s)        actor clustering      SIEM / MISP output
                           zero egress                    anomaly detection      evolution engine
                           synthetic responses only       audit ledger           tenant API / billing

• Zones communicate over NATS JetStream when configured; file fallback in lab mode. No zone trusts another by network position.

• Zone B has zero egress: the honeypot can record but cannot reach out — an agent inside cannot use it as a relay.

• All state flows one direction (B → C → D); control plane changes (new lures) flow back only through the validation gauntlet + human approval.

Details: docs/ARCHITECTURE.md.

Security guarantees (tested)

These are machine-checked in tests/security.test.mjs — the CI fails if any stops being true:

1. Digest-only persistence. Raw argument text never reaches disk — SHA-256 digests only. The suite feeds known secret strings (API keys, SQLi, private keys) through the capture plane and asserts none appear in the store.

2. Tamper-evident audit ledger. Privileged operations append to a hash chain; verifyLedger() detects any edited entry and reports where. The test forges an entry and asserts detection.

3. No raw text in the LLM path. Antigen profiles for candidate generation contain counts and hashes only.

4. Human promotion gate. Lures move live only via human action — no programmatic promoteToLive() exists in the codebase.

5. Per-tenant isolation. Schema mutation is deterministic per tenant and synonym-only (semantics never dropped).

6. Synthetic responses. Every response is generated fiction; canaries are marked simulated.

Ethics: this tool is for defenders studying surfaces they own. It does not exfiltrate data from visiting agents beyond fingerprint digests, and it cannot be used offensively. See SECURITY.md.

Extending: adding a new honeypot server

The finance-warehouse server is one instance of a pattern. To add a new fictional surface (e.g. an "hr-portal"):

1. Contract first — create lures/hr-portal/lure.yaml following the existing contract (family, privilege levels, budgets, shadow rules).

2. Payloads — add payloads/ entries with explicit privilege_claim (L1/L2/L3) and success_signal.

3. Server — copy surface/mcpservers/finance-warehouse/ as a template; register your tools with the recorder (see mcp_server.ts for the single-path capture convention).

4. Benign corpus — extend corpus/benign/ if your tools widen false-positive risk (a legitimate internal tool that resembles your bait is the classic FP source).

5. Test — mirror the coverage in tests/integration.test.mjs and keep npm test green.

Contributions adding offensive capability (payload delivery, harvesting beyond digests) will be rejected — see CONTRIBUTING.md.

Extending: the evolution engine

When a session escapes (connects but never takes the bait), the system can generate improved lure candidates:

escaped session
  → antigen (structured profile — no raw text, hashes only)
  → candidates (deterministic templates in lab mode; your LLM via AGENT_HONEYPOT_LLM_URL)
  → validation gauntlet (self-monitor, benign-corpus FP < 2%, anti-fingerprint checks)
  → SHADOW deployment (>= 7 days, >= 50 sessions)
  → human approval        ← the only path to live
  → live (Thompson-sampling bandit rotates variants)

The reward function (bait_config/contextleak_reward.yaml) mirrors ContextLeak's, defender-operated: reward bait-selection and context-completeness, penalize detection signals and benign false-positives.

Deployment tiers

Docker

docker compose up -d
# dashboard: http://localhost:9079
# honeypot on stdio: docker exec agent-honeypot node bin/agent-honeypot.mjs serve

Multi-stage build (node:20-slim), health-checked, persistent volume for captures, optional NATS sidecar (uncomment in docker-compose.yml).

Testing

npm test    # 57 tests, 7 suites, ~3 seconds (core, invariants, no live servers)

CI runs the full matrix (Ubuntu + Windows × Node 20/22/24).

Live agent test suites

Beyond the unit suites, the repo ships standalone live harnesses that drive both honeypot MCP servers over the real MCP protocol and exercise bait-taking, canary trips, escalation chains, and edge cases end to end:

node tests/mega_test_suite.mjs        # 56 scenarios across both servers
node tests/deep_test.mjs              # 37 scenarios: injection, disclosure, persistence, pagination, edges
node tests/agent_simulation_test.mjs   # 13 steps: ASSASSIN / autonomous / benign agent profiles
node tests/direct_mcp_test.mjs         # 6 scenarios: raw MCP protocol verification

Run npm run build first — the harnesses spawn the built servers over stdio. Each run appends real capture events to data/sessions.jsonl (digest-only), then runs the analysis pipeline and prints tier / cluster / anomaly output.

Latest full run: 112/112 scenarios passed, producing 110 sessions, 319 capture events, 12 high-tier sessions, 16 canary trips, 12 STIX bundles, and 43 distinct actor clusters — every alert tier (low/medium/high) exercised.

All sample credentials in these harnesses are synthetic placeholders (they match canary patterns on purpose — that is what trips detection).

Wiring the honeypot to a real agent client

See tests/INTEGRATION_GUIDE.md for drop-in MCP config snippets for Claude Desktop, ASSASSIN, OpenClaw, and any stdio MCP client. tests/openclaw_honeypot_test.mjs and tests/opencode_honeypot_test.mjs drive a real agent CLI against the servers when installed (OPENCLAW_BIN / OPENCODE_BIN env vars override the binary path).

Troubleshooting

npm test says dist/... not found You skipped the build. Run npm run build first.

agent-honeypot serve exits immediately Check you built (npm run build) — the CLI refuses to serve without dist/. npm run doctor confirms.

Dashboard shows 0 sessions Captures only exist after an agent actually connects (or after npm run seed). Verify the path: npm run dash then check /health and confirm data/sessions.jsonl exists.

A tool call returned an error (429) That's the error-injection realism (~3%). It's by design — retry, like a real client would.

My captures disappeared Did you set AGENT_HONEYPOT_DATA_DIR differently in the two shells? All state follows that variable. npm run doctor shows the active data dir.

Windows: garbled characters in console output PowerShell 5.1 defaults to a legacy code page. Run chcp 65001, or just open the dashboard in a browser instead of curl-ing it.

Port already in use Set AGENT_HONEYPOT_DASH_PORT / AGENT_HONEYPOT_TENANT_API_PORT to something free.

FAQ

Can a visiting agent steal anything from it? No. Every response is synthetic. There is no real database, no real credentials, no secrets in the process, and no network egress from the honeypot. The agent can only read fiction. (Tested: the security suite proves secret strings fed into the honeypot don't even persist on our side.)

Wait — the agent might inject me through tool results. Is that handled? That's a real class of attack (tool-output injection), and the design accounts for it: analysis components never consume raw attacker text (only digests/structured profiles), and the evolution engine's LLM hook only ever sees bounded, structured antigen data — a meta-injection has nothing to attack.

Is this an attack tool? Could I point it at someone else's agents? No. It's a passive listening surface — it has no capability to reach out, exploit, or exfiltrate. Deploying it against systems you don't own would just be... running a server nobody visits. It's useful exactly one way: on infrastructure you control, telling you who's visiting.

How do I know the fingerprints are accurate? They're behavioral measurements, not magic. Each dimension reports its own confidence, and the composite reports its coverage percentage. Coarse dimensions (model-family) are documented as coarse — the research agenda is in Limitations.

What's a "session"? One MCP stdio connection. One connecting process = one session = one fingerprint.

Does it work with real Claude / GPT agents autonomously? Yes, any MCP client. The tools look like a plausible internal finance system; well-behaved agents will ignore or politely decline, suspicious ones will probe — that's the signal.

Can I run it in Docker / Kubernetes? Yes — infra/helm ships a chart, and infra/terraform covers the network policies. Lab mode needs neither.

How do I cite this? See CITATION.cff.

Repository layout

analysis/     fingerprint extractors (24 dims), clustering, anomaly, STIX
antibodies/   Tier-0 self-monitor (CAITLYN pattern)
bin/          CLI entry point (agent-honeypot)
capture/      shared paths, session recorder, event bus
control/      dashboard, tenant API, SIEM/MISP, report, billing
corpus/       benign replay corpus (false-positive gate)
credential/   simulated canary templates
docs/         architecture reference, logo
examples/     MCP client guides
evolution/    counterexample engine, RL bandit, hardening suite
honeydocs/    synthetic documents
infra/        Terraform, Helm, Cloudflare, ClickHouse, pgvector, Vault, metrics
lures/        lure contracts with lineage
mcp_tool/     tool contract JSON Schema
payloads/     L1-L3 injection payload definitions
scripts/      seed utility
security/     hash-chain audit ledger, rotation schedules
surface/      MCP honeypot servers (finance-warehouse)
tests/        5 suites, 47 tests

Glossary

• Bait / lure — a tool or document engineered to elicit a specific agent behavior (disclosure, persistence).

• Bait taken — the agent provided the requested context/fields, crossing the capture threshold.

• Capture threshold — the context-length boundary that marks bait-taking. As of v0.2.1 the boundary jitters ±15% per session (drawn once per server process around the documented mean, e.g. ~40 chars for db_query). Aggregate capture statistics are unchanged, but a probing agent cannot bisect the exact boundary across sessions — its calibration converges on noise.

• Canary — a uniquely-marked fake credential or string; use of it is proof of malicious execution. Ours are simulated and webhook-instrumented. Matching is confusable-folded (fullwidth/homoglyph re-encodings of a canary still trip detection).

• Digest — a fixed-length SHA-256 hash (full 64-hex as of v0.2.1; legacy 16-hex rows remain readable). Lets us count and correlate without storing attacker content.

• Escape — a session that connected but never took the bait. The evolution engine's input.

• L1/L2/L3 — bait privilege-claim levels: note → system-level → harness-level (from When Context Gets Root).

• Shadow deployment — a new lure variant serves only synthetic traffic silently, accumulating evidence before any human promotion decision.

• Tarpit / pagination trap — a deliberately slow, paginating resource that measures how long an agent will grind.

Limitations

Pre-alpha research prototype, stated plainly:

• Model-family heuristics are coarse (stylometry-informed since v0.2.0, but a trained classifier is future work).

• TLS/GeoIP dimensions (13-14) require edge termination to produce values.

• The RL reward function is specified and unit-tested; the bandit rotates phrasing variants but no fine-tuned generator ships in this release.

• MITRE ATLAS IDs in analysis/ttmapper/atlas_map.yaml are marked verify before external sharing.

• Latency and error-rate realism values are lab-calibrated; production tuning is a deployment concern.

• Docker image is provided as a convenience; no hardened container configuration is claimed (run behind your own network controls in production).

Contributing

Defensive research only — see CONTRIBUTING.md. Ground rules: no secrets, no real data, cite the research a new heuristic derives from, keep npm test green and npm run typecheck clean.

References

1. Jia, Y. et al. ContextLeak: Exfiltrating LLM Agent Context via Malicious Tools. arXiv:2608.27800 (2026).

2. Liu, Y. et al. LongPIBench: A Long-Context Benchmark for Prompt Injection. Findings of EMNLP 2026.

3. He, X. et al. When Context Gets Root: Privilege Escalation in LLM Harnesses. arXiv:2608.27299 (2026).

4. Liang, Z. et al. CAITLYN: Can LLM Agents Autonomously Synthesize Defenses against Emerging Injection Attacks? (2026).

5. Wu, C. et al. Safety Does Not Compose: Non-Decaying Loop State for Autonomous LLM Agents. arXiv:2608.27141 (2026).

6. McFadden, S. et al. REPLICANT: Learning Policies for Evading and Hardening Malware Detectors. arXiv:2608.28499 (2026).

7. CrowdStrike. 2026 Global Threat Report.

8. Model Context Protocol. Tools Specification, 2025-06-18.

9. Spitzner, L. Honeypots: Tracking Hackers. Addison-Wesley (2002).

License

MIT — see LICENSE.