Security scanning

Agents fail in ways ordinary code doesn't. A prompt can be hijacked by text the agent reads. A tool can be talked into sending email to an attacker. A Python tool can reach a URL it was never meant to.

Convolution Labs scans your agents for these problems while you're still building — not after an incident. Run a scan from Dashboard → Security, or from an individual agent's security tab.

Two kinds of scan

Static scan

Analyses the agent's graph without executing anything: nodes, edges, configuration, prompts, and the source of any custom Python tools. It's fast, deterministic, and free.

Nine checks run today:

Check	What it catches
static.injection.unsanitized_input	User input flowing into a prompt with no sanitization
static.injection.indirect_tool_feedback	Tool output fed back into a prompt — the indirect injection path
static.disclosure.secret_in_prompt	Credentials or keys hardcoded in a prompt
static.ssrf.unfiltered_http	HTTP tool calls with an attacker-influenceable URL
static.agency.email_from_public_input	Send-email reachable from public input
static.output.unvalidated_sink	Model output flowing into a sink without validation
static.sandbox.python_present	Custom Python present — flags the expanded attack surface
static.dos.unbounded_iterations	Loops with no iteration ceiling
static.dos.unbounded_delay	Delay nodes with no bound

Dynamic scan

Actually attacks your agent — through its normal execution path, using the same queue and worker as a real run. Each probe plants a server-generated canary and a detector inspects the output and trace for evidence the attack landed.

Probe	Attack
dynamic.injection.canary	Injects instructions and checks whether the agent obeys them
dynamic.disclosure.prompt_leak	Tries to make the agent reveal its system prompt
dynamic.jailbreak.refusal	Tests whether safety refusals can be bypassed
dynamic.ssrf.canary	Tries to make the agent fetch an attacker-chosen URL

note

Dynamic scans execute your agent, so they consume credits for any tool calls and use your LLM provider keys — exactly like a normal run. They only ever target agents you own.

Findings

Every finding carries:

• Category — one of eight, mapped to the OWASP LLM Top 10 and NIST AI RMF
• Severity — CRITICAL, HIGH, MEDIUM, LOW or INFO
• Evidence — the specific node and snippet that triggered it
• Remediation — what to change

Categories

Category	Meaning
PROMPT_INJECTION	Untrusted text steering the agent's behaviour
SENSITIVE_INFO_DISCLOSURE	Secrets or system prompts leaking out
INSECURE_OUTPUT_HANDLING	Model output trusted by a downstream sink
EXCESSIVE_AGENCY	The agent can take actions beyond what it should
SSRF	Server-side request forgery through outbound calls
SUPPLY_CHAIN_SANDBOX	Risk introduced by custom code and dependencies
UNBOUNDED_CONSUMPTION	Loops or delays with no ceiling — cost and availability
JAILBREAK	Safety constraints bypassed

Triage

Each finding has a status you control:

• OPEN — counts against your score
• ACKNOWLEDGED — seen, accepted for now
• RESOLVED — fixed
• FALSE_POSITIVE — not applicable to your case

Only OPEN findings affect the score, so triaging honestly raises it.

The security score

A deterministic 0–100 score, explainable rather than a black box. Start at 100 and subtract a fixed penalty per open finding:

Severity	Penalty
CRITICAL	−40
HIGH	−20
MEDIUM	−8
LOW	−3
INFO	0

The score floors at 0, and maps to a grade:

Score	Grade
90–100	A
75–89	B
50–74	C
25–49	D
0–24	F

Because the model is fixed, you can always explain a score — "−40 from one critical finding" — and see exactly what fixing an issue would recover.

Reference

Dashboard → Security → Reference documents every category: what the weakness is, how it shows up in this platform specifically, an illustrative example payload, and which checks detect it. Both the OWASP LLM Top 10 and NIST views render from that catalog.

Limits

Scans are rate-limited to 10 per hour per user.