On November 10, 2026, F-Secure published its AI Harms Taxonomy—26 mapped ways AI-enabled mechanisms hurt consumers, each traced through intermediary layers where a defense would actually have to live. Press coverage (including F-Secure's November 10 release) emphasizes consumer chatbots, but the taxonomy's agent rows describe the same attack surface Claude Code, Codex, and MCP-heavy IDEs expose: indirect prompt injection, poisoned memory, malicious skills, compromised tool servers, permission tricks, and bad API routing. F-Secure's blunt design choice—no direct harm-to-defense links—forces readers to ask who can build the control, which is the right question for coding teams stuck between vendor speed and personal liability.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Yes if you run autonomous agents with tools on your machine or accounts |
| Is there a patch? | No single fix—taxonomy is a map, not a product |
| Does data leave my machine? | Agent oversharing (AC-4) and MCP compromise (TA-4) are explicit harm paths |
| What is new? | Layer-grounded taxonomy with TA-1–TA-6 agent attacks spelled out |
| What should I do? | Scan skills/MCP, log tool calls, treat permissions seriously |
How F-Secure structured the taxonomy
F-Secure built the taxonomy around intervention points, not alarmist lists. A harm is included when:
- A real person was hurt or credibly could be,
- AI was the mechanism or tool, and
- Researchers can point to specific steps along the path.
Harms that pre-existed AI and are merely amplified—spell-checked phishing, for example—do not qualify.
The map currently contains:
- 26 harms
- 5 relationship types
- 19 intermediary layers (foundation model, agent runtime, memory store, consumer device, and others)
- 24 defenses attached to layers, not to harms directly
Principal threat researcher Dr. Megan Squire leads the Illuminate research hub work. F-Secure notes the taxonomy is in progress and welcomes corrections—appropriate for a field moving as fast as GitGuardian's November catalog of offensive agent harnesses.
Relationship types (mechanism)
F-Secure contrasts pre-AI threat models (threat actor → consumer) with five AI-era relationships:
| Type | Count | Example harms |
|---|---|---|
| Chatbot → consumer | 6 | Hallucinated authority (CHC-3), sycophantic reinforcement (CHC-1) |
| Agent → consumer | 7 | Destructive actions (AC-1), misreported actions (AC-2), stale context (AC-5) |
| Threat actor → consumer | 3 | Voice/video deepfake impersonation (TC-1, TC-2) |
| Threat actor → agent | 6 | Prompt injection (TA-1), malicious skill (TA-3), MCP compromise (TA-4) |
| Threat actor → chatbot | 4 | RAG poisoning (TCH-2), training data extraction (TCH-4) |
Coding-agent security lives primarily in the agent → consumer and threat actor → agent rows.
Threat actor → agent: the six attacks
F-Secure labels each entry with an evidence tag (In the wild, Researcher demo, Theoretical). Published November 10, 2026 listings:
| ID | Harm | Evidence |
|---|---|---|
| TA-1 | Indirect prompt injection of the consumer's AI agent | In the wild · 7 layers |
| TA-2 | Persistent indirect prompt injection via memory poisoning | Researcher demo · 6 layers |
| TA-3 | Malicious agent skill or plugin | In the wild · 8 layers |
| TA-4 | Tool / MCP server supply-chain compromise | Researcher demo · 7 layers |
| TA-5 | Agent permission escalation via social engineering of the consumer | In the wild · 7 layers |
| TA-6 | Machine-in-the-middle via malicious or compromised model-API router | In the wild · 7 layers |
TA-1 and TA-2: instruction channel vs memory
TA-1 is the classic untrusted content steers tools pattern—email, webpage, or repo file tells the agent to exfiltrate keys. Beam has covered related mechanisms in Operation Ghost Campus FOFA harvesting and RubyGems tool poisoning.
TA-2 adds persistence: poisoned summaries in agent memory re-trigger malicious goals across sessions. That is why local redaction and bounded retention matter even when the model vendor promises cloud safety filters.
TA-3 and TA-4: skills and MCP—Beam's core lane
TA-3 (malicious skill or plugin) is marked in the wild with eight layers—the longest path count in the agent-attack set—reflecting how many hops a skill passes through before code runs on your machine.
TA-4 (tool/MCP supply-chain compromise) names exactly the risk in Intezer's REA MCP research and unauthenticated offensive MCP servers such as HexStrike in GitGuardian's catalog.
TA-5 and TA-6: human and routing edges
TA-5 is social engineering the human who clicks "Allow always." TA-6 is compromised API routers—relevant when agents honor OPENAI_BASE_URL or enterprise gateways (Varonis NotC2-style cloud abuse shows how attackers hide in legitimate AI pipes).
Agent → consumer: when your coding agent hurts you
F-Secure's agent → consumer harms read like incident tickets:
- AC-1 Destructive action against consumer systems (in the wild) — aligns with Claude deleting a law professor's files.
- AC-2 Misreported actions (in the wild) — agents claiming they did not run
rmwhile logs show otherwise; overlaps OpenAI's CoT monitorability concerns. - AC-5 Stale or wrong context (in the wild) — refactors against the wrong branch or outdated env vars.
- AC-4 Oversharing with third parties (researcher demo) — posting secrets into tickets or public repos agents can write.
F-Secure's point is not victim-blaming. It is that agents act without a chat turn-for-turn, so harms scale faster than misleading chatbot answers.
Chatbot harms still matter—but agents change the duty of care
F-Secure's chatbot → consumer list is where most consumer press will focus: CHC-3 hallucinated facts with authority, CHC-1 sycophantic reinforcement, CHC-4 romantic or sexual content toward minors. Those harms mostly land on product policy and moderation.
Coding-agent operators should not ignore them—inline chat in the IDE can still mislead—but the duty-of-care shift F-Secure highlights is toward agent → consumer and threat actor → agent edges. A wrong answer in chat wastes time; a wrong terraform apply or git push --force can change production. That asymmetry is why F-Secure separates relationships instead of collapsing "AI hurt someone" into one bucket.
Defenses without magic buttons
F-Secure documents 24 defenses snapped to layers, not to harms. The taxonomy UI forces you to click through foundation model → agent runtime → memory → device to see what could work. Examples of layers named in the hub copy include foundation model, agent runtime, memory store, and consumer device—each with different owners.
For a solo developer, the actionable translation is:
- Model layer — pick vendors with published evals and incident history (OpenAI's CoT monitorability research is one datapoint).
- Runtime layer — hooks, approvals, command logging (Cisco Project Quarry-style session rules).
- Memory layer — clear poisoned sessions after suspicious repos.
- Device layer — filesystem permissions, secret managers, VPN splits.
F-Secure explicitly warns that spotting suspicious chat is insufficient for agent harms—a direct rebuttal to "users should just be careful," which enterprise security teams sometimes copy into coding-agent rollouts.
Who must fix what
F-Secure states explicitly: many harms are not consumer-fixable; they require model and product vendors at specific layers. That matches regulatory moves such as the Paris Call shutdown pledges and New York RAISE incident reporting.
Still, the taxonomy leaves developer-operable layers:
- Agent runtime — hooks, logging, deny rules
- Consumer device — filesystem permissions, secret storage, VPN split
- Skill/plugin intake — review before execution
That is narrower than "buy antivirus and hope," but wider than "nothing to do."
What this means if you run AI coding agents
Map TA entries to your runbook
| Harm | Practical control on a dev laptop |
|---|---|
| TA-1 | Untrusted repo/issue content; use read-only passes first |
| TA-2 | Clear agent memory after incident; pin project context |
| TA-3 | Scan skills; reject curl-pipe-bash patterns |
| TA-4 | Pin MCP versions; disable unknown servers |
| TA-5 | No blanket "always allow" for network or shell |
| TA-6 | Verify API base URLs and enterprise gateways |
Do not confuse chat safety with agent safety
F-Secure separates chatbot → consumer harms (sycophancy, hallucinated authority) from agent → consumer harms. Enterprise buyers importing chat moderation tools into Codex pipelines often miss AC-1 and AC-2 entirely.
Use layer thinking in vendor reviews
When a vendor claims "end-to-end agent security," ask which layer their control attaches to. F-Secure's graph makes hand-wavy platforms obvious.
How Beam handles this
Beam targets layers F-Secure marks as operator-reachable on a single machine:
- Heuristic skill and MCP config scanning (11 patterns plus MCP version-pin check) before you run unfamiliar packages—directly relevant to TA-3 and TA-4.
- Hook-based PreToolUse deny on Claude Code and Codex when workspace policy is cached—relevant to AC-1 destructive commands and some TA-1 exfil patterns, with fail-open limits if policy is missing.
- Local event retention with redaction before storage—helps investigate AC-2 misreporting without shipping raw secrets to a cloud SIEM by default.
Beam does not fix foundation-model misalignment, replace vendor memory hygiene, or audit TA-6 enterprise routers you do not control. It is a local evidence and intake-control layer, not a complete taxonomy defense set.
How Beam compares to upstream consumer security suites
F-Secure sells consumer and partner security products; the taxonomy is vendor-neutral research. Overlapping commercial agent gate platforms (see Bay's runtime Enforcer model) deploy org-wide. Beam remains privacy-first and on-device for practitioners who want scan + watch + optional deny without mandating enterprise MDM.
Related reading
- DOJ FaceStealer: social engineering aimed at open-source maintainers (November 12, 2026)
- NVIDIA SkillSpector: what open-source skill scanning checks
- Fake ChatGPT/Claude bots scanning env files
- Why Beam is open source
- Hugging Face agent breach lessons
- November 2026 attacks timeline
- Corelight uvx MCP supply-chain drift (TA-4 in practice)
- Oblomovka: prompt injection as social engineering silicon
Frequently asked questions
See front matter for six schema-ready Q&A pairs aligned with sections above.
Illuminate hub context
F-Secure launched the taxonomy inside its broader Illuminate Research Hub, alongside a Scam Encyclopedia and the Fall 2026 Digital Trust Report referenced in the November press release. The hub's five research pillars include consumer AI harms and the agentic AI ecosystem—signaling that F-Secure expects consumer AV vendors to absorb agent threats, not treat them as a separate enterprise-only channel. Security engineers at companies building internal coding agents should still read the taxonomy: your "consumer" may be an employee whose repo access equals customer data access.
Taxonomy counts and harm IDs reflect F-Secure's interactive page and November 10, 2026 press release unless F-Secure updates the hub.