AI 에이전트의 워크스페이스 접근 범위를 정하는 법

AI 에이전트의 접근 범위는 새로 온 외주 인력에게 주듯이 정하세요. 필요한 몇몇 영역에만 읽기 권한을 주고, 특정 작업이 필요로 할 때 쓰기 스코프를 하나씩 추가하고, 토큰이 만든 사람보다 더 많은 일을 절대 할 수 없게 하고, 무엇을 건드렸는지 볼 수 있도록 모든 호출을 기록합니다. MCP 용어로는 동의 화면에서 고르는 OAuth 2.1 스코프, 에이전트가 그 밖으로 나갈 때의 403, 그리고 서버의 감사 로그입니다.

이 글은 Atrix에서 자체 에이전트에 쓰는 레시피입니다. 표준 쪽은 MCP 인가 명세에서, 제품 쪽은 2026년 10월 기준 부여 가능한 스코프 49개를 가진 우리 서버에서 가져왔습니다.

에이전트 권한이 사용자 권한과 다른 이유

사람은 행동하기 전에 화면을 읽습니다. 에이전트는 도구 설명을 읽고 밀리초 안에, 한 시간에 수백 번, 웹 페이지나 이메일이나 회사 밖 사람이 쓴 티켓에서 온 텍스트를 바탕으로 행동합니다. 프롬프트 인젝션이 흔한 예지만, 평범한 실수가 더 자주 일어납니다. "오래된 이슈 정리해"라는 요청을 받은 에이전트가 "정리"를 "삭제"로 해석하는 식입니다.

두 가지 결과가 따라옵니다. 첫째, 잘못된 행동의 피해 범위는 토큰이 할 수 있는 일로만 제한되므로 토큰은 작아야 합니다. 둘째, 각 행동을 미리 검토할 수 없으므로 사후에 검토할 수 있을 만큼 좋은 로그가 필요합니다.

사용자 권한은 "이 사람이 무엇을 보고 바꿀 수 있는가"에 답합니다. 에이전트 권한은 "이 프로그램이 이 사람을 대신해, 이 작업을 위해, 이번 주에 무엇을 해도 되는가"에 답합니다. 두 번째 질문의 답이 더 좁습니다.

MCP 인가 명세가 제공하는 것

Model Context Protocol의 인가 명세(2025-06-18 개정판, 2026년 10월 기준 현행)는 MCP 서버를 OAuth 2.1 리소스 서버로, MCP 클라이언트를 OAuth 2.1 클라이언트로 다룹니다. 범위 설정에 중요한 부분은 다음과 같습니다.

요구사항	당신에게 의미하는 것
서버는 Protected Resource Metadata(RFC 9728)를 게시하고 `WWW-Authenticate` 포인터와 함께 401로 응답해야 한다	클라이언트가 인가 서버를 스스로 찾는다. 아무도 설정 파일에 토큰을 붙여 넣지 않는다
클라이언트는 PKCE를 써야 하고 동적 클라이언트 등록(RFC 7591)을 지원하는 것이 좋다	에이전트 호스트가 스스로 등록하고 브라우저 동의 흐름을 실행한다
클라이언트는 `resource` 파라미터(RFC 8707)를 보내야 하고 서버는 토큰의 대상을 검증해야 한다	한 서버용으로 발급된 토큰을 다른 서버에 재사용할 수 없다
토큰이 없거나 무효면 401, 스코프가 무효이거나 권한이 부족하면 403	스코프 실패가 명시적이어서 에이전트가 "허용 안 됨"과 "로그인 안 됨"을 구분한다
인가 서버는 단기 액세스 토큰을 발급하는 것이 좋고 공개 클라이언트의 리프레시 토큰은 교체해야 한다	유출된 토큰은 만료되고, 도난당한 리프레시 토큰은 다음 사용 때 잡힌다
토큰 패스스루는 금지	서버는 당신의 토큰을 하위 API로 전달할 수 없다

명세는 스코프의 이름과 세분화 수준을 일부러 각 서버에 맡깁니다. 메커니즘(동의, 대상, 403)을 주고 정책은 당신에게 맡깁니다. 이 글의 나머지가 그 정책입니다.

레시피: 읽기부터, 쓰기마다 넓히기, 사람을 넘지 않기

우리가 적용하는 순서대로 다섯 가지 규칙입니다.

