Provider key는 model context, 도구 인수, 도구 결과, URL, 브라우저 코드, log 바깥에 있어야 합니다. MCP server는 별도의 업스트림 자격 증명을 사용하고, 모델에는 권한이 확인된 도구 결과만 전달해야 합니다.
MCP access token도 보호해야 하지만 provider token과는 다릅니다. 이를 업스트림 API로 전달하면 프로토콜이 정의한 대상 경계가 무너집니다.
자격 증명이 유출되는 곳
Prompt와 context
agent가 설정 문제를 진단하려고 .env를 읽은 뒤 그 값을 reasoning, 생성 코드, transcript에 그대로 쓸 수 있습니다. 가능하다면 모델에 노출되는 file tool이 secret store를 읽지 못하게 하세요. process에 자격 증명이 필요하면 모델이 가져오게 하지 말고 해당 process에 직접 주입하세요.
도구 인수와 결과
도구가 업스트림 API를 그대로 본떠 apiKey를 받거나 자격 증명과 debug header가 포함된 provider response를 반환할 수 있습니다. schema에서 secret field 자체를 제거하세요. 서버는 인증된 session state에서 자격 증명을 찾아야 합니다.
URL
Query string은 access log, 브라우저 방문 기록, analytics, error report, screenshot에 나타납니다. MCP 권한 부여 명세는 bearer access token을 Authorization header에 넣도록 요구하며 URI query string에 넣는 것을 금지합니다.
Log와 trace
HTTP middleware가 애플리케이션의 redaction보다 먼저 header와 body를 기록할 수 있습니다. Error tracker가 environment variable, subprocess command, local file을 수집할 수도 있습니다. 수집 경계에서 민감 정보를 제거하고 logger 호출만이 아니라 직렬화된 event를 테스트하세요.
생성된 코드와 artifact
.env가 Git에서 무시되어도 agent가 값을 script, fixture, notebook, screenshot, build output에 하드코딩할 수 있습니다. 배포 전에 빌드된 client bundle과 생성 artifact에서 자격 증명 prefix를 검색하세요.
AI agent 보안 가이드는 MCP 외부까지 포함한 secret 처리를 다룹니다.
두 개의 권한 경계를 사용하세요
flowchart LR
C[MCP client] -->|MCP access token| S[MCP server]
S -->|validated user and policy| P[Tool executor]
P -->|separate upstream credential| U[Provider API]
U -->|bounded result| P
P -->|redacted tool result| C
MCP server는 access token이 자신을 대상으로 발급되었는지 검증합니다. 이어서 그 토큰이 대신하는 사용자와 도구 작업에 권한을 부여합니다. executor는 업스트림 서비스용 자격 증명을 사용합니다. 가능한 경우 업스트림 API가 최종 리소스 권한을 확인합니다.
MCP 명세는 들어온 MCP token을 업스트림 API로 전달하는 것을 명시적으로 금지합니다. 인증 및 권한 부여 가이드는 resource indicator, audience check, 별도의 다운스트림 권한 부여를 설명합니다.
업스트림 자격 증명의 범위를 도구에 맞추세요
도구에 필요한 작업과 리소스만 허용하는 자격 증명을 사용하세요. 읽기 전용 고객 조회가 account administrator key로 실행되면 안 됩니다. provider가 필요한 범위의 자격 증명을 발급할 수 없다면 앞에 범위가 좁은 server-side proxy를 두고 누락된 규칙을 그곳에서 적용하세요.
개발과 production에는 별도의 자격 증명을 사용하세요. production 자격 증명은 coding-agent workspace와 test fixture에 두지 마세요.
Cohesivity 자격 증명은 server-side에 보관하세요
Cohesivity는 tenant 관리용 management key와 provision된 서비스용 application key를 분리합니다. 두 key 모두 server-side 코드에 있어야 합니다. 업스트림 provider 자격 증명은 Cohesivity 내부에 남습니다.
HTTP 애플리케이션에서는 offering이 지원할 경우 application key를 수명이 짧은 edge session token으로 교환한 뒤 그 token을 서버 요청 경로 안에 유지하세요. coh_* 값을 공개 environment variable이나 브라우저 요청에 넣지 마세요.
백엔드 provision 안내는 전체 설정 과정에서 이 분리를 보여 줍니다.
canary로 redaction을 테스트하세요
테스트 환경에서 가짜 자격 증명 형태의 canary를 사용하세요. model input, 도구 실행, 업스트림 실패, 재시도, logging, tracing, error reporting까지 요청을 통과시킨 다음 수집된 모든 artifact에서 canary를 검색합니다.
최소한 다음 항목을 테스트하세요.
- 요청 및 응답 log
- trace attribute 및 event
- error tracker payload
- model transcript
- 생성된 source 및 build output
- shell history 및 process command line
- test snapshot 및 fixture
이 테스트에 실제 자격 증명을 사용하지 마세요.
사고가 발생하기 전에 rotation과 revocation을 설계하세요
자격 증명의 소유자, 범위, 생성 시각, 마지막 사용, rotation 절차, revocation 경로를 기록하세요. rotation 중 구 자격 증명과 신 자격 증명이 겹치는 시간은 배포에 필요한 만큼으로 제한해야 합니다. 자격 증명을 취소하기 위해 사용자의 account나 조직의 모든 integration을 삭제해야 하는 구조는 피하세요.
아래 프롬프트는 값을 출력하지 않고 지정한 자격 증명 하나를 시스템 전체에서 추적합니다.