Salt Code 공개, AI 코딩 보안 정책을 MCP로 강제

AI 요약

• 무슨 일: Salt Security가 2026년 6월 1일 Salt Code를 공개했습니다.
  • Claude Code, Cursor, GitHub Copilot, Windsurf, Codex, Gemini CLI 같은 AI 코딩 어시스턴트에 보안 정책을 연결합니다.
• 제품 각도: PR 이후 스캔보다 앞선 code generation enforcement를 내세웁니다.
  • Salt는 MCP server configuration을 지원하는 assistant나 code review workflow라면 붙을 수 있다고 설명합니다.
• 개발자 영향: 보안팀 정책이 prompt, MCP, CI/CD, runtime 관측으로 이어지는지 확인해야 합니다.
• 주의점: 정책 주입은 취약점 제거가 아니라 검증 위치를 앞당기는 설계입니다.

2026년 6월 1일 Salt Security는 Salt Code 출시를 발표했습니다. 제품 설명은 명확합니다. Salt는 Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, Codex, Gemini CLI, Antigravity를 지원 대상으로 들었습니다. VS Code, OpenCode, JetBrains처럼 개발자가 쓰는 AI 코딩 도구에 조직의 보안 정책을 연결하고, 코드 생성 시점부터 정책을 적용하겠다는 주장입니다.

이 발표가 단순한 보안 제품 출시보다 넓게 읽히는 이유는 적용 위치입니다. 기존 SAST, DAST, secret scanning은 대개 commit, pull request, CI/CD, 배포 전후에 경고를 냅니다. Salt Code는 제품 페이지에서 "Cursor, Copilot, Claude" 같은 assistant가 코드를 만들 때 정책이 실시간으로 guide한다고 설명합니다. AI가 코드를 쓴 뒤 사람이 고치는 방식에서, AI가 코드 쓰기 전부터 조직 정책을 읽는 방식으로 control point를 옮기려는 시도입니다.

Salt가 겨냥한 문제는 이미 개발팀 안에 들어와 있습니다. Sonar의 2026 State of Code Developer Survey는 전문 개발자 1,100명 이상을 조사했습니다. 이 조사에서 개발자가 commit하는 코드의 42%가 AI-generated 또는 AI-assisted라고 답했습니다. 같은 글은 AI 코딩 도구를 써본 개발자의 72%가 매일 사용하며, AI 생성 코드를 완전히 신뢰하지 않는 비율이 96%라고 적었습니다. 그런데 항상 검증한다고 답한 비율은 48%입니다.

Salt의 발표문은 이 간격을 "policy enforcement lives in PDFs, wikis, and tribal knowledge"라는 문장으로 정리합니다. 보안팀의 표준은 문서와 위키에 있는데, AI 코딩 어시스턴트는 그 문서를 모른 채 API endpoint, MCP integration, auth flow, OpenAPI spec, database query를 생성합니다. 개발자가 "보안도 지켜줘"라고 매번 말하지 않으면, assistant는 조직의 실제 기준보다 공개 코드 패턴과 일반적인 best practice에 기대게 됩니다.

Salt Code의 구조는 여섯 단계로 소개됩니다. 첫째, code repository와 cloud environment에서 API, MCP server, AI agent integration을 찾습니다. 둘째, 생성 단계에서 보안 정책을 assistant의 context로 넣습니다. 셋째, CI/CD와 pull request에서 정책 위반을 검증합니다. 넷째, runtime에서 API, MCP server, agent behavior를 관측합니다. 다섯째, runtime finding을 개발 workflow와 AI assistant로 되돌립니다. 여섯째, 같은 policy model을 code, control plane configuration, runtime behavior에 걸쳐 유지합니다.

기존 접근과 Salt Code의 차이는 검증 위치에서 갈립니다. 코드 생성 전후에는 개발자가 prompt에 보안 요구사항을 직접 넣는 방식이 일반적이었습니다. Salt Code는 정책 pack을 assistant context와 MCP configuration으로 연결한다고 설명합니다. Pull request 단계에서는 SAST, secret scan, reviewer checklist가 뒤늦게 감지합니다. Salt Code는 생성 단계 policy와 같은 기준으로 CI/CD validation을 수행하겠다는 쪽입니다. Runtime에서는 API gateway, WAF, observability 도구가 별도 운영되는 경우가 많습니다. Salt는 API, MCP server, agent behavior를 같은 policy model로 관측한다고 말합니다.

기술적으로 가장 눈에 띄는 연결점은 MCP입니다. Salt는 AI coding assistant나 code review workflow가 MCP server configuration을 지원하면 Salt Code가 붙을 수 있다고 설명합니다. MCP는 assistant가 외부 도구와 context를 호출하는 통로입니다. 보안팀 입장에서는 이 통로가 위험이면서 기회입니다. 위험인 이유는 assistant가 더 많은 권한을 갖기 때문이고, 기회인 이유는 같은 통로를 통해 정책, schema, 검증 규칙, 조직별 금지 패턴을 전달할 수 있기 때문입니다.