작업이 건드리는 영역의 읽기 스코프만으로 시작한다. 주간 상태를 초안하는 에이전트는 이슈, 목표, 피드를 읽어야 합니다. 고객, 급여, 채용은 읽을 필요가 없습니다. 읽기 스코프 서너 개를 고르고 멈추세요.
이름이 있는 작업이 필요로 할 때만, 그 하나만 쓰기 스코프를 추가한다. "구현한 이슈에 댓글 달기"에는 이슈 쓰기가 필요합니다. 프로젝트 쓰기, 페이지 쓰기, 팀 피드에 게시하는 능력은 필요 없습니다. 쓰기 스코프가 읽기를 포함하는 것은 괜찮지만, 그 반대는 결코 성립하지 않습니다.
파괴적이고 외부로 향하는 행동은 별도 부여로 다룬다. 삭제, 게시, 이메일 발송, 알림 게시는 되돌릴 수 없는 행동입니다. 각자의 스코프 뒤에 두고, 가능하면 사람이 보는 확인 뒤에 두세요.
토큰은 발급한 사람을 절대 넘어서면 안 된다. 에이전트 토큰이 소유자가 못 읽는 것을 읽을 수 있다면 스코프는 권한 상승 수단이 된 것입니다. 소유자의 권한을 발급 시점이 아니라 호출마다 확인해, 소유자의 접근을 폐기하면 에이전트의 접근도 폐기되게 하세요.
모든 호출을 감사하고, 감사 기록을 읽는다. 도구 이름, 결과, 건드린 대상의 종류와 id. 내용은 아닙니다. 고객 데이터로 가득한 감사 로그는 두 번째 유출 사고가 되기를 기다리는 것입니다.

피해야 할 실패 양상은 "모두 연결" 동의 화면입니다. 에이전트 호스트가 모든 스코프를 한 번에 요청하고, 목록이 길어서 사람이 그냥 승인을 누릅니다. 짧은 목록은 읽힙니다.

실제 사례: Atrix AI의 스코프 49개

Atrix의 MCP 서버는 우리가 운영하는 것이라 솔직하게 말할 수 있는 사례입니다. 2026년 10월 기준 개발자 문서에 나열된 부여 가능한 스코프 49개 뒤에 도구 85개가 있습니다. 설계 선택은 위 규칙과 대응합니다.

영역별 읽기·쓰기 쌍: work.read, work.write, crm.read, crm.write, pages.read, pages.write 등. 쓰기 스코프는 읽기를 포함하고, 그 외에는 아무것도 암묵적으로 포함되지 않습니다.
되돌릴 수 없거나 외부로 향하는 행동에는 이름 있는 스코프: destructive, publish, email.send, feed.post. 쓰기 스코프가 이를 암묵적으로 포함하는 일은 없습니다. feed.post가 feed.write와 분리된 이유는 게시가 거부 옵션 없이 사람들의 휴대폰에 알림을 보내기 때문입니다.
아홉 개 스코프는 토큰 뒤 계정에 해당 권한도 요구한다: 거래 금액, 고용 기록, 계약, 채용, 통합, 결제, 청구서, 제품 변경. 권한은 호출마다 확인되므로 토큰은 만든 사람보다 많은 일을 할 수 없고, 누군가의 접근을 폐기하면 그 사람의 토큰이 미치는 범위도 즉시 사라집니다.
급여는 아예 부여할 수 없다. 급여에 닿는 스코프가 없고 보상 기록을 선택하는 도구도 없습니다. 어떤 데이터는 에이전트에서 동의 클릭 한 번 거리에 있어서는 안 되며, 그것을 보장하는 방법은 스코프 목록에서 빼는 것입니다.
제한과 감사: 토큰당 분당 120회 호출과 30회 쓰기. 모든 호출은 도구, 결과, 대상 종류와 id로 기록되고 내용은 기록되지 않습니다.

이 설계의 비용: Claude나 Cursor를 연결하는 팀원은 스코프 선택기를 보고 30초쯤 생각해야 합니다. 비교하자면 Linear 서버는 별도의 읽기 전용 URL을 제공하는데, "읽기만"을 표현하는 더 단순한 방법입니다. 두 접근 모두 작동합니다. 우리는 결정을 사람에게, Linear는 URL에 둡니다.

스텝업: 작업이 요구할 때 넓히기, 그 전에는 말고

쓰기 스코프를 처음부터 부여하는 것의 대안은 스텝업 인가입니다. 에이전트는 읽기로 실행되다가 첫 쓰기에서 403을 받고, 호스트가 그 세션을 위한 추가 스코프 승인을 사람에게 요청합니다. 스텝업 인가 용어집 항목이 이 패턴을 설명하며, 명세는 403과 새 동의 라운드를 통해 이를 지원합니다.

