Cursor에 MCP 서버가 연결되면, 에이전트는 더 이상 텍스트의 소스가 아니라 실행 프로세스가 됩니다. MCP 보안 공식 가이드는 이를 엄격하게 규정합니다: 로컬 서버는 클라이언트와 동일한 권한으로 작동하므로, 권한이 과도하게 부여된 서버나 악성 실행 명령은 ~/.ssh/id_rsa와 같은 파일을 추출할 수 있습니다 (MCP security best-practices, 2026-07-18 기준).

여기서 검증하거나 반박할 수 있는 실무적 명제가 도출됩니다: 만약 MCP 서버가 작업 범위보다 분리할 수 없거나 더 넓은 범위의 비밀(secret)을 사용한다면, 해당 설정은 최소 권한 원칙에 부합하지 않습니다. 이는 'IDE 전체'를 대상으로 검토하는 것이 아니라, 각 서버별로 개별적으로 검토해야 합니다: 어떤 키를 보유하고 있는지, 그 키가 어떤 권한을 갖는지, 소유자는 누구이며 데이터가 어디로 전송되는지를 확인해야 합니다.

다음은 이 네 가지 축에 따른 감사(audit) 분석과 권한 최소화 계획입니다. 이는 에이전트의 오류 발생 시 피해 범위를 줄여주지만, 절대적인 보호를 보장하지는 않습니다. Cursor의 일부 메커니즘은 스스로를 보증(guarantee)이 아닌 '최선의 노력(best-effort)'이라고 명시하고 있습니다.

Cursor가 설정을 저장하는 위치 및 비밀(secret) 전달 방법

Cursor는 두 영역에서 MCP 정의를 읽어옵니다: 프로젝트 단위의 .cursor/mcp.json과 전역(global) 단위의 ~/.cursor/mcp.json입니다. 서버가 두 곳 모두에 정의되어 있는 경우, 프로젝트 정의가 우선합니다 (Cursor docs, 2026-07-18 기준).

Cursor는 mcp.json에 비밀 키(secret)를 절대 하드코딩(hardcode)하지 말라고 권고합니다. 비밀 키를 전달하는 지원되는 방식은 다음과 같습니다: 환경 변수 보간(environment variable interpolation, "${env:VAR}"), stdio 서버를 위한 별도의 .env 파일, 원격 서버를 위한 Authorization: Bearer ${env:TOKEN} 형태의 헤더, 그리고 정적 OAuth 자격 증명(credentials)입니다. 또한,

작성 시점의 문서에 기록된 최소한의 프로젝트 설정은 다음과 같습니다:

