FSR-Playbooks LLM-Authored Playbook Compilation or Publish
This rule flags when someone uses an AI co-authoring tool to write or publish security automation playbooks for FortiSOAR. It's not proof of an attack — it's a review trigger, so a human checks the AI-generated automation before it runs in production.
How the attack works
An engineer or automated pipeline runs the fsr-playbooks command-line tool with an option that invokes an LLM (co-authoring, prompt, model, or MCP-serve) or that publishes/deploys a playbook to FortiSOAR. Separately, the rule watches for HTTP uploads of FortiSOAR Workflow JSON that either name the AI model that drafted it or contain text that looks like an instruction override — the kind of phrase an attacker could smuggle into a document to hijack an AI reader. The detection only fires when two distinct, specific markers appear together in one event, which keeps it narrow. The rule explicitly does not try to prove that a prompt injection led to a malicious playbook being generated and deployed — the telemetry available cannot connect those dots, so it doesn't claim to.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7c3f9a41-58d2-4be6-9f0a-1d84c6b7e352
- Severity
- Medium
Why it matters
If an attacker manages to inject hidden instructions into content an AI playbook-authoring tool reads, that AI could be tricked into generating and publishing a malicious automation workflow into FortiSOAR — potentially giving attackers a path to execute actions inside the security orchestration platform. This rule only surfaces the artifact (the CLI call or the JSON payload with suspicious markers), not confirmation that such an attack happened.
What you can do
- →Treat any AI-authored playbook as unreviewed code: require human sign-off before it is promoted or deployed to FortiSOAR.
- →Scan playbook JSON and any source documents feeding the AI co-author for instruction-override phrases (e.g. 'ignore previous instructions') before ingestion.
- →Restrict who can run fsr-playbooks with publish/deploy verbs, separate that permission from routine authoring use.
- →Keep authorship attribution metadata on generated workflows so reviewers can trace which playbooks were AI-drafted and audit them specifically.
Known benign look-alikes
- A playbook engineer legitimately using the fsr-playbooks LLM co-authoring feature during normal authoring work — this is the intended product workflow and will match branch 1. The rule reports rather than blocks precisely because the invocation itself is sanctioned; the signal exists so that machine-generated playbooks can be reviewed before promotion.
- Running the fsr-playbooks MCP server as a long-lived development service (mcp serve) on an engineer workstation.
- CI/CD promotion of already-reviewed playbooks where the pipeline retains an authorship attribution field naming the model that drafted them.
- FortiSOAR playbooks that intentionally contain prompt-injection strings as detection content or test data (phishing-triage, LLM-abuse hunting playbooks). Mitigated by filter_detection_content, which suppresses bodies carrying detection-rule fields such as "pattern", "signature", "regex" or Sigma/YARA references.
- Template and scaffold files where the model attribution value is an unfilled placeholder. Mitigated by filter_placeholder.
- CLI help, version and schema-dump invocations. Mitigated by filter_help.