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.
See plans and usage limitsWhat 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: untrusted input reaching a prompt, sensitive data reaching a provider call, untrusted content reaching a retrieval or training pipeline, and model output reaching code execution or unsafe rendering. Each finding states whether the path was proven 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 declared servers and server code for unpinned versions, install-at-launch commands, credential passthrough, plaintext transports, missing authentication, blanket auto-approval, privileged launch settings, tool descriptions that carry instructions aimed at the model, tools that reach a shell, unrestricted filesystem access, and consequential tools with no approval step.
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.
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.