Guides / Agent attack tests

Agent attack tests

kosa8 attack puts a fixed catalogue of AI-agent attacks to kosa8's own controls on your machine, and records what stopped each one and what did not. Every scenario carries its OWASP Top 10 for LLM Applications 2025 and MITRE ATLAS ids. The result is a scorecard signed with this machine's audit key, which a security reviewer can check without trusting you or us.

Run it

$ kosa8 attack list                  # the catalogue, with OWASP and ATLAS ids
$ kosa8 attack run                   # both postures, policy mode, signed scorecard
$ kosa8 attack run exfil-secret AK-08  # only these scenarios
$ kosa8 attack run --live            # also inside real sandboxes
$ kosa8 attack verify ~/.kosa8/attack/atk-….json --kid SHA256:…
$ kosa8 attack upload ~/.kosa8/attack/atk-….json   # or: run --upload

Three results

A scenario is made of attempts; an agent only needs one to get through, so a scenario's result is its weakest attempt. An attempt's result is its strongest layer: one refusal stops it.

Two postures

default is this machine as it is configured now: the org policy's default_egress if one is installed (else any), the installed signed MCP policy if there is one, MCP pins on first use, no pre-run hook. hardened is the setup kosa8 recommends for an agent: an egress allow-list through the broker (Anthropic's API, PyPI, npm and GitHub, port 443), egress deny otherwise, the pre-run hook on, a signed MCP policy with org-pinned tool definitions. Running both shows what changing the settings buys.

The scenarios

Results are on a machine with no org policy installed. Your default column depends on your settings; that is the point of running it.

OWASP: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM06 Excessive Agency (genai.owasp.org/llm-top-10). ATLAS ids are from ATLAS 2026.10 (atlas.mitre.org): T0051.001 Prompt Injection: Indirect, T0086 Exfiltration via AI Agent Tool Invocation, T0025 Exfiltration via Cyber Means, T0055 Unsecured Credentials, T0098 AI Agent Tool Credential Harvesting, T0072 Cyber Communication Channel, T0101 Data Destruction via AI Agent Tool Invocation, T0050 Command and Scripting Interpreter, T0110 AI Agent Tool Poisoning, T0011.002 Poisoned AI Agent Tool, T0010.005 AI Agent Tool (supply chain), T0053 AI Agent Tool Invocation, T0010.001 Software (supply chain), T0011.001 Malicious Package, T0081 Modify AI Agent Configuration. kosa8 attack list prints every name.

What blocks what is ALLOWED by default

Policy mode and live mode

Policy mode (the default) needs no daemon and no VM, so it runs in CI and in unit tests. Each attempt goes through the real decision code: the rules engine, a real egress broker on a loopback port with dialling switched off (nothing leaves the machine), the host network guard fed the DNS query and TCP SYN the sandbox would send, the MCP policy engine, the MCP pin check, and the sandbox's mount layout. It shows what those controls decide; it does not show that the packets would have gone nowhere.

Live mode (--live) then boots one small sandbox per posture (alpine:3.20) and runs the network and isolation scenarios (AK-01, 02, 03, 07, 08) inside it with wget, against harmless public names. The verdict comes from the daemon's audit log, not from exit codes: a request is BLOCKED only if a sandbox.egress.deny entry for it was written, and the result carries that entry's sequence number and hash. A request that failed for any other reason is still ALLOWED, with a note that no kosa8 control refused it. The sandboxes are removed afterwards. Without a running daemon, --live says so and the run stays in policy mode.

The signed scorecard

Each run writes a file of this shape:

{ "format": "kosa8.attack.scorecard/v1",
  "payload": "<base64 of the scorecard JSON>",
  "key": { "alg": "ed25519", "kid": "SHA256:…", "public": "<base64 DER public key>" },
  "sig": "<base64 signature>" }

The signature is over kosa8.attack.scorecard/v1, a newline, then the payload bytes, made with the same key that signs this machine's audit log (kosa8 audit key prints its id). The prefix keeps a scorecard signature from ever being mistaken for an audit entry's. The scorecard inside holds every result with its attempts and evidence, the kosa8 version and platform, the framework versions, a digest of the results, and the disclaimer above. When the daemon is running, the run is also written to the audit log as an attack.run entry whose fields hold that digest and each scenario's outcome, so the scorecard is anchored in the hash chain.

$ kosa8 attack verify atk-….json --kid SHA256:e218d6…
signature      ok (ed25519 SHA256:e218d6…)
results digest ok
pinned key     ok
run            atk-20261111T213822Z-675c4950, policy mode
default        2 blocked, 0 need approval, 7 allowed
hardened       8 blocked, 1 need approval, 0 allowed
verified

verify checks the signature, that the key's id matches the key, and the results digest, and exits non-zero if any fails. --kid pins the key you expect, which is what a reviewer on another machine should do: a valid signature only proves that the holder of that key signed these results. verify works on a machine that has not signed in to kosa8.

In the desktop app

Security → Attack tests runs both postures in policy mode, shows the table with OWASP and ATLAS labels (hover a label for its name), what blocks each ALLOWED result, and where the file was saved. Export saves the signed file; Upload sends it to your kosa8 Cloud org once the app is linked to it.

In kosa8 Cloud

Upload with kosa8 attack run --upload, kosa8 attack upload FILE, the desktop app, or POST /v1/attack/scorecards with {"signed": <the file>} (a key with sandboxes:write). kosa8 Cloud checks the signature itself before it stores anything, and refuses a changed file with 422 scorecard_invalid. Each upload, accepted or refused, is an attack.scorecard_upload event in the org's audit log. Stored scorecards are listed by GET /v1/attack/scorecards and fetched as uploaded from GET /v1/attack/scorecards/{id}, for anyone to check again with kosa8 attack verify. The results are shown in the CLI and the desktop app's Security screen.

Limits

• Nine scenarios, chosen because kosa8 has a control for each. Attacks outside the catalogue are not tested.
• AK-07 catches a look-alike registry. A misspelt package name on the real registry is not caught by any kosa8 control.
• The rules in AK-04 and AK-09 apply only to agents run under the pre-run hook (kosa8 agent claude).
• AK-02 tests the host's files. Credentials you place inside the sandbox are readable by what runs there; keep them out with brokered keys.
• Policy mode tests decisions; live mode tests the network path for five scenarios. Neither tests the VM boundary itself.