Salt Code가 제공한다는 pre-built policy library도 이 지점에 맞춰져 있습니다. 발표문은 OWASP API Top 10, MCP Security Top 10, LLM Security Top 10, OpenAPI/Swagger compliance, common regulatory frameworks, custom organizational policies를 언급합니다. API endpoint를 만드는 assistant라면 authentication, rate limiting, PII handling, TLS, OpenAPI schema가 생성물에 들어가야 합니다. MCP server를 만드는 assistant라면 tool permission, credential boundary, prompt injection handling, audit log가 빠지면 안 됩니다.

Salt의 제품 화면은 registration service의 api.yaml 예시를 보여줍니다. 오른쪽에는 "Authentication via HTTPS", "JWT bearer auth required on external APIs", "Rate limiting enforced on auth endpoints" 같은 항목이 표시됩니다. "No shadow APIs introduced in this PR"도 Compliant로 표시됩니다. 데모 화면만으로 실제 enforce 방식까지 확인할 수는 없지만, 제품이 겨냥하는 객체는 source file 전체가 아니라 생성 중인 API contract와 보안 요구사항의 매칭입니다.

이 접근은 최근 AI 코딩 보안 연구와도 맞닿아 있습니다. Cloud Security Alliance가 2026년 4월 공개한 AI Coding Assistants as Attack Surface research note는 AI coding assistant의 공격면을 code, skills, secrets로 나눴습니다. 이 문서는 Cursor, GitHub Copilot, OpenAI Codex CLI, Claude Code 관련 CVE 사례를 모았습니다. 정리된 공격 유형에는 configuration rewrite, command injection, path restriction bypass, malicious hooks, API key exfiltration이 들어갑니다. 문서 자체가 "Unofficial AI-assisted Research"라고 밝히므로 수치는 보수적으로 읽어야 하지만, 공격면의 분류는 제품 검토 checklist로 쓸 만합니다.

Salt Code의 강점은 보안 정책이 개발자의 기억에만 남지 않게 만든다는 점입니다. AI 코딩 도구를 쓰는 팀에서 가장 약한 고리는 종종 모델 성능이 아닙니다. 어떤 프로젝트에는 보안 header가 필요하고, 어떤 내부 API에는 mTLS가 필요하고, 어떤 repo에는 특정 ORM pattern이 금지되며, 어떤 고객 데이터는 log에 남기면 안 됩니다. 이 기준은 조직마다 다르고, model vendor가 기본 학습으로 알 수 없습니다. Salt식 접근은 이 조직별 차이를 assistant가 부르는 context와 policy pack으로 옮깁니다.

숫자로 보면 검증 병목은 세 갈래입니다. Sonar 조사에서 AI-generated 또는 AI-assisted committed code는 42%입니다. 같은 조사에서 AI-assisted code를 항상 검증한다고 답한 개발자 비율은 48%입니다. Salt Code Early Access는 첫 100개 조직으로 제한됩니다. 이 세 숫자는 AI 코드 생성량, 검증 습관, 새 거버넌스 제품의 초기 접근성을 함께 보여줍니다.

하지만 생성 단계 정책 적용이 만능 방어는 아닙니다. 첫 번째 한계는 policy freshness입니다. OWASP API Top 10이나 LLM Security Top 10처럼 공개된 기준은 시작점일 뿐입니다. 조직의 실제 사고는 특정 cloud account, private package registry, legacy auth service, 내부 data classification에 묶여 있습니다. 이 정책을 누가 작성하고, 누가 승인하고, 언제 rotate하며, 어떤 repo에 적용할지 정하지 않으면 assistant context만 늘어납니다.

두 번째 한계는 enforcement와 suggestion의 차이입니다. AI assistant가 "JWT bearer auth가 필요합니다"라는 policy를 읽고 코드를 고친다고 해도, 실제 PR이 해당 기준을 만족하는지 별도 검증해야 합니다. Salt는 CI/CD validation과 runtime validation을 제품 흐름에 넣었다고 설명합니다. 여기서 확인할 질문은 구체적입니다. 정책 위반 시 assistant 출력이 차단되는지, PR check가 fail하는지, runtime anomaly가 ticket으로 연결되는지, false positive를 누가 triage하는지, developer override가 audit log에 남는지 봐야 합니다.

세 번째 한계는 prompt injection입니다. MCP와 assistant context는 policy를 넣는 통로지만, 공격자가 instruction을 넣는 통로도 됩니다. CSA research note가 언급한 configuration file, hidden Unicode, GitHub Issue context, workspace setting 공격은 모두 assistant가 신뢰한 입력을 이용합니다. Salt Code 같은 제품을 도입하더라도 "policy text가 있다"로 끝나지 않습니다. assistant가 어떤 instruction source를 더 신뢰하는지, tool call approval이 어느 boundary에서 멈추는지, repo file이 policy를 덮어쓸 수 없는지 검증해야 합니다.

