Salt Code brings 40 security policies into AI coding assistants through MCP
Salt Code connects security policy packs to AI coding assistants through MCP, moving checks from PR review into code generation, MCP configuration, and runtime behavior.
- What happened: Salt Security announced
Salt Code, a product that applies security policies inside AI coding assistants.- The product page lists 4 secure coding packs, 40+ policies, support for 10+ assistants, and a free early-access path for the first 100 organizations.
- How it works: Salt Code connects as an
MCPserver to tools such as Cursor, Copilot, Claude, Codex, and Gemini CLI. - Why it matters: AI coding security is moving from after-the-fact PR checks toward prompt-time policy, MCP configuration, and runtime validation.
- The claim to test is whether policy-compliant code by default lowers exceptions, review churn, and CI failures in real repositories.
Salt Security announced Salt Code on June 1, 2026. At first glance it looks like another AI security product release, but the product's placement is the interesting part. Salt Code is not described as a tool that waits until an AI coding assistant has generated a pull request and then scans the diff. It connects to developer tools such as Cursor, GitHub Copilot, Claude, Codex, and Gemini CLI through an MCP server, then applies security policy while code is being generated.
Salt's press release introduces Salt Code as a new component of its Agentic Security Platform. The covered surface is split into three areas: generated code, control-plane configuration such as MCP servers and registered agent tools, and runtime behavior from APIs, MCP integrations, and agents in production. That attempt to bind code generation, agent configuration, and live behavior into one policy model is the product's clearest differentiation.
The product-page numbers are specific. The free starter account includes four ready-to-use secure coding packs: OWASP API Top 10, MCP Security Top 10, LLM Security Top 10, and OpenAPI/Swagger Compliance. Salt says those packs contain more than 40 policies and work with Cursor, Copilot, Claude, and any MCP-enabled assistant. Non-customers can apply for an Early Access Program that is free for the first 100 organizations.
Salt chose MCP as the connection layer. In the official description, a developer adds Salt Code to Cursor, GitHub Copilot, Claude, or another AI coding assistant as an MCP server, enables one or more security packs, and keeps prompting in the normal coding flow. Salt's promised result is that "output arrives policy-compliant." That phrase should be treated as a vendor claim, but the control point is clear. Instead of appearing as a pull-request comment or a CI failure after the code exists, the policy enters the model's working context at generation time.
That placement has become more important as AI coding tools have moved from autocomplete toward agentic workflows. Copilot, Claude Code, Codex, Cursor, Windsurf, and Gemini CLI can read files, run tests, propose commands, and sometimes prepare pull requests. As human review moves later in the workflow, security teams have to ask less about which assistant produced a given function and more about which permissions, tools, and policies that assistant could see while acting. Salt Code tries to answer that question through MCP configuration and policy packs.
The security backdrop in Salt's release points in the same direction. Salt cites Georgia Tech's Vibe Security Radar and says 35 CVEs tied to AI coding tools were disclosed in March 2026. Infosecurity Magazine reported the same tracking project on March 26, 2026, noting monthly counts of 6 in January, 15 in February, and 35 in March. The public Vibe Security Radar page, checked for the Korean article on June 1, showed 78 AI-linked CVEs, 8 AI tools, 43 critical or high-severity cases, and 46,831 advisory scans.
Those numbers should be kept separate from Salt Code's sales argument. Vibe Security Radar is not simply claiming that all AI-generated code is dangerous. It tracks vulnerability causes through metadata, commit signatures, issue threads, and tool traces left by AI-generated code. A rising count could reflect more AI-caused defects, wider AI tool adoption, better attribution, or some combination of all three. For security teams, each explanation creates the same operational pressure: as code generation accelerates, a single human review checkpoint becomes too weak as the primary policy boundary.
The four packs Salt lists are useful because they show the policy categories rather than only the supported tools. The OWASP API Top 10 pack targets generated API code, including risks such as broken authorization, unrestricted resource consumption, and SSRF. The MCP Security Top 10 pack covers agent connection points such as MCP server authentication, tool description validation, and least-privilege scopes. The LLM Security Top 10 pack focuses on prompt injection, sensitive-information disclosure, and excessive agency. The OpenAPI/Swagger Compliance pack asks for authentication schemes, response codes, and schema documentation during generation.
| Policy pack | Generated artifact Salt targets | What engineering teams should verify |
|---|---|---|
| OWASP API Top 10 | API endpoints, auth guards, rate limits, and SSRF defenses | Whether violations fall before PR review, and whether the pack duplicates existing SAST checks |
| MCP Security Top 10 | MCP server config, tool registration, and scope definitions | Whether it catches tool-description prompt injection and overly broad scopes |
| LLM Security Top 10 | User-input handling, sensitive-data protection, and agent action limits | Whether policy outcomes stay consistent across different models and assistants |
| OpenAPI / Swagger | OpenAPI schemas, response codes, and authentication-scheme documentation | Whether documentation drifts less from the actual handlers |
In this architecture, MCP is more than a plugin format. Salt's press release describes MCP as an open protocol that lets AI assistants connect to external context and tools. That definition maps directly to the daily security problem in agentic development. Once an assistant can read a repository, ticket, database schema, internal API, secret scanner, or CI log, the review target is no longer a single generated .ts file. It is the whole connection list. Salt Code's separate MCP Security Top 10 pack exists because that connection layer is now part of the application security surface.
Salt Code is better read as a complement to existing security tools than as a replacement. Secret scanning in GitHub Advanced Security, SAST from Snyk or Semgrep, Checkmarx code scanning, and CI policy gates still matter. Salt is trying to move the first failure point. If a developer asks an AI assistant to create an API endpoint and missing authentication, absent response codes, or an overly broad tool scope can be corrected in that moment, the pull-request review burden falls. If Salt Code only converts the same problems into later tickets, it becomes another queue in the security backlog.
Salt also says the same policy model extends into runtime. The press release mentions integrations with GitHub, GitLab, Bitbucket, VS Code, IDEs that support MCP configuration, major CI/CD platforms, Jira, and ServiceNow. The strongest version of the product is not a dashboard that aggregates unrelated alerts. It is a loop where a runtime policy violation on an API can feed back into the next code-generation prompt and constrain the proposed fix. That would give real substance to Salt's runtime-to-code remediation language.
Engineering teams evaluating the product should start with three questions. First, when Salt Code connects as an MCP server, what repository, branch, prompt, and tool-call metadata does it read? Second, does a policy violation block generation, warn the developer, or ask the model to regenerate? Third, if one team uses Cursor, Codex, Claude Code, and Copilot at the same time, do the same policies produce equivalent results? AI coding-assistant security will be shaped less by benchmark scores and more by permissions, logs, exception approval, and audit trails.
Public community reaction to Salt Code itself was still thin at launch. The Korean article checked the Hacker News front page on June 1, 2026 and did not find a Salt Code discussion. However, PromptArmor's "ChatGPT for Google Sheets exfiltrates workbooks" item was visible with 252 points and 97 comments, showing that developers were paying attention to data-exfiltration paths created when AI tools connect to work files. On GeekNews, a May 31 item about "Claw Patrol - a security firewall for agents" covered agent credentials and traffic parsing.
Those adjacent discussions help frame where Salt Code sits. The PromptArmor case showed how prompt injection can affect both a user interface and access to work data. Claw Patrol-style products try to control agent credentials and wire-level traffic at runtime. Salt Code is positioned earlier, at code generation and MCP configuration time. Under the same "agent security" label, the buyer and operator can change with the control point: platform engineering owns IDE and MCP rollout, AppSec owns policy packs and CI results, and security operations owns runtime alerts.
The practical validation bar for Salt Code is straightforward. False positives have to stay low. If policies interrupt the coding assistant too often, developers will disable the MCP server or move to a looser tool. Custom-policy authoring has to be cheap. Salt's 40-plus default policies are only a starting point, because real companies need internal authentication middleware rules, company-specific logging requirements, API versioning conventions, and PII masking policies. Policy results also need stable IDs and explanations across PRs, tickets, and runtime logs so teams can trace the same issue through the workflow.
The "40 policies" in the title is not proof of product value on its own. Its meaning is that security teams are beginning to treat AI coding tools as something to govern through deployable policy packs rather than through broad prohibition. Until recently, many AI coding guidelines were written as static documents: do not paste secrets, review generated code, test before production. Salt Code turns that kind of guidance into an MCP server and policy engine.
For buyers, the remaining question is less about list price than operating boundary. Salt says non-customers can use a free Early Access Program and that existing Salt customers get Salt Code included in their licenses. The operational cost sits elsewhere: exception approval, policy writing, assistant-specific rollout, developer education, and log retention. Central policy becomes more valuable as teams adopt more assistants, but that also exposes differences in each tool's MCP implementation and permission model.
Salt Code is a useful marker for where AI coding security is moving. The question is no longer only whether AI-generated code can be scanned after it lands in a branch. The harder question is what policies an assistant sees while it writes code, registers tools, and responds to runtime findings. Vibe Security Radar's CVE tracking, PromptArmor's data-exfiltration example, and developer interest in agent firewalls all point at the same pressure. Development teams have accepted faster code generation. Security teams now have to move controls to the places where that speed is created.