Coverage
Code Security
Shift AI security left, into the pull request
Most AI risk is decided at build time — how a prompt is assembled, what a tool is allowed to do, whether output is validated before it reaches a shell. SAF3AI scans for the patterns that only show up in code that talks to a model, and returns SARIF so the findings land where your developers already work.
What you see
The telemetry we pull
AI-specific code weaknesses
Unvalidated prompt construction, unsafe tool registration, missing output handling and the other patterns that only appear in code that calls a model.
Hardcoded secrets
Credentials in source, matched by provider signature — AWS, GitHub, Slack, Stripe, OpenAI, Twilio, JWT and PEM — with entropy analysis as the fallback for generic tokens.
Agent and tool definitions
Which agents, tools and MCP servers a repository declares, extracted from the code itself so the inventory is grounded in what will actually deploy.
Model and provider usage
Which SDKs, models and providers the codebase calls, which is where model-supply-chain questions get concrete answers.
Dependency and supply chain
AI libraries and their versions, including the ones pulled in transitively that nobody chose deliberately.
Findings as SARIF
Line-level results in a standard format, so they land in GitHub code scanning, your IDE and your existing triage flow rather than a separate console.
How it connects
From zero to first signal
- 1
Scan from the CLI
Run saf3ai sast scan against a local directory or a repository URL. The directory is archived client-side and uploaded; nothing needs to be checked in.
- 2
Gate the build
The CLI exits non-zero when findings meet your --fail-on threshold, so a pull request that introduces a hardcoded key or an unsafe tool definition does not merge.
- 3
Surface it in the IDE
The VS Code extension runs the same CLI and renders findings as diagnostics, so developers see the issue where they wrote it rather than in a report a week later.
- 4
Feed the graph
Agents, tools and models found in code become graph entities, so posture from source lines up with what runtime telemetry later observes.
The CLI is the single engine — the IDE extension and CI action both invoke it, so a finding in your editor and a finding in the pipeline are produced by identical logic.
What it catches
Risks specific to this surface
Secrets committed to source
Validated by provider signature rather than pattern guessing, so the findings are worth acting on instead of tuning out.
Unsafe tool registration
Tools exposed to an agent with broader capability than the task requires — the code-level origin of most excessive-agency findings.
Prompt built by string concatenation
User input spliced directly into a prompt with no separation, which is prompt injection waiting for its first adversarial user.
Unvalidated model output
Model responses passed to a shell, a query or a renderer without checking — the AI-era version of injection.
Vulnerable AI dependencies
Known-bad versions of AI libraries, including the transitive ones nobody deliberately added.
Drift between code and runtime
An agent whose deployed capability no longer matches what the repository declares, visible only when both are in the same graph.
See Code Security in your own tenant
Connect this surface in a pilot and get a mapped inventory, a scored risk list and the attack paths that actually reach your data.