CodeStax / AI security
AI security. know what AI your code runs, and what it exposes.
Most AI risk enters through code that was written quickly and reviewed lightly. CodeStax reads your repositories to build an AI bill of materials, traces where untrusted input can reach a model and where model output can reach something dangerous, and reports what changed since the last run.
what is AI security?
AI security in the software development lifecycle covers two questions. What AI does this codebase use, including providers, models, frameworks, vector stores, agents, tools and Model Context Protocol servers. And what can go wrong through them: prompt injection, sensitive data leaving your boundary, unsafe handling of model output, over-privileged agents, and vulnerable AI dependencies.
an AI bill of materials, built from evidence
Providers, foundation and embedding models, frameworks, vector databases, guardrails, agents, tools, prompts, application endpoints and Model Context Protocol servers are inventoried with the file, line and evidence that produced each entry. Export it as CycloneDX or SPDX. Coverage gaps are reported rather than presented as an empty inventory.
dataflow evidence, not proximity guesses
For the risks that are dataflow problems, CodeStax traces a path from source to sink in Python, JavaScript and TypeScript, Go and Java: untrusted input reaching a prompt, sensitive data reaching a provider call, untrusted content reaching a retrieval or training pipeline, model output reaching code execution, a query, a request or unsafe rendering, and a model-supplied tool argument reaching a shell, the filesystem, an outbound request or a database. Each finding states whether the path was proven, matched as a pattern, read from configuration or inferred, so a traced path and a nearby pattern are never presented as the same claim.
Model Context Protocol servers are third-party code
An MCP server can invoke tools with your application’s privileges. CodeStax reads the client configurations of the common coding assistants and editors, the server code in your repository, and the published package a configuration launches, which it downloads, digest-verifies and reads without installing or running it. Checks cover unpinned versions, install-at-launch commands and install-time scripts, known vulnerabilities in the server package, credential passthrough and inline credentials, plaintext transports and disabled certificate checks, missing authentication and tokens accepted without validation, blanket auto-approval, privileged launch settings, tool, resource and prompt text that carries instructions aimed at the model, tools that reach a shell, the filesystem, the network or a database from model-supplied arguments, consequential tools with no approval step, missing or permissive input schemas, annotations that contradict the handler, servers exposed without origin validation, weak session identifiers, and elicitation that asks the user for secrets.
your AI dependencies, matched against exploitation data
Resolved AI packages are checked against public vulnerability data and ranked by exploitation signal first: whether the vulnerability is in the known-exploited catalogue, then its estimated probability of exploitation, then severity. Dependencies with an unresolved version constraint are excluded rather than reported clean.
changes to your AI stack, reported when they happen
A new provider, a model that stopped being pinned, an MCP server someone added, a dependency that became exploitable: each is recorded against the previous verified run and delivered to your webhooks and administrators. The first run of a repository sets the baseline instead of reporting the whole inventory as new.
policy that applies to AI specifically
Restrict which providers are permitted, deny particular models, require pinned model revisions, require approved assets, and fail a run when coverage is incomplete. Policy results participate in the same quality gate as the rest of the platform.
measured, not asserted
Detection precision and recall for every AI and MCP rule are measured nightly against labelled corpora, including a vulnerable-by-design MCP server suite, with the product’s own configuration rather than a vanilla engine. The per-rule results are visible to administrators, so a rule that misses or over-reports is a number, not a surprise.
what this cannot prove
CodeStax analyses code and configuration. It does not observe production traffic, so it cannot prove that a specific prompt injection succeeds against your deployed system, that a flagged path executes, or that an inventory is exhaustive. Where dataflow analysis did not run, findings are labelled as inferred rather than proven, and incomplete coverage is reported instead of being presented as a clean result. Use it to find and fix exposed paths before deployment, alongside the runtime controls you operate.
common questions
What is an AI bill of materials (AI-BOM)?
An AI-BOM is an inventory of the AI components a system depends on: providers, models, frameworks, vector stores, agents, tools and the servers that expose them. CodeStax builds one from repository evidence and exports it in CycloneDX or SPDX. An inventory supports a review; it does not certify compliance.
Can CodeStax detect prompt injection?
CodeStax reports where untrusted input can reach a prompt without a visible guard, and states whether that path was traced by dataflow analysis or inferred from a pattern. Static analysis identifies exposed paths; it cannot prove that a specific injection succeeds against your deployed system.
How is this different from scanning dependencies?
Dependency scanning answers whether a package has a known vulnerability. AI security also answers which AI the code uses, how untrusted data reaches it, what the model can do once it answers, and which of those paths changed. The two are complementary and run in the same scan.
What is shadow AI, and how does discovery help?
Shadow AI is AI usage that governance does not know about: a provider added in a side project, a model called from a script, an MCP server added to a developer configuration. Repository-level discovery surfaces it with file-level evidence so it can be reviewed rather than found later.
Does this replace runtime AI monitoring?
No. CodeStax analyses code and configuration. It does not observe production traffic, so it cannot confirm which paths execute or what a model returned in a real request. Use it to find and fix exposed paths before deployment, alongside whatever runtime controls you operate.
Your next step
evaluate with your own repository.
Review the findings, test the workflow, and decide with evidence.