Every company has a version of the same thing.
Sometimes it’s a security wiki. Sometimes it’s a Confluence page. Sometimes it’s a PDF nobody wants to update. Sometimes it’s “ask Sarah from AppSec because she knows how we do this here.”
What “it” does is explain how APIs should be authenticated, how sensitive data should be handled, how secrets should be used, which logging patterns are acceptable, and which standards matter for your business, your regulators, and your customers.
Then a developer opens an AI coding assistant and asks it to build something.
The assistant hasn't read any of it.
That’s the gap. And a really big problem.
For years, security teams have tried to solve this by reviewing code after it is written. Scan it in the pipeline. Open a ticket. Send it back to the developer. Wait for the fix. Rinse and repeat.
That model was already painful when humans wrote most of the code.
Today, almost 50% of code is written by AI, and that model has broken.
AI is not just writing code. It is writing the action layer.
In the agentic world, the code AI generates is not just another internal app. It is often the infrastructure that gives agents hands to do things.
APIs. MCP servers. Agent tools. Connectors. Integrations. Workflows.
That AI-generated code becomes the path an agent uses to touch the business.
A developer asks an assistant to build a support tool that can look up orders and issue refunds. The assistant generates an MCP server. The MCP server calls internal APIs. Those APIs touch customer records, payment systems, logistics data, and audit logs.
From the outside, this looks like productivity.
From a security point of view, it is the birth of a new action path and unseen risk.
If that path has weak authorization, hard-coded credentials, missing rate limits, poor logging, or sensitive data flowing through the wrong place, the problem is not theoretical. It becomes part of the agent’s hands.
And once the code is written, reviewed, merged, deployed, and connected to real APIs, fixing the pattern is much harder.
This is the part I think the industry needs to say more clearly:
If your security policy does the moment code is created, it will always be chasing what AI already wrote.
The Security Wiki cannot keep up with the coding assistant.
It’s not because developers are careless. It is because the workflow changed.
A developer used to write code, search internal resources, ask another engineer, read the standard, and copy patterns from existing services. That process had plenty of problems, but at least the human knew there was a company way to do things.
AI coding assistants do not naturally know your company's way.
They know common patterns from the internet. Some are good. Some are outdated. Some are insecure. Some are completely wrong for your environment.
They do not know that your APIs require a specific authorization pattern. They do not know that your company forbids tokens in tool configuration. They do not know that every public endpoint must have an OpenAPI schema, that certain data classes cannot be returned to an agent, or that MCP tools with write permissions require stronger controls.
Unless you bring the policy to the assistant, the assistant will improvise.
And “improvise” is not a security strategy. I’m proud to say our team at Salt has solved this problem.
Today we are launching Salt Code.
The core idea behind Salt Code is simple: security policy should travel with the code from the first prompt.
Not after the pull request.
Not after the SAST finding.
Not after the runtime posture gap.
But from the moment the developer asks the AI assistant to create something.
Salt Code connects our Posture Governance Engine to the coding assistants developers already use: Claude, Cursor, GitHub Copilot, Windsurf, Codex, Gemini CLI, and other MCP-compatible workflows. The Posture Governance Engine is our policy layer where security and compliance standards are defined once, then applied across the lifecycle.
For the developer, it works in the background inside the workflow they already use. For the security team, it means the standard is no longer trapped in a wiki. It becomes part of how code is created.
A developer can ask Cursor to build an MCP server that calls an internal billing API. Salt Code can guide the generated code to follow the enterprise standard: no hard-coded secrets, the right authentication pattern, required authorization checks, OpenAPI documentation, approved logging behavior, and controls for sensitive data. And build the MCP server to policy.
The developer does not need to remember to ask for secure code.
The assistant generates it that way by default.
That is the gap being closed.
Security needs to move from review to creation.
There is still a place for existing code security tools. SAST, DAST, code review, CI/CD checks, and runtime monitoring are not going away.
But if the first time security policy appears is after AI has already generated the code, we are starting too late, and the gap has already grown too wide to close
It is like letting a factory produce thousands of parts all day, then sending someone at the end of the line to throw away the broken ones. You still need inspection at the end. But you also need the machine calibrated before production starts.
Salt Code is about calibrating the machine.
It applies policy when code is generated. It validates the same policy in the pipeline. It uses runtime intelligence to understand how APIs, MCP integrations, and agents actually behave once deployed. And over time, runtime findings can feed back into developer workflows so the next version is better than the last.
That last part matters because agentic security is not a single gate. It is a loop.
Code tells you what was built. Configuration tells you how it is governed. Runtime tells you what happened. The same security standard needs to connect all three.
That is the core idea behind Salt Code: one policy model that follows the agentic system from the code that creates it, to the control plane that governs it, to the runtime behavior that proves what actually happened.
The code is not just code. It’s also future behavior.
If this were only about generating safer code snippets, it would be useful. But agentic systems blur the line between development and runtime.
The code a developer generates today may become an MCP tool tomorrow that’s used by another agent in two days. That MCP tool may call an API next week. That API may give an agent access to customer data, payment flows, account changes, or operational systems.
In other words, the code is not just code. It’s future behavior.
That is why Salt Code is an integral part of our Agentic Security Platform and not a standalone code scanner. The same policies that shape code at creation should govern the APIs and agentic systems that code becomes in production.
This is how we move from “find the issue later” to “prevent the pattern from being created in the first place.”
The time horizon matters.
Every week, an AI coding assistant runs in your environment without policy enforcement is a week of agentic code that no security review ever saw.
Some of that code will be harmless. Some of it will become prototypes. Some of it will quietly become production. And some of it will become the action layer your agents use to touch critical systems.
That is why I believe securing agentic AI starts before the first prompt.
Not because prompt security is unimportant. Not because runtime protection is optional. But because the first prompt a developer gives to an AI coding assistant may become the first version of a tool, API, or MCP server that your agents will rely on later.
If we want agents to act safely, we have to care about what their hands do.
AI is changing how software gets built.
Security policy has to move there too.
Salt Code is available through our Early Access Program to the first 100 organizations, with all four Secure Coding Packs included. You can sign up for your free trial here or join our webinar on June 16th to see a demo of Salt Code.