사용자의 위임과 도구의 실행 권한은 별도로 확인한다
도구가 어떤 작업을 실행할 권한을 가졌다는 사실과 사용자가 그 작업을 맡겼다는 사실은 서로 다른 조건이다. 실행 주체의 넓은 권한을 요청의 허용 범위로 해석하면, 기술적으로 가능한 행위가 위임하지 않은 행위로 이어질 수 있다.
실행 허용을 판단하는 두 근거
사용자가 맡긴 목적·대상·행위의 범위와, 실제 자원에 적용되는 인증·인가 정책을 각각 확인한다. 위임이 있어도 실행 권한이 없으면 접근이 허용되지 않으며, 실행 권한이 있어도 위임 밖의 작업을 임의로 수행하지 않는다.
OWASP Excessive Agency는 사용자 문맥과 최소 권한을 보존하고 실행 시스템이 요청을 인가하도록 설명한다. 모델이 허용된다고 판단하거나 도구 설명에 안전하다고 적힌 것만으로 이 검사를 대신하지 않는다. 고영향 행위에 필요한 승인은 실행 경계에서 적용한다.
승인을 설계할 때는 어떤 대상과 입력·변경 범위를 허용했는지 식별할 수 있게 한다. 이미 승인한 범위의 후속 실행과 범위가 달라진 요청을 구분한다. 이 문단은 위 원칙의 적용 해석이며 모든 도구 호출에 새 승인을 요구하는 규칙은 아니다.
업무 도구를 연결한 뒤의 확인
MCP 기반 AI 에이전트의 도구 실행과 권한 설계 - LG CNS는 백엔드에서 신원·권한을 확인하고 MCP가 허용 범위 안에서 조회하게 한 사례다. 저자는 인가를 강제할 수 있는 신뢰 경계에서 검사해야 한다고 설명한다. 도구 연결의 성공을 그 사용자의 모든 자료 접근 허용으로 해석하지 않는다. 프롬프트의 권한 문구, 실제 인가, 감사 기록은 각각 다른 역할이다.
검사나 승인 단계는 현재 위임과 실행 경계에 맞춘다. 외부 글에 사람의 개입 단계가 있다는 이유만으로 이미 허용된 후속 작업까지 다시 승인받게 하지 않는다. 전달·판정·차단의 일반 구분은 규칙을 다시 전달하는 것과 위반을 판정하는 것은 다르다에서 읽는다.
주체의 식별과 권한의 전달
자동화 주체와 그 주체가 대신하는 사용자를 추적하되, 계정 하나를 추가한 것만으로 위임이 제한됐다고 판단하지 않는다. MCP의 token passthrough 금지는 토큰의 수신 대상 검증과 주체 추적이 연결되는 구체적인 프로토콜 사례다. 이 사례를 모든 시스템의 동일한 인증 구현으로 확대하지 않는다.
입력의 출처·내용 일치는 AI 생성값과 서버 사실값을 분리한다에서, 그 입력을 누가 어떤 범위로 실행할 수 있는지는 이 노트에서 다룬다.