How MAGDOX uses AI and secures AI-assisted development
Fix faster with AI, and keep AI-assisted development safe.
Every security vendor now says AI. Here is exactly what ours does: what goes in, what comes out, what never leaves and who decides. Rules find the problems, so results are repeatable. AI helps your developers fix them, and our checks protect you from the new risks AI coding tools bring.
- Finds the issues
- MAGDOX's rules engine
- AI in a hosted scan
- None reads your code
- Training on your data
- Never
- Who decides
- Your reviewers
- AI code in your repos
- Scanned like the rest
Code Security
Your AI coding tools, working from your real findings.
Your developers already ask an AI assistant to write code. Connect it to MAGDOX and the same assistant can work through your security findings with the facts in front of it, instead of guessing from the code alone.
Once an admin allows the scan tools, the assistant can send the code it just wrote to MAGDOX and get back what is vulnerable, where and how to fix it, before anything is committed. It can also list your repositories and findings, read a finding with MAGDOX's guidance, start a scan of a repository connected through the GitHub App and check a package name before installing it. It never ignores or changes a finding. It reaches one organisation, with the access a person approved; every call is audited, and access can be revoked at any time and ends when that person leaves the organisation.
Connect your AI coding toolsGoes in
The code your assistant sends for scanning, plus the findings, MAGDOX's fix guidance, scan status and package names your approved access allows. Your assistant's own provider handles what it reads.
Comes out
What is vulnerable in that code, the file and line, and how to fix it, plus the assistant's explanation and proposed change in your editor or chat.
Who decides
Your developers and reviewers. The pull request is scanned again and checked in your code host before anything merges.
Code Security
Catch what AI agents add to your repository.
A single hidden line in an agent instruction file can turn a helpful agent against you, AI tools regularly suggest packages that do not exist or look like popular ones, and AI features can quietly send customer data to a model provider. Every scan checks for these, and each rule names its OWASP LLM or Agentic Top 10 item.
| Where | What it looks for |
|---|---|
| Agent instructions: CLAUDE.md, AGENTS.md, GEMINI.md, .cursorrules, copilot-instructions.md | Hidden or invisible characters, instructions to fetch and run remote code, instructions to switch off checks or reveal secrets |
| MCP configs: .mcp.json, .cursor/mcp.json, .vscode/mcp.json, Claude settings | Auto-approved tools, unpinned npx -y or uvx servers, plain http servers, secrets in the file, wildcard permissions |
| CI workflows | AI agent steps that run on issues, comments or pull_request_target while holding write tokens or secrets |
| Package names, through a connected AI tool | Names one edit away from a popular package and names AI tools are known to invent |
| Python, JavaScript and TypeScript code that calls AI services | Personal data such as Aadhaar, PAN or phone numbers passed to an AI model call, a logger or an analytics or error tracker |
Code Security
The AI in your code, scanned like the rest of it.
MAGDOX secures your code, and more of that code now calls AI models or runs agents. The same scan checks it in every supported language: untrusted text built into a prompt, model output that reaches a shell, a query or a page, credentials written into prompts, tools that run commands for a model, and models loaded in ways that run their code.
Each finding in that code names its item in the OWASP Top 10 for LLM Applications 2025 or the OWASP Top 10 for Agentic Applications 2026, so your reviewers and auditors see the same reference. 17 of the 20 items have rules; the rest describe the model, its data or the running system, which a code scan cannot show.
| Item | Status | Rules |
|---|---|---|
| LLM01 Prompt Injection | partly detectable | 19 |
| LLM02 Sensitive Information Disclosure | partly detectable | 16 |
| LLM03 Supply Chain | partly detectable | 8 |
| LLM04 Data and Model Poisoning | partly detectable | 6 |
| LLM05 Improper Output Handling | detectable | 24 |
| LLM06 Excessive Agency | partly detectable | 28 |
| LLM07 System Prompt Leakage | partly detectable | 15 |
| LLM08 Vector and Embedding Weaknesses | partly detectable | 19 |
| LLM09 Misinformation | not detectable in code | None |
| LLM10 Unbounded Consumption | partly detectable | 27 |
Code Security
Know which AI services your code sends data to.
Teams add AI features faster than anyone records them. The AI inventory finds the AI services, local models and frameworks your code uses, from OpenAI, Anthropic, Google Gemini and AWS Bedrock to Ollama and LangChain, and marks whether each one sends data to a third party, runs locally or orchestrates other calls.
It tells your privacy and security teams which owners to ask about data handling. A code pattern does not prove what data was sent. Every hosted scan builds the AI inventory, and each run's inventory downloads from the console as JSON or CycloneDX ML-BOM.
Explore the inventoriesWhere AI is not used
The decisions that must be repeatable stay with rules.
A security result you cannot reproduce is hard to defend to an auditor. So the parts that decide what a finding is, and what happens to your code and firmware, do not depend on a model.
| Part of the product | Uses AI? | Why |
|---|---|---|
| Finding issues in code | No: MAGDOX's rules engine | The same code gives the same result, for every customer |
| Hosted scans | No model reads your code | The scan worker has no AI component; your code is deleted after the scan, or within 24 hours if an admin keeps uploads for proofs |
| FDIE firmware analysis | Not used, by design | Deterministic analysis: rules, component evidence and sandboxed execution, with summaries written from templates. The same image and vulnerability data give the same static findings. |
| Your AI coding tools | Yes, your tools | They read the findings their approved access allows |
| Recommendations, fixes, regression tests and proofs | Yes, with your own AI provider | Off until an admin connects it; answers are labelled unverified and never change a finding, and MAGDOX's own guidance is always there |
| Writing MAGDOX's rules | Yes, to help our team | Every rule is tested against fixtures and real repositories, then ships as a plain rule |
Questions
AI questions buyers ask us.
Does MAGDOX use AI to find vulnerabilities?
No. Findings come from MAGDOX's rules engine, the same rules for every customer, so the same code gives the same result every time, and every finding comes with MAGDOX's own recommendation, mitigation and fix guidance. If an admin connects your organisation's own AI provider, your model also writes a recommendation for up to 20 new critical and high findings after each scan and reviews pull requests (on by default; an admin can switch review comments off). On request it explains a finding, judges whether it is a false positive, proposes a fix and writes a regression test. Every AI answer is labelled unverified and never changes or hides a finding: AI informs, people act.
Does an AI model read our code during a hosted scan?
Not during the scan. A hosted scan runs MAGDOX's rules engine in an isolated worker on our servers in India, and the worker contains no AI component. Your code is deleted when the scan ends, unless an admin keeps uploads for proofs, for 24 hours at most. Once an admin connects your organisation's own AI provider, the short excerpt around a finding, with secrets masked, goes to that provider with your key: after each scan for up to 20 new critical and high findings, for the new findings of a pull request while review comments are on, and whenever a person asks for AI help. The provider never receives the whole repository.
Does MAGDOX train AI models on our data?
No. MAGDOX never uses your data, including your code, firmware, findings, files and personal data, to train any artificial intelligence or machine-learning model, whether ours or anyone else's.
Which AI coding tools can connect?
Claude, ChatGPT, Cursor and VS Code, and tools that run on a developer's own computer, such as Claude Code. Each connection is approved by a person with a fresh code from their authenticator, limited to one organisation and recorded in the audit log. They read findings and start scans of repositories connected through the GitHub App; they scan the code they write only when an admin allows it, and they never ignore or change a finding.
Whose AI model is it?
Yours. MAGDOX runs no AI model of its own and charges nothing for AI. An admin connects your organisation's own provider key (Anthropic, OpenAI, Azure OpenAI, Google Gemini, Amazon Bedrock, Mistral AI, Groq, Together AI, DeepSeek, OpenRouter or Fireworks AI, or any other OpenAI-compatible service through the Custom (OpenAI-compatible) provider). MAGDOX lists the models the key can use, and for Anthropic its workspaces; the admin pins one model and sets monthly token and spend caps. MAGDOX checks the key with one small request, stores it encrypted and shows only its last four characters.
Can MAGDOX prove a finding is real?
For Python and JavaScript findings, yes: in a connected repository, and in uploaded code your organisation keeps for proofs, for the number of hours it chooses, up to 24. Your own AI model writes a proof of concept, and MAGDOX runs it against your code in an isolated sandbox with no network. The finding counts as proven only when the exploit reproduces, and a fix counts as verified only when the same proof then stops reproducing. Not reproduced does not mean the code is safe. Your model can also write a regression test for a fix; it counts as verified only when it fails on the current code and passes with the fix in the same sandbox.
Does Code Security check the parts of our code that use AI?
Yes, as part of the normal scan, in every supported language. Code that builds prompts, handles model output, gives tools to an agent or loads a model is checked like any other code, and each finding names its item in the OWASP Top 10 for LLM Applications 2025 or the OWASP Agentic Top 10 2026. Passing a person's text to a model as its own user message is the recommended pattern and is not reported; writing it into the system prompt, the instructions or a prompt template is.
Does FDIE use AI?
FDIE is deterministic by design. It analyses firmware with rules, component evidence and sandboxed execution, and writes its release summaries from templates, so static findings can be reproduced and every finding audited line by line. Firmware is never sent to an AI model. MAGDOX never uses your data, including your code, firmware, findings, files and personal data, to train any artificial intelligence or machine-learning model, whether ours or anyone else's.