네 번째 한계는 vendor coverage입니다. Salt는 Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, Codex, Gemini CLI, Antigravity, VS Code, OpenCode, JetBrains, any MCP client를 나열합니다. 이 목록은 넓지만 각 assistant의 MCP 지원 수준, local/remote execution model, workspace permission, enterprise policy API는 다릅니다. Claude Code의 local file access와 Copilot의 IDE integration, Codex CLI의 shell command path, Cursor의 workspace context는 같은 risk surface가 아닙니다. 보안팀은 "지원됨"을 "동일하게 통제됨"으로 읽으면 안 됩니다.

커뮤니티 반응도 이 점을 건드립니다. 2026년 6월 2일 r/grc에 올라온 금융권 AI coding tool 평가 글은 여러 기준을 들었습니다. SOC 2 Type 2, GDPR documentation, zero data retention, on-premises deployment, exportable audit logs, model training transparency입니다. 한 댓글은 regulated environment에서 좋은 coding assistant는 autocomplete 품질보다 legal, security, audit, procurement 승인을 통과할 수 있는지가 먼저라고 적었습니다. Salt Code 같은 governance layer도 이 조달 질문을 피하지 못합니다.

r/vibecoding의 한 보안 감사 글은 AI-generated SaaS boilerplate에서 hardcoded secrets, tenant isolation failure, misconfigured security headers를 봤다고 주장했습니다. 댓글에는 제품 홍보성 글이라는 지적도 있었지만, "테스트가 통과해도 injection, broken auth, insecure defaults가 남을 수 있다"는 반응도 있었습니다. 이 반응은 Salt Code의 시장 가설과 잘 맞습니다. AI 코딩 보안은 "더 좋은 model을 쓰면 해결"이 아니라 "생성, 테스트, 리뷰, 배포, runtime에서 어떤 검증을 강제하나"로 쪼개집니다.

개발팀이 당장 확인할 항목은 다섯 가지입니다. 첫째, AI coding assistant가 생성하는 산출물 유형을 분류해야 합니다. UI component와 internal script, customer-facing API, auth middleware, payment integration, MCP server는 같은 review rule을 공유할 수 없습니다. 둘째, 조직 보안 정책을 assistant가 읽을 수 있는 machine-readable pack으로 정리해야 합니다. 자연어 wiki만으로는 repo별 적용과 CI/CD fail 조건을 만들기 어렵습니다.

셋째, PR check와 runtime finding이 같은 policy ID를 공유해야 합니다. 예를 들어 API-AUTH-003이 생성 단계에서 assistant에 전달되고, PR에서 validation되고, runtime에서 anonymous access anomaly로 다시 잡힌다면 triage가 빨라집니다. 넷째, override 절차가 필요합니다. 보안팀이 예외를 모두 막으면 개발팀은 우회 경로를 찾습니다. 예외가 필요할 때 approver, expiration, justification, linked ticket을 남겨야 합니다.

다섯째, assistant별 권한 차이를 문서화해야 합니다. Local shell을 실행하는 CLI agent와 IDE 안에서 file edit만 하는 assistant는 서로 다른 boundary를 가집니다. Cloud sandbox에서 PR을 여는 agent와 MCP tool을 호출하는 chat agent도 같은 방식으로 통제할 수 없습니다. Salt Code가 여러 assistant를 지원한다는 설명은 출발점입니다. 실제 운영에서는 assistant별로 allowed tools, network access, credential scope, audit log export, data retention을 따로 확인해야 합니다.

Salt Code의 Early Access는 first 100 organizations로 제한된다고 발표됐습니다. Current Salt Security customers는 기존 license에 포함된다고 합니다. 이 조건은 제품이 아직 market validation을 거치는 단계라는 뜻입니다. 공개된 데모와 발표문만으로 false positive rate, policy authoring UX, assistant별 latency overhead, CI/CD integration 난이도, runtime feedback loop의 실제 자동화 수준은 확인할 수 없습니다.

이번 발표의 실무적 의미는 그래도 선명합니다. AI 코딩 도구가 늘수록 보안팀은 "AI가 쓴 코드를 사람이 더 열심히 리뷰하자"만으로 버티기 어렵습니다. Sonar 조사에서 이미 검증 병목이 드러났고, assistant가 만드는 산출물은 API, MCP server, agent tool, configuration으로 넓어지고 있습니다. Salt Code는 이 병목을 product category로 만든 사례입니다. 보안 정책은 PDF에서 끝나지 않고, assistant context, MCP configuration, PR check, runtime telemetry로 배포돼야 합니다.

좋은 도입 질문은 "Salt Code를 써야 하나"가 아니라 "우리 조직의 AI-generated code policy는 어느 단계에서 실제로 강제되나"입니다. 생성 단계에 없으면 개발자가 prompt로 기억해야 합니다. PR 단계에 없으면 reviewer가 놓칠 수 있습니다. runtime에 없으면 배포 뒤 drift를 모릅니다. Salt Code 발표는 AI 코딩 보안 시장이 이 세 단계를 하나의 control plane으로 묶으려 한다는 사건입니다. 모델 이름보다 policy path가 중요해지는 쪽으로 AI 개발 workflow가 이동하고 있습니다.