What the agent blocks today, why, and what a production deployment would add next. The guardrails node is the only point in the pipeline that sees raw user input before an LLM does — everything downstream trusts that the topic was screened here.

For the broader security posture (rate limits, JWT, key handling, no auto-connection-request code) see docs/rules/security.md. This document covers prompt-injection specifically.

The agent runs against an authenticated single-admin FastAPI backend, so a random attacker on the public internet can't submit a topic without first brute-forcing /token past the slowapi limiter (5/min/IP). The realistic abuse vectors are therefore:

1. A compromised admin account submitting hostile topics — direct prompt injection of the drafter.
2. A poisoned context chunk in pgvector being retrieved into a prompt — indirect prompt injection via RAG.
3. A model that happens to invent malicious content — output filter territory.

This Day 8 implementation addresses (1). Vectors (2) and (3) are explicitly in the v2 roadmap below.

src/linkedin_agent/guardrails/injection.py regex-matches an NFKC-normalised, zero-width-stripped copy of the topic against the families below. The canonical signature is prompt_injection_guardrail(text: str) -> bool — True means BLOCK. The caller (guardrails_node) translates that into PostStatus.CANCELLED + an error_message, and the conditional edge in graph/builder.py (did_pass_guardrails) routes blocked runs straight to END so no LLM call happens.

• Zero-width characters (U+200B–U+200D, U+FEFF BOM, U+00AD soft hyphen) are stripped before matching, so Ig​nore all previous … still hits.
• Full-width Latin (U+FF21–U+FF5A) is NFKC-normalised to ASCII, so Ｉｇｎｏｒｅ all previous … still hits.

• Base64 / hex / ROT13 — decoding inside the guardrail invites a parsing exploit and adds cost on every benign topic. The output filter (v2, below) is the right place for this.
• Long-context burying (the attack lives inside paragraphs 4-5 of a multi-page topic). MVP topics are ≤500 chars (AgentState.topic validator), so the surface is small.
• Semantic / intent-level attacks worded as ordinary English. Caught only by a model-based judge — v2.

tests/security/test_guardrails.py runs against tests/security/adversarial_inputs.json — 10 attacks (5 hand-written + 5 Lakera-style) and 10 benign topics drawn from the eval set.

.venv/bin/pytest tests/security/ --no-cov -v

Gate (spec): 10/10 attacks blocked · 0/10 benign topics blocked.

Two parametrised tests pin each item individually so a regression points at the exact attack/topic that broke; two aggregate tests assert the total count matches the spec wording.

The current defence is a deny-list: it catches the shape of known attack patterns and nothing else. A production deployment should layer:

1. Output filter. Re-run the guardrail (plus length / link / pattern checks) on the draft before it goes to PostBoost. Catches attacks that survive the topic gate via indirect injection through retrieved context. Cheap, high signal. Highest priority for v2.
2. Context-chunk sanitisation. Strip injection-shaped tokens from retrieved RAG chunks before they become part of the LLM prompt. Pairs with #1.
3. Embed-and-classify. Cosine distance against an embedded corpus of known injection probes (Lakera Gandalf, PromptInject taxonomy). Catches paraphrased attacks the regex misses; one extra embedding call per topic.
4. Cross-model intent judge. Send the topic to the Day-5 judge (Claude Sonnet 4.6) with an "is this prompt injection?" prompt. Adds latency + cost; the right tool when the volume is small and the cost of a false negative is high.
5. Block-rate alerting. Per-IP block counter wired into the Day 10 Uptime Kuma + Telegram channel — a spike is an attack indicator and should page someone.

These items live in docs/v2-roadmap.md. They are out of scope for the 14-day MVP — adding them inside MVP pushes past the kill-switch budget (see IMPLEMENTATION_PLAN.md § "Kill-switch order").