[OpenAI][MCP] approval 흐름을 팀 정책과 감사 로그 기준으로 나누는 법

IT 리서치 노트

[OpenAI][MCP] approval 흐름을 팀 정책과 감사 로그 기준으로 나누는 법

MCP 운영이 실제 서비스 단계로 들어가면 핵심은 연결 성공보다 승인 경계다. 2026년 6월 24일 기준 OpenAI 공식 문서는 민감한 action에는 approval을 요구하고, allowed_tools로 tool surface를 좁히라고 반복해서 설명한다. 문제는 많은 팀이 이 설정을 '사용자 편의 옵션' 정도로만 보고, 어떤 action을 승인 대상으로 나눌지 정책과 감사 로그 기준을 따로 문서화하지 않는다는 점이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무 적용 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

먼저 결론부터 말하면, approval 흐름은 tool 이름 기준이 아니라 action 위험도 기준으로 나눠야 한다. read-only 조회는 자동 허용할 수 있지만, 상태 변경이나 외부 전송, 삭제 성격의 tool은 approval과 audit log를 항상 같이 묶는 편이 좋다. 이미 Responses API에 remote MCP 서버를 붙일 때 allowed_tools와 approval을 먼저 줄이는 글을 본 상태라면, 이번 글은 그 설계를 팀 정책 수준으로 끌어올리는 정리다.

또 approval은 MCP 서버 하나마다 따로 노는 규칙이 아니라, 팀 차원의 공통 분류표가 있어야 운영이 편하다. Remote MCP 연결 전에 OAuth와 tool 권한을 확인하는 글처럼 연결 전 권한 점검이 첫 단계라면, 그 다음 단계는 어떤 tool class가 자동 실행되면 안 되는지 합의하는 일이다.

2. 어디서 실제로 막히는가

실무에서는 MCP 서버를 붙이는 순간 도구 수가 생각보다 빨리 늘어난다. 검색, 조회, 수정, 발송, 삭제가 한 서버 안에 같이 들어오는 경우도 많다. 이 상태에서 approval 설정을 뭉뚱그려 두면 두 가지 문제가 생긴다. 너무 넓게 허용하면 민감 action이 자동 실행될 수 있고, 반대로 전부 approval로 묶으면 읽기 전용 작업까지 사람 승인 큐에 몰려 운영이 불편해진다.

또 tool surface를 넓게 열어둔 채 approval만 붙이는 방식은 로그 품질도 나빠진다. 어떤 action이 실제로 위험했고, 어떤 요청이 단순 조회였는지 구분 기준이 섞여 감사 로그가 noisy해진다. 이 경우 사후 분석에서 '모든 tool call을 다 기록했는데도 왜 위험한 실행을 빨리 못 찾았는가'라는 문제가 생긴다.

OpenAI 공식 문서는 allowed_tools와 require_approval를 함께 보라고 한다. 이는 단지 토큰 절약 문제가 아니라, 모델이 선택할 수 있는 action 범위를 애초에 줄이라는 의미다. 위험도 분류가 없으면 모델에게 너무 많은 선택지를 주고, approval도 의미 없이 넓게 쓰게 된다.

• 실패: read, write, delete를 같은 approval 정책으로 묶는다.
• 오해: approval만 켜면 tool surface가 넓어도 괜찮다고 본다.
• 누락: audit log에서 어떤 action class였는지 남기지 않는다.
• 막힘: 읽기 전용 조회도 모두 사람 승인 큐로 몰려 운영 속도가 떨어진다.

상황	먼저 볼 값	실무 판단
조회성 tool이 너무 많다	allowed_tools 범위	현재 작업에 필요한 read-only tool만 노출한다
상태 변경 tool이 섞여 있다	require_approval 분류	write/delete는 always require로 분리한다
감사 로그가 너무 시끄럽다	action class, audit tag	위험도별 로그 보존 수준을 나눈다

3. 실무 적용 순서

가장 실용적인 설계는 네 단계다. 첫째, tool을 read-only, internal write, external side effect 세 등급으로 나눈다. 둘째, 기본 allowed_tools에는 read-only tool만 넣는다. 셋째, write나 delete, 전송 계열은 require_approval 정책으로 분리한다. 넷째, approval이 필요한 tool에는 audit tag와 입력값 요약, 결과 요약을 같이 남기도록 한다. 이렇게 하면 사용자 승인과 감사 로그가 같은 위험도 기준을 공유하게 된다.

1. tool을 read-only / internal write / external side effect로 분류한다.
2. allowed_tools에는 현재 작업에 필요한 read-only 범위만 넣는다.
3. write, delete, send 계열은 require_approval로 항상 묶는다.
4. approval 대상 tool에는 audit tag와 결과 요약을 남긴다.
5. Responses API와 Realtime에서 같은 분류표를 재사용한다.

예를 들어 customer support bot이 지식 검색과 티켓 수정 도구를 동시에 가진다면, 검색은 자동 허용하고 티켓 수정은 approval required로 나누는 식이다. 같은 서버에 있어도 action class가 다르면 경계를 다르게 둬야 한다. 이후 background 저장이나 webhook 후처리가 얽힌다면 Responses API background mode와 webhook 글처럼 비동기 후처리 경계까지 같이 설계하는 편이 낫다.

감사 로그 예시

{
  "tool": "update_ticket",
  "risk_class": "internal_write",
  "approval": "required",
  "audit_tag": "prod-mcp-policy-v3",
  "input_summary": "change priority P2 -> P1",
  "result_summary": "ticket updated"
}

