AI Code Security & Supply Chain
Last verified: October 2026· engagement
We audit AI-generated code for vulnerabilities, license violations, prompt-injection vectors, and data leakage, then set up policy and automated scanning in your CI.
- Outcome
- A security report + scanning infra in CI
- Timeline
- 3–5 weeks
- Pricing
- $20–50k audit, $5–12k/mo monitoring
- Buyer
- CISO, VP Eng
The problem
AI is writing code faster than anyone can review it. Hallucinated APIs, subtle vulnerabilities, secrets in prompts, and license violations are entering your repos daily. Traditional AppSec tooling misses the new failure modes — and your team is moving too fast for manual review alone.
What we do
- AI-aware static analysis in CI: hallucinated packages, missing tests, license violations, secret leakage.
- A prompt-data gateway that redacts PII / secrets before requests hit the model and audit-logs every prompt.
- MCP-server hardening: least-privilege credentials, read-only defaults, audit logs, human-in-the-loop on destructive tools.
- Mapping of new prompt-injection surfaces (agents that read external content and call tools) and mitigations.
How it fits together
What you get
Built on our open source
agentvfs — A workspace runtime and execution boundary for AI agents — guardrails on what an agent can touch.
The failure modes traditional AppSec tooling misses
Existing scanners are good at the vulnerability classes they were written for, and AI-generated code introduces some they were not. Hallucinated dependencies are the clearest example: a model confidently imports a package that does not exist, and the risk is not the broken build — the build failing is the good outcome — but that the name is plausible enough for someone else to register it. Any control here has to operate on whether a dependency existed and was trusted before the model suggested it, which is a provenance question rather than a code-analysis one.
License exposure is the second gap. Generated code can reproduce patterns from training data closely enough to raise questions that your existing license scanning, which reads dependency manifests, will never see because there is no manifest entry to read. The practical control is policy plus review on the surfaces where it matters commercially, rather than a tool that claims to detect provenance in a snippet.
The third is the prompt data path, which is usually nobody's responsibility. Source code, customer records, and occasionally credentials flow out through prompts to model providers, and through traces into observability stores that are far more widely readable inside most companies than the databases the data came from. We treat that as a gateway problem: one place where redaction, allowed destinations, and retention are enforced, rather than a policy document asking engineers to be careful. Then indirect prompt injection, where content an agent retrieves carries instructions, which is a real and under-controlled surface as soon as agents can both read external content and call tools.
When this is not the right engagement
Security work needs authority behind it to be worth buying. It is a poor fit when:
- You have no AI-generated code or agent tooling in the estate yet. Come back when there is something to secure.
- You want a compliance certificate. We produce findings, controls and scanning in CI; certification is somebody else's product.
- Security has no authority to change how engineering works. Scanning that nobody is empowered to act on becomes a queue nobody reads.
Common questions about this engagement
Do you work under NDA?
Yes — we sign your mutual NDA before any data or repo access. For audits we prefer read-only access to start; for builds we work in a clean repo under your ownership.
Will we own what you ship?
Always. You own the code, the runbooks, the dashboards. We are explicitly set up to hand off and transition out, not to create dependency.
Vendor-agnostic — what does that mean in practice?
We integrate with what you already run — OpenAI, Anthropic, open-weight models on your cloud, your CI/CD, your observability stack. If a hosted vendor solves it, we will not reinvent it; if a self-hosted tool is the right answer, we will not pretend the hosted one is.
How is this different from a Big Four consulting deck?
We are the engineers doing the work, not analysts handing recommendations to a different team. The deliverable is working software in your repo, not a slide deck.
Can you work with our in-house AI team instead of replacing them?
Yes — most of our engagements pair with an internal owner and ramp them up to run the system after we leave. Many of our best engagements start with "we hired an AI team, help us get them productive."
Which of these risks is genuinely new?
Three. Dependency provenance, because a model can suggest a package that never existed and the risk is that the plausible name gets registered by someone else. The prompt data path, because source code and customer records leave through prompts and then sit in trace stores that are far more widely readable than the databases the data came from. And indirect prompt injection, which has no complete technical fix. Insecure generated code is a familiar problem arriving at unfamiliar volume, which is a process risk rather than a new vulnerability class.
Can you stop prompt injection?
Not with prompting, and anyone who says otherwise is selling something. Models cannot reliably distinguish instructions from data in the same context, and phrase detection is defeated by rephrasing. What works is architectural: least privilege on every tool, read-only by default, human approval on anything irreversible, egress restrictions so a compromised turn cannot reach an arbitrary destination, and audit logging. We design for the blast radius rather than for the attack, because the blast radius is the part you control.
Guides for this work
How to choose an MCP server development company
The MCP SDK is a weekend's work; the job you're actually hiring for is least-privilege auth, scoping, audit logging, and production hardening on servers that reach straight into your internal systems.
Agentic codingIs your codebase ready for AI agents?
Agents don't fail randomly on a repo — they fail predictably on the same things that slow down human engineers: fuzzy boundaries, missing tests, undocumented conventions. Readiness is just those weaknesses paid down deliberately.
Let’s scope it on a call
Thirty minutes with an engineer. We’ll tell you straight whether this is the right first move for your team.