실제로는 이렇게 작동합니다. 에이전트가 상태 보고서를 초안합니다(읽기만). 당신이 초안을 승인합니다. 에이전트가 게시를 위해 feed.post를 요청합니다. 그 토큰에 부여하거나, 초안을 직접 게시합니다. 쓰기 스코프는 작업이 필요로 하는 동안만 존재합니다.

스텝업은 첫날에는 넓은 부여보다 느리고 둘째 날부터는 빠릅니다. 작업이 안정되면 에이전트가 획득한 스코프 집합이 더 늘지 않기 때문입니다.

보안 정책에 붙여 넣을 수 있는 체크리스트

에이전트는 호스트의 동의 흐름을 통해 OAuth 2.1로 인증한다. CI를 제외하면 설정 파일에 장기 키를 두지 않는다.
각 에이전트 토큰은 스코프, 소유자, 생성일, 마지막 사용일을 나열한다.
기본 부여는 최대 네 영역의 읽기 전용이다.
쓰기 스코프는 작업별로 부여하고 매달 검토한다.
파괴, 게시, 이메일, 알림 행동은 자체 스코프와 사람의 확인을 요구한다.
소유자 권한은 호출마다 확인한다. 소유자를 폐기하면 에이전트도 폐기된다.
속도 제한은 토큰별로 존재한다.
감사 로그는 도구, 결과, 대상 종류와 id를 기록하고 매주 검토한다.
일부 데이터(최소한 급여)는 어떤 스코프로도 닿을 수 없다.

자주 묻는 질문

MCP 스코프란 무엇인가요?

MCP 서버가 토큰이 할 수 있는 일을 제한하기 위해 정의하는 OAuth 2.1 스코프로, 동의 화면에서 사람이 고릅니다. MCP 명세는 호출이 토큰의 스코프를 넘을 때 서버가 403으로 응답할 것을 요구합니다. 이름과 세분화는 각 서버에 달려 있습니다. 스코프 용어집 항목을 보세요.

AI 에이전트에게 사용자와 같은 권한을 줘야 하나요?

아니요. 사용자의 권한은 상한이지 기본값이 아닙니다. 작업이 건드리는 영역의 읽기 스코프로 시작하고 쓰기는 하나씩 추가하세요. 토큰은 호출마다 사용자 권한을 확인해 절대 그것을 넘지 않아야 합니다.

에이전트용으로 설정 파일에 API 키를 넣어도 되나요?

브라우저가 없는 CI라면 가장 좁은 스코프와 교체 일정을 전제로 괜찮습니다. 개인 노트북에서는 OAuth 흐름을 쓰세요. 토큰은 범위가 제한되고, 단기이며, 갱신·폐기가 가능하고, 명세는 PKCE와 대상 바인딩을 요구합니다.

에이전트가 실제로 무엇을 했는지 어떻게 아나요?

서버의 감사 로그에서 알 수 있습니다. 도구 이름, 결과, 건드린 대상의 종류와 id를 타임스탬프와 함께 요구하세요. 서버가 내용만 기록하거나 오류만 기록한다면 세션을 재구성할 수 없습니다.

에이전트에게 절대 부여하면 안 되는 것은 무엇인가요?

노출을 되돌릴 수 없고 에이전트가 쓸 일상적 목적이 없는 모든 것. 우리에게는 급여입니다. 당신의 목록에는 건강 데이터, 은행 정보, 소스 코드 비밀이 추가될 수 있습니다. 보호는 구조적이어야 합니다. 스코프가 없으면 도구도 없습니다.

MCP의 스텝업 인가란 무엇인가요?

에이전트를 좁은 스코프로 실행하고 특정 호출이 403을 돌려줄 때만 추가 스코프를 위한 새 동의 라운드를 거쳐 넓히는 것입니다. 부여를 처음의 추측이 아니라 작업에 묶어 둡니다.

다음 단계

사용 중인 에이전트 호스트의 동의 화면을 열고 기본으로 요청하는 스코프 수를 세어 보세요. 답이 "전부"라면 그것이 가장 먼저 바꿀 일입니다. Atrix MCP 페이지에는 스코프 49개와 각각이 여는 것이, 개발자 문서에는 도구별로 필요한 스코프가 나와 있습니다.

AI 에이전트의 워크스페이스 접근 범위를 정하는 법: MCP 스코프, 최소 권한, 감사 기록