이 정도 구조만 있어도 나중에 승인 요청이 많아졌을 때 '어떤 도구를 자동 허용으로 옮겨도 되는가'를 논의하기 쉬워진다. 반대로 기준 없이 tool 개수만 늘리면 승인과 감사 로그가 모두 시끄러워진다.

특히 음성 에이전트나 Realtime 세션으로 확장한다면 승인 정책 문서만으로는 부족하다. Realtime MCP approval request와 approval response를 이벤트 순서로 처리하는 글처럼 request id와 응답 이벤트를 실제 세션 로그에 남기는 구현 단계까지 같이 설계해야 운영 설명이 맞아진다.

4. 공식 문서와 예시 화면으로 확인하기

가장 먼저 보는 문서는 Tools, Connectors, MCP 가이드다. 여기서 OpenAI가 민감한 action에는 approval을 항상 요구하라고 명시하는 구간을 직접 보는 편이 좋다.

OpenAI MCP 가이드는 민감한 action에는 approval을 항상 요구하고, allowed_tools로 표면적을 좁히라고 권장한다.

즉 approval은 편의 기능이 아니라 보안 경계다. 팀 정책을 세울 때는 '언제 승인할 것인가'보다 '어떤 tool class를 자동 실행하면 안 되는가'를 먼저 정해야 한다.

Realtime MCP 문서도 같은 방향을 반복한다. tool surface를 좁히고, 자동 실행하지 않을 action에는 approval을 요구하라고 적고 있다.

Realtime MCP 문서도 allowed_tools를 좁히고 자동 실행하면 안 되는 action에는 approval을 요구하라고 설명한다.

이 점이 중요하다. Responses API든 Realtime이든 approval 정책은 transport 차이가 아니라 action 위험도 기준으로 설계해야 일관성이 생긴다.

세 번째는 cookbook의 MCP tool guide다. production에서 allowed_tools로 tool 수를 줄이라는 운영 팁이 있어서 승인 범위를 분류하는 데 도움이 된다.

Cookbook 예시는 production에서 allowed_tools를 먼저 줄여 token overhead와 위험 범위를 같이 낮추라고 권장한다.

결국 approval 흐름도 allowed_tools 설계 위에 세워야 한다. 전체 도구를 다 노출한 뒤 approval만 붙이는 구조는 로그도 시끄럽고 운영도 거칠어진다.

실전에서는 위험도별로 approval 정책을 분리한 설정 예시를 갖고 있는 편이 좋다. 그래야 팀마다 민감 action을 어떻게 나눴는지 코드로 남길 수 있다.

위험도별 allowed_tools와 require_approval 분리 예시는 approval 정책을 코드로 남기는 기본 형태다.

이 예시는 read-only 검색과 read-only lookup은 자동 허용하고, write나 delete 성격의 action은 approval을 요구하는 구조다. 중요한 것은 tool 이름보다 action class를 먼저 나누는 것이다.

마지막 자료는 팀 정책과 감사 로그 기준을 묶은 위험도 표다. approval을 어디서 나눌지 회의할 때 이 정도 표가 있으면 기준이 흔들리지 않는다.

read/write/external side effect 기준으로 approval과 audit 수준을 나누면 팀 정책을 문서화하기 쉽다.

이 매트릭스를 기준으로 도구를 분류하면, 동일한 MCP 서버라도 읽기 tool은 auto, 외부 전송이나 변경 tool은 approval required처럼 일관되게 운영할 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 MCP 서버가 신뢰하는 URL이나 이미지 URL을 그대로 받아 실행 흐름에 넣는 것이다. 공식 문서도 tool call output 안의 URL을 신뢰하기 전에 도메인과 출처를 검증하라고 한다. 두 번째 리스크는 approval UI만 있고 audit log가 빈약한 구조다. 승인 여부만 남고 어떤 입력이 어떤 결과를 만들었는지 기록이 없으면 사후 분석이 어렵다.

또 읽기 전용처럼 보이는 tool이라도 외부 비용이나 side effect를 유발할 수 있는 경우가 있다. 예를 들어 검색 API가 과금형이거나 rate limit이 빡센 경우에는 조회 도구도 별도 모드로 분리하는 편이 낫다. 따라서 read-only라는 이름만 보고 자동 허용하지 말고 실제 부수 효과를 같이 봐야 한다.

• tool output URL은 신뢰 도메인 검증 없이 바로 실행하지 않는다.
• approval과 audit log는 같은 위험도 기준을 공유해야 한다.
• read-only처럼 보여도 비용이나 부수 효과가 있으면 별도 분류가 필요하다.

6. 결론

MCP approval 흐름은 사용자 클릭 한 번을 넣는 문제가 아니라, tool 위험도를 코드와 로그로 분류하는 문제다. allowed_tools로 표면적을 먼저 줄이고, write·delete·전송 계열은 approval required와 audit log를 함께 묶어야 팀 정책이 흔들리지 않는다.

• tool 이름보다 action 위험도 기준으로 나눈다.
• allowed_tools와 require_approval를 같이 설계한다.
• approval 대상에는 audit tag와 결과 요약을 남긴다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/tools-connectors-mcp
2. https://developers.openai.com/api/docs/guides/realtime-mcp
3. https://developers.openai.com/cookbook/examples/mcp/mcp_tool_guide