에이전트가 사용자를 대신해 여러 시스템을 조작합니다. 사용자 권한과 서비스 계정·도구 권한을 어떻게 나누나요?

모델이 요청을 이해하는 권한과 실제 시스템을 변경하는 자격을 분리하겠습니다. 사용자의 인증된 신원과 승인 범위를 런타임이 유지하고, 도구마다 필요한 자원·행동·기간에 맞는 최소 권한을 사용합니다. 모델 프롬프트에 관리자 토큰을 넣거나 도구가 넓은 서비스 계정으로 모든 사용자 요청을 처리하게 하면 작은 판단 오류의 피해 범위가 커집니다.

인자는 권한의 증명이 아닙니다

모델이 요청 인자로 user_id나 tenant_id를 보냈다고 그 사용자를 대신할 수 있는 것은 아닙니다. 실행기는 인증 문맥에서 사용자 범위를 얻고 요청 대상이 그 범위에 있는지 검사합니다. 모델은 어떤 주문을 처리할지 제안할 수 있지만 다른 테넌트의 주문을 지정하면 서버가 거절해야 합니다. 도구 수준의 write 권한과 특정 자원에 대한 소유권 검사도 구분합니다.

조회·초안 작성·게시·삭제를 나누면 작업에 필요한 권한만 발급하기 쉽습니다. 짧은 수명의 자격이나 작업에 묶인 capability를 사용할 수 있지만 토큰이 만료되어도 이미 실행된 외부 효과는 남습니다. 민감한 변경은 실행 직전 승인된 인자와 대상 버전을 확인합니다. 자격 증명은 가능한 한 모델과 생성 코드가 읽지 못하는 실행 계층에서 주입합니다.

재위임과 권한 철회

하위 에이전트가 필요하다고 더 강한 서비스 계정을 쓰게 하면 원래 사용자의 권한이 확대될 수 있습니다. 재위임은 원래 권한의 부분집합이어야 하고, 추가 권한이 필요하면 사용자 승인이나 관리자 정책을 거쳐야 합니다. 한 도구에서 거절된 행동을 다른 연결이나 에이전트에게 시키는 것은 정상 복구가 아니라 권한 우회가 될 수 있습니다.

장기 작업에서는 시작 당시 권한만 확인하지 않고 중요한 조회·변경 때 현재 권한과 취소 상태를 다시 확인합니다. 사용자가 접근을 철회했는데 큐에 남은 작업이 계속 실행되지 않도록 실행권과 내구 상태를 연결합니다. 시험은 다른 사용자 대상, scope 부족, 만료·철회, 재위임, 서비스 계정 fallback을 포함합니다. 성공률을 높이기 위해 거절을 없애는 것이 아니라 허용된 작업은 수행하고 금지된 작업은 안정적으로 거절하는 것이 목적입니다. 최소 권한은 에이전트가 예의 있게 행동한다는 기대가 아니라 실제 접근 가능한 자원을 좁히는 실행 설계입니다.

실행 사례로 확인합니다

한 도구가 읽기와 삭제를 같은 자격으로 제공하면 프롬프트에서 삭제 도구를 숨겨도 다른 API 경로로 실행될 수 있습니다. 실제 자격·서버 인가에서 삭제를 금지해야 합니다. 사용자가 특정 폴더만 허용했다면 하위 경로·심볼릭 링크·리다이렉트로 범위를 벗어나는 접근도 검사합니다. 일시적으로 권한을 높이는 절차는 대상·시간·이유를 남기고 작업이 끝나면 회수합니다. 실패한 요청을 디버깅하려고 비밀 토큰을 모델에게 보여 주는 것은 문제 해결에 꼭 필요한 경우가 드물고 노출 범위만 늘릴 수 있습니다. 오류 코드와 필요한 scope 같은 최소 정보로도 대부분의 복구 경로를 안내할 수 있습니다.