AI security rules and dataflow analysis

CodeStax checks the AI code and configuration in your repositories against a catalogue of 45 rules: 13 rules for LLM applications and agents (AIASM-LLM*) and 32 rules for Model Context Protocol (MCP) clients, servers and packages (AIASM-MCP-*). Every rule maps to a category of the OWASP Top 10 for LLM Applications 2025.

This page is the rule reference. For the inventory, BOM, triage, approval and policy workflows that consume these findings, see AI Attack Surface Management.

How a finding is decided

Every finding records how it was decided. The dashboard shows this as a tag under the confidence value, so you can tell a proven path from an inference before you act on it.

The method is also returned as analysis_method on each finding from the AI Attack Surface API. The Overview tab of AI Attack Surface shows a Dataflow-proven count: findings where a source-to-sink path was traced rather than inferred from nearby code.

Rules confirmed by dataflow analysis

Twelve rules are owned by the dataflow engine. When the engine runs, CodeStax reports these rules only from the engine’s results and does not also emit the heuristic version, so a proven finding is never duplicated by a weaker guess.

When dataflow analysis is unavailable

If the dataflow engine cannot run for a scan, the run records that dataflow was unavailable and the twelve rules above fall back to their heuristic versions. Those findings carry the Inferred tag, not Dataflow proven, so an unverified result is never presented as a proven one. A repository with no AI-bearing files needs no dataflow analysis and is treated as complete.

An unavailable dataflow engine weakens the evidence but does not mark the run’s file coverage as partial. See coverage and freshness.

Findings in test files

Findings in test paths keep their rule ID but are reported at info severity, so a deliberately vulnerable fixture does not count as a critical or high finding.

LLM application rules

AIASM-LLM06-002 fires when an agent is equipped with a shell, code-interpreter, terminal or arbitrary-execution tool. A prompt injection or model error then becomes code execution with the agent’s privileges. Replace general execution tools with narrowly scoped operations, sandbox any execution that remains, and require approval before it runs.

AIASM-LLM10-002 fires on a loop that calls the model repeatedly with no visible iteration limit, budget, deadline or counted exit. Bound every agent loop with a maximum number of iterations, a token or cost budget and a wall-clock deadline.

MCP rules

MCP rules are checked in three places. See Review Model Context Protocol servers for the supported client configuration files and SDKs.

Client configuration

Configuration findings carry the From configuration tag. Inline credential values are redacted in the evidence. AIASM-MCP-021 is also reported from server code that disables certificate verification.

Server code in your repository

AIASM-MCP-007, AIASM-MCP-008, AIASM-MCP-017 and AIASM-MCP-018 are dataflow rules: a finding means a model-supplied tool argument was traced to the sink. The remaining server-code rules are decided by pattern matching or inference and carry the matching tag.

Published packages that a configuration launches

AIASM-MCP-031 uses the advisory’s own severity when one is published.

Third-party MCP package inspection

A configuration such as npx -y some-server or uvx some-server tells the model’s host to download and run third-party code. CodeStax inspects that code without running it.

1. Resolve the package. Launch commands are mapped to a registry package:

   • npm: npx, bunx, pnpx, pnpm dlx, yarn dlx, npm exec, npm x, bun x
   • PyPI: uvx, uv tool run, pipx run

   Servers launched from a local path, a container image or a shell wrapper are not registry packages and are not inspected.

2. Download and verify. CodeStax fetches the pinned version, or the version the registry currently resolves when the configuration is unpinned (which is itself reported by AIASM-MCP-001). It checks the archive against the registry’s published integrity digest. A digest mismatch or a version that does not exist is reported as AIASM-MCP-032.

3. Read without executing. The archive is opened file by file. No package manager, install script or package code runs. Archive entries with absolute paths, .. segments, links or device files are rejected, and downloads and extraction are size-capped.

4. Check the contents. The server-code rules above run over the package, plus install-time scripts (AIASM-MCP-030) and published advisories for the resolved version (AIASM-MCP-031).

Findings are attributed to the configuration file that trusts the server and name the package, version and file. The server’s inventory entry records the ecosystem, whether the version is pinned, whether the integrity check passed, and the tools the package exposes.

Work with rule findings in the dashboard

Open AI Attack Surface → Findings.

1. Type a rule ID such as AIASM-MCP-007 into Search title, rule, or file to list every occurrence of one rule.
2. Use the OWASP filter (for example LLM06 · Excessive agency), the severity filter and the triage-state filter to narrow the list.
3. Open a finding to see its rule ID, OWASP category, confidence, the analysis-method tag, occurrences, first-seen date, location, redacted evidence and remediation.
4. Record a triage decision. See Triage AI-specific findings for the states and who can set them.

To enforce rules rather than review them, configure AI Attack Surface → Policy. See Configure policy.

Related

• AI Attack Surface Management
• AI Bill of Materials
• AI Attack Surface API