{
  "mcpServers": {
    "github": {
...

{
  "mcp": { "allowlist": ["github:*"] }
}

여기서 github:*는 도구 그룹의 이름이 아니라, 문서화된 Cursor 템플릿 형식인 server:* 형태입니다. 에이전트가 실제로 보게 될 도구 세트는 이미 서버 자체 수준에서 --toolsets 플래그를 통해 축소되어 있으며, allowlist(허용 목록)는 단지 이 축소된 세트 내의 도구들을 호출할 수 있도록 허용할 뿐입니다.

「MCP 서버 — 키 — 권한 — 소유자」 매트릭스

Cursor는 이미 설정된 서버가 런타임(runtime)에 어떤 비밀 정보(secrets)를 가져올 수 있는지 보여주지 않습니다. 문서에는 비밀 정보 사용에 대한 내장 로그 기능이 설명되어 있지 않습니다. 따라서 아래의 매트릭스는 제품의 기능이 아니라, 개발자가 직접 채워 넣어야 하는 산출물입니다. 각 행은 서버, 키, 해당 키의 권한, 그리고 소유자라는 네 가지 사실을 연결합니다. 다섯 번째 열은 데이터 경로, 즉 요청이 어디로 전송되는지를 나타냅니다.

다음 중 하나라도 해당되면 해당 행은 검토를 통과하지 못합니다: 키가 다른 것들과 분리되어 있지 않음, 비밀 정보의 소유자가 없음, 권한이 작업 범위보다 넓음, 또는 데이터 경로가 불분명함.

첫 번째 행은 특정 서버의 확인된 기능에 기반합니다. 하단의 두 행은 템플릿이며, 이에 대한 판단은 개발자가 직접 내려야 하며 출처에서 이를 확인해주지 않습니다.

GitHub MCP 서버: 일반적인 표준이 아닌 제한된 키의 예시

GitHub의 공식 MCP 서버는 매트릭스(matrix)가 요구하는 바로 그 분리(separation)를 보여주는 작동 가능한 예시입니다. 이 서버는 OAuth 로그인(토큰이 메모리에만 유지됨), 세분화된 PAT (fine-grained PAT) 또는 클래식 PAT를 지원합니다. --read-only 플래그는 명시적으로 요청되더라도 쓰기(write) 도구를 건너뜁니다. --toolsets/--tools 플래그는 전체 API 표면 대신 repos, issues, actions, code_security와 같이 선택된 도구 그룹만 개방합니다. GitHub 문서는 필요한 권한(repo, read:packages, read:org)만 부여하고 프로젝트와 환경에 별도의 토큰을 사용할 것을 권장합니다 (github/github-mcp-server 참조, 2026-07-18).

이는 하나의 서버 예시일 뿐 일반적인 법칙은 아닙니다. Slack, Postgres 또는 파일 서버가 자격 증명(credentials)을 처리하는 방식은 별도로 확인해야 하며, GitHub의 토큰 모델이 이들에게 그대로 적용되지는 않습니다.

MCP 명세(specification)는 다른 측면에서 이를 뒷받침합니다. 프로토콜 내의 인증(authorization)은 선택 사항입니다. 서버가 이를 구현할 경우 OAuth 2.1 리소스 서버(resource server) 역할을 수행하며 토큰을 검증해야 하지만, 명세는 표준화된 스코프(scope) 이름을 의도적으로 지정하지 않습니다. 키를 얼마나 좁게 제한할 수 있는지는 특정 서버의 작성자가 결정합니다 (MCP authorization spec 참조, 2026-07-18). 따라서 "MCP의 보편적인 스코프 표준"은 존재하지 않습니다. repo나 read:org는 GitHub의 예시일 뿐 프로토콜의 요구 사항이 아닙니다.

보안 가이드에서는 두 가지 규칙을 추가합니다. 서버는 자신을 위해 발행되지 않은 토큰을 수락해서는 안 됩니다. 즉, 토큰 패스스루(token passthrough)는 금지됩니다. 그리고 별도로 "스코프 최소화(scope minimization)"가 있습니다. files:*, db:*, admin:*와 같은 포괄적인(omnibus) 스코프는 피해 범위(radius of blast)를 확장시키고 권한 회수를 어렵게 만듭니다. 권장되는 패턴은 점진적인 최소 권한 원칙(least-privilege)으로, 시작 시에는 최소한의 읽기 전용(read-only) 권한을 부여하고 특정 권한이 필요한 작업에 대해서만 로그를 남기며 권한을 높이는 방식입니다 (MCP security best-practices 참조, 2026-07-18).

Cursor 모델 키와 MCP 서버 키는 서로 다른 비밀 정보입니다

개발자가 "cursor api 키"를 검색할 때, 이는 거의 항상 모델 제공자(model provider)의 키를 의미합니다. 즉, mcp.json이 아니라 AI 연결 설정에 입력하는 키를 말합니다. 또한 "cursor ai api" 역시 채팅과 자동 완성(autocomplete)에서 어떤 모델이 응답하는지에 관한 것이지, 에이전트가 MCP를 통해 호출할 수 있는 도구(tool)에 관한 것이 아닙니다.

이 둘을 구분하는 것은 매우 중요합니다. 왜냐하면 두 키는 피해 범위(radius of damage)가 서로 다르기 때문입니다. 모델 키가 유출되면 토큰(token) 비용이 발생합니다. 반면 MCP 키가 유출되면 에이전트에게 인프라에 대한 쓰기 권한(write-access)을 부여하게 됩니다. 이 둘을 하나의 비밀 정보로 섞거나, 권한 구분 없이 하나의 파일에 나란히 두는 것은 위에서 언급한 매트릭스가 반드시 잡아내야 할 안티패턴(anti-pattern)입니다.

provod.ai가 단순화하는 것과 그렇지 않은 것

"claude를 cursor에 연결하는 방법" 또는 "deepseek를 cursor에 연결하는 방법"과 같은 실질적인 사례는 mcp.json을 수정하는 것이 아니라, 모델 설정에서 base_url과 키 쌍을 변경함으로써 해결됩니다. 이 부분의 작업은 다음과 같이 단순화할 수 있습니다: provod.ai는 플랫폼에서 사용 가능한 모델 카탈로그에 대해 OpenAI 프로토콜과 호환되는 단일 API를 제공합니다. 해당 프로토콜을 지원하는 클라이언트는 base_url과 키를 교체하는 것만으로 연결할 수 있으며, 특정 모델 및 엔드포인트(endpoint)에 대한 실제 지원은 현재 provod.ai 카탈로그 범위 내에서 이루어집니다.

base_url: https://api.provod.ai/v1

보안 주제와 관련하여 적용 가능한 점은, 보호된 러시아 내부망(Russian perimeter)이 외부 모델로 요청을 보내기 전에 직접적인 개인 식별자(PII)를 마스킹(masking)하며, 152-FZ 법률 시나리오를 지원한다는 것입니다. 하지만 이것이 모든 프로세스에 대한 자동적인 준수(compliance) 보증은 아니며, 개발자 측에 완전히 남아 있는 MCP 액세스 권한에 대한 감사(audit)를 대체하는 것도 아닙니다.

키를 제공해도 되는 시점

각 MCP 서버에 대해 다음 네 가지 조건이 모두 충족될 때만 통합을 허용합니다. 그렇지 않다면 키를 제공하기 전에 구성을 보완해야 합니다.

이러한 해결책의 대가는 간단합니다. 개별적인 제한된 비밀값을 발급하고 경로를 확인하는 것이 모든 것에 적용되는 하나의 광범위한 키를 사용하는 것보다 번거롭다는 점입니다. 그 대가로 에이전트의 오류 범위(blast radius)를 제한할 수 있습니다. 모든 서버에 대한 공용 키를 사용하거나 에이전트에게 사용자 수준의 권한을 부여하는 대안은 표의 기준 중 적어도 하나를 위반하기 때문에 거부됩니다.

감사가 끝나는 지점

매트릭스와 최소 권한 원칙은 피해를 줄여주지만, 저장소(repository) 보호를 대체하거나 절대적인 보안을 제공하지는 않습니다. Cursor의 허용 목록(Allowlist)은 최선의 노력(best-effort) 수준에 머물며 프롬프트 인젝션(prompt-injection)에 의해 우회될 수 있습니다. 이는 설정의 정확성 문제가 아니라 메커니즘 자체의 한계입니다. Cursor의 엔터프라이즈 문서에는 터미널 및 도구에 대한 실행 모드(Run Mode: LLM 분류기를 통한 자동 검토(Auto-review), 허용 목록(Allowlist), 모두 실행(Run Everything))가 설명되어 있지만, 특정 MCP 서버가 어떤 비밀값을 볼 수 있는지에 대한 별도의 감사 메커니즘은 제공하지 않습니다. 대신 훅(hooks)과 파일 시스템 권한을 통해 세밀한 제어를 제안합니다 (Cursor 문서 기준, 2026-07-18).

구체적인 검사 없이는 각 서버의 전체 동작을 알 수 없으며, 이는 추측의 근거가 아닌 정직한 미지의 영역입니다. 개별 시나리오는 수동으로 분석해야 합니다. 예를 들어 'Cursor MCP 서버와 1C'의 결합은 본 문서의 출처가 다루지 않는 문제, 즉 해당 서버가 자격 증명(credentials)을 어떻게 유지하고 데이터를 어디로 전송하는지와 같은 문제에 직면하며, 이는 GitHub과의 유사성이 아니라 해당 서버 자체의 문서에서 확인해야 합니다. 또한 이는 OpenCode MCP와의 호환성에 관한 것도 아닙니다. 여기서의 분석은 오직 Cursor의 권한과 키에 국한됩니다.

provod.ai — 하나의 작업 컨텍스트 내에서의 선도적인 비디오 모델들

접근 방식을 비교하고 영상, 예산 및 제작 속도에 맞는 생성기를 선택하세요: 팀은 각 비디오 제공업체(video provider)마다 별도의 잔액을 관리하거나 액세스 권한을 새로 구성할 필요가 없습니다.