DAILY NEWSLETTER · 2026-07-25 · LOCAL FILES · DESKTOP AUTOMATION · REVOCATION

7월 25일 운영 브리핑 — 로컬 파일, 데스크톱 자동화, 끝나는 에이전트 권한

에이전트의 위험은 모델이 답을 만드는 순간보다, 로컬 파일을 열고 데스크톱에서 클릭하며 다른 서비스의 권한을 계속 보유하는 순간에 커진다. 오늘의 기준은 단순하다. 파일의 위치가 신뢰를 만들지 않고, 화면을 조작할 수 있다는 사실이 업무 범위를 정하지 않으며, 권한을 부여한 뒤에는 그것이 끝났음을 확인할 수 있어야 한다. NIST의 제로 트러스트 원칙과 Google의 OAuth 권한·토큰 회수 문서를 연결해 이 세 경로를 운영 가능한 통제로 바꾼다.

오늘의 방향

첫째, 로컬 디스크라는 위치 자체를 신뢰 경계로 취급하지 않는다. NIST SP 800-207은 물리적 또는 네트워크 위치와 자산 소유만으로 사용자 계정이나 자산에 암묵적 신뢰를 부여하지 않는다고 설명한다. 로컬 폴더에 있는 파일도 에이전트가 읽을 수 있는 자원이라면 누가 어떤 목적에서 어떤 범위로 읽는지 별도로 정해야 한다. 둘째, 데스크톱 자동화는 사람의 화면을 대신 쓰는 기능이지만 사람의 승인과 책임까지 대신하지 않는다. 셋째, 신원 목록은 부여된 접근을 나열하는 문서가 아니라, OAuth 토큰·범위·소유자·회수 경로·회수 검증을 연결하는 운영 기록이어야 한다. 아래의 절차는 두 원문을 조직의 에이전트 운영에 적용한 권고이며, NIST나 Google이 모든 제품에 같은 화면·명령·필드를 요구한다는 뜻은 아니다.

1. 로컬 파일을 경로가 아니라 보호할 자원과 필요한 작업으로 분해한다.
2. 데스크톱 에이전트의 화면 조작을 최소 권한·명시적 승인·기록 가능한 단계로 제한한다.
3. 각 에이전트 신원에 부여·사용·회수·거부 확인까지의 닫힌 경로를 만든다.

1. 로컬 파일 권한은 “내 컴퓨터”가 아니라 자원·주체·작업으로 판단한다

로컬 파일 권한을 다룰 때 흔한 착각은 파일이 회사 노트북이나 업무용 폴더에 있으므로 이미 신뢰된다는 생각이다. NIST SP 800-207의 추상은 반대 방향을 제시한다. 제로 트러스트는 정적 네트워크 경계에서 사용자·자산·자원으로 방어의 초점을 옮기며, 물리적 또는 네트워크 위치와 자산 소유만으로 암묵적 신뢰를 주지 않는다. 이 원칙을 에이전트에 적용하면 파일이 로컬에 있다는 사실은 접근 허용의 근거가 아니라, 보호해야 할 자원이 어디 있는지를 알려 주는 정보가 된다.

원문 · NIST CSRCSP 800-207, Zero Trust Architecture제로 트러스트는 위치나 자산 소유만으로 사용자 계정과 자산에 암묵적 신뢰를 부여하지 않는다고 설명한다.

첫 번째 점검 단위는 폴더 하나가 아니라 파일 묶음과 작업의 조합이다. 예를 들어 에이전트가 회의록을 요약해야 한다면, 회의록을 읽는 권한과 같은 디렉터리의 계약서·비밀 키·개인 파일까지 열람할 수 있는 권한은 다르다. 입력으로 받은 파일을 읽는 작업, 검색 색인을 만들기 위한 읽기, 다른 위치에 복사하는 쓰기, 외부 API에 첨부하는 전송도 같은 “파일 접근”이 아니다. 운영자는 각 작업에 대해 주체, 대상, 동작, 목적지, 유효 기간을 분리해 기록한다. 이 기록은 권한을 자동으로 제한하지는 않지만, 나중에 무엇을 재검토하거나 중지해야 하는지 보이게 한다.

두 번째 점검은 파일의 내용과 경로를 모두 신뢰할 수 없는 입력으로 취급하는 일이다. 문서 안의 문장, 파일명, 폴더명, 메타데이터는 에이전트에 업무 지시처럼 보일 수 있다. 따라서 파일을 발견하고 읽는 단계와 그 안의 지시에 따라 도구를 호출하는 단계를 분리한다. 격리된 시험 폴더에 표식 문서와 업무 목표를 벗어난 문구를 넣고, 에이전트가 문서를 데이터로 처리하는지, 추가 파일을 찾거나 외부 도구를 제안하는지, 쓰기·삭제·전송 전에 승인 경계가 작동하는지를 관찰한다. 실제 고객 파일이나 운영 비밀을 이용해 시험할 필요는 없다. 회수 가능한 시험 계정과 민감하지 않은 표식 데이터가 재현성과 안전성을 함께 높인다.

세 번째 점검은 읽기 결과가 어디까지 이동하는지다. 요약을 위해 파일을 읽는 권한이 있다고 해서 그 원문이나 파생 결과를 어떤 목적지로든 보낼 수 있다는 뜻은 아니다. 출력 파일, 클립보드, 채팅 연동, 브라우저 업로드, 오류 보고, 색인 저장소는 서로 다른 목적지가 될 수 있다. NIST는 세션이 기업 자원에 설정되기 전에 주체와 장치의 인증 및 인가가 별개의 기능으로 수행된다고 설명한다. 조직의 구현은 다를 수 있지만, 이 관점은 로컬 파일 작업에서도 접근 주체와 실행 장치를 한 덩어리로 추정하지 말고 각각 확인하게 한다.

원문 · NIST CSRCSP 800-207, Zero Trust Architecture기업 자원 세션 전 주체와 장치의 인증·인가는 별개의 기능이라는 원칙을 제시한다.

실무 카드에는 최소한 file_set, subject_id, device_context, allowed_action, destination, approval, expiry를 둔다. file_set은 광범위한 홈 디렉터리 대신 필요한 프로젝트·형식·생성 위치처럼 좁게 표현한다. allowed_action은 읽기, 생성, 수정, 삭제, 전송을 구분한다. destination에는 결과가 남을 저장소와 외부 전송 가능 여부를 쓴다. approval은 어떤 행동에서 누구의 확인이 필요한지 표시한다. 원시 토큰·비밀번호·문서 전문을 이 카드에 복사하지 않는다. 참조값과 로그 위치를 남기고 민감한 원문은 통제된 저장소에 둔다.

이 카드가 살아 있는지 확인하려면 한 가지 실패 시나리오를 실행한다. 에이전트에 허용되지 않은 하위 폴더를 읽게 하거나, 읽은 표식 파일을 승인되지 않은 목적지로 보내게 한다. 기대 결과는 “모델이 거절 문장을 생성한다”가 아니라 실제 파일 열람·쓰기·전송이 일어나지 않고, 어떤 주체가 어떤 규칙 때문에 거부됐는지 감사 기록으로 남는 것이다. 실패를 정상적인 결과로 남길 수 있어야 권한 경계가 다음 버전에서도 비교 가능한 통제가 된다.

2. 데스크톱 자동화 권한은 화면의 능력과 업무의 권한을 분리해야 한다

AWS는 Amazon WorkSpaces for AI agents를 데스크톱 애플리케이션에서 에이전트가 행동할 수 있는 관리형 작업 공간으로 소개한다. 이 제품 소개는 특정 팀의 권한 정책을 대신하지 않는다. 다만 API가 없는 업무용 데스크톱 애플리케이션까지 자동화의 실행 범위가 넓어질 수 있음을 보여 준다. 따라서 화면을 조작할 수 있다는 기능과 어떤 업무 행동을 허용할 것인지는 따로 설계해야 한다.

원문 · AWSAmazon WorkSpaces for AI agents관리형 WorkSpaces에서 AI 에이전트가 데스크톱 애플리케이션을 조작하는 제품 맥락을 제공한다.

데스크톱 에이전트는 파일 선택 창을 열고, 브라우저에 로그인하며, 복사·붙여넣기하고, 버튼을 눌러 업무를 끝낼 수 있다. 이 흐름은 편리하지만 한 번의 화면 조작 권한이 수많은 자원 접근으로 번질 수 있다는 뜻이기도 하다. NIST는 제로 트러스트가 자원, 자산, 서비스, 워크플로, 네트워크 계정 등을 보호 대상으로 본다고 설명한다. 데스크톱을 한 개의 신뢰된 화면으로 보는 대신, 자동화가 닿는 파일·웹 애플리케이션·세션·업로드 목적지·워크플로를 각각 자원으로 보아야 하는 이유다.

원문 · NIST CSRCSP 800-207, Zero Trust Architecture제로 트러스트의 보호 대상에는 자원·서비스·워크플로·네트워크 계정 등이 포함된다.

데스크톱 자동화의 첫 경계는 역할과 실행 범위다. “브라우저를 조작할 수 있음”은 인사 시스템, 재무 서비스, 개인 메일, 관리자 콘솔을 같은 방식으로 조작할 수 있다는 허가가 아니다. 작업별로 허용 애플리케이션, 허용 계정, 허용 도메인, 허용 동작, 최대 실행 시간을 정한다. 예를 들어 정기 보고서 초안을 올리는 자동화는 지정된 브라우저 프로필과 지정된 저장소에서 파일을 읽고 초안을 만드는 데서 끝날 수 있다. 게시 버튼, 결제 버튼, 사용자 추가, 권한 변경, 비밀 표시처럼 되돌리기 어렵거나 범위를 넓히는 단계는 사람의 명시적 확인을 요구하는 별도 경계로 둔다.

두 번째 경계는 로그인 상태다. Google의 OAuth 문서는 애플리케이션이 요청할 권한을 정의하는 인증 요청의 매개변수와, 사용자에게 부여를 요청할 범위를 설명한다. 또한 OAuth 2.0은 비밀번호 등을 공유하지 않으면서 사용자가 애플리케이션에 특정 데이터 접근을 공유할 수 있게 한다고 설명한다. 데스크톱 자동화에 이 사실을 적용하면, 사람의 브라우저 세션을 에이전트가 우연히 이어받는 구조보다 목적이 분명한 애플리케이션 신원과 필요한 범위를 따로 설계하는 편이 검토 가능하다. 이는 Google 문서가 특정 데스크톱 제품의 설계를 지시한다는 주장이 아니라, 세션의 편의와 권한 부여의 범위를 혼동하지 않기 위한 운영 적용이다.

원문 · Google for DevelopersUsing OAuth 2.0 for Web Server ApplicationsOAuth 요청은 애플리케이션과 요청 권한을 식별하며, OAuth는 특정 데이터 접근을 공유하도록 설계됐다고 설명한다.

세 번째 경계는 관찰과 중단이다. 자동화는 정상 경로에서만 움직이지 않는다. 리디렉션된 로그인 화면, 새 도메인의 팝업, 예상하지 않은 권한 동의 창, 파일 선택기의 상위 폴더, 오류 복구 화면은 모두 범위가 넓어질 수 있는 지점이다. 자동화 정책에는 허용된 창 제목이나 도메인 목록만 적기보다, 목록 밖의 상태가 나오면 중지하고 사람에게 넘기는 동작을 둔다. 실행 기록에는 시작한 신원, 사용한 프로필 또는 장치 문맥, 열린 대상, 파일 선택 또는 업로드 여부, 승인이 필요한 단계, 중지 이유, 결과를 남긴다. 화면 캡처와 로그는 민감한 내용을 포함할 수 있으므로 보존 위치와 접근자도 정해야 한다.

시험은 낮은 위험의 격리된 환경에서 한다. 승인되지 않은 도메인으로 이동시키는 링크, 다른 계정을 선택하게 하는 화면, 쓰기 권한을 요구하는 대화 상자, 민감하지 않은 표식 파일을 외부에 첨부하려는 흐름을 준비한다. 통제는 예상하지 않은 화면을 알아차리고 중지해야 하며, 이미 시작된 도구 호출이나 업로드가 있으면 그 상태를 확인할 수 있어야 한다. 한 번의 성공 시연은 충분하지 않다. 정책 변경, 브라우저 업데이트, 에이전트 도구 변경 뒤 동일한 사례를 다시 실행해 차단과 기록이 유지되는지 비교한다.

결국 데스크톱 자동화의 승인 화면은 신뢰의 종착점이 아니다. 누가 요청했고, 어떤 범위가 부여됐으며, 어떤 자원을 실제로 조작했고, 언제 멈췄는지 연결할 수 있어야 한다. 이 연결이 없으면 담당자는 화면에서 완료 표시를 보더라도 그 자동화가 어떤 파일·세션·토큰·외부 목적지에 닿았는지 재구성하기 어렵다. 반대로 작업 단위 경계와 기록을 갖추면, 자동화를 끄지 않고도 더 좁은 위험으로 운영할 선택지가 생긴다.

3. 접근 회수와 신원 목록은 “토큰 삭제”를 넘어 이전 경로의 거부까지 확인한다

에이전트 권한은 사람이 퇴사하거나 프로젝트가 끝날 때만 회수하는 문제가 아니다. 작업 범위가 바뀌거나, 데스크톱 자동화를 다른 환경으로 옮기거나, 로컬 파일 접근 시험에서 예외가 드러나거나, 새 통합을 붙일 때도 신원을 다시 확인해야 한다. NIST는 네트워크 위치가 더 이상 자원의 보안 상태를 좌우하는 핵심 요소로 보이지 않는다고 설명한다. 따라서 사내 장치에서 실행된다는 이유만으로 이전 OAuth 동의, 서비스 신원, 브라우저 세션, API 연결이 계속 적절하다고 가정할 수 없다.

원문 · NIST CSRCSP 800-207, Zero Trust Architecture네트워크 위치를 자원의 보안 상태를 결정하는 핵심 요소로 보지 않는 제로 트러스트 관점을 제시한다.

목록의 한 행은 화면에 보이는 에이전트 이름만으로 충분하지 않다. subject_id, owner, purpose, scope, credential_ref, device_or_runtime, last_review, expiry, revoke_path, revoke_evidence를 연결한다. subject_id는 디렉터리나 인증 제공자가 식별하는 실제 주체다. owner는 검토와 종료에 책임지는 사람 또는 역할이다. scope는 역할 이름뿐 아니라 닿을 수 있는 자원과 허용 동작을 표현한다. credential_ref에는 원시 비밀이 아닌 안전한 참조만 둔다. 기술적 만료가 없으면 재승인 날짜를 expiry로 기록해 영구 권한처럼 잊히지 않게 한다.

Google 문서는 액세스 토큰과 새 액세스 토큰을 얻는 데 쓸 수 있는 리프레시 토큰을 설명하며, 리프레시 토큰은 사용자가 접근을 철회하거나 토큰이 만료될 때까지 유효하다고 적는다. 또 토큰을 취소하는 예시로 OAuth 2.0 서버의 /revoke 엔드포인트에 토큰을 POST하는 흐름을 제시한다. 이 문서의 정확한 절차와 엔드포인트는 Google OAuth 환경의 것이다. 이를 일반화해 다른 제공자에 같은 주소나 결과를 가정해서는 안 된다. 다만 목록에 발급자별 회수 경로와 회수 후 검증을 반드시 넣어야 한다는 운영 원칙은 여기서 분명해진다.

원문 · Google for DevelopersUsing OAuth 2.0 for Web Server Applications리프레시 토큰의 유효 조건과 Google OAuth 토큰 회수 흐름을 설명한다. 제품별 회수 절차는 각 발급자 문서를 따른다.

회수 훈련은 목록이 실제 통제인지 확인하는 가장 짧은 방법이다. 낮은 위험의 시험 신원을 고르고, 먼저 현재 접근이 존재한다는 증거를 남긴다. 그다음 목록의 revoke_path에 따라 해당 OAuth 동의·토큰·역할·세션·키를 취소, 비활성화 또는 교체한다. 이후에는 두 군데에서 확인한다. 발급자 쪽에서는 취소나 교체가 완료됐는지 확인하고, 대상 자원 쪽에서는 이전 경로를 사용한 요청이 거부되는지 확인한다. 두 확인은 중복이 아니다. 발급자 화면의 상태 변경만으로 대상 서비스의 캐시된 세션이나 파생 접근이 이미 끝났다고 결론 낼 수 없고, 대상의 일시적 오류만으로 회수가 성공했다고 볼 수도 없다.

revoke_evidence에는 티켓 번호 하나만 두지 않는다. 수행 시각, 수행자, 발급자 확인 위치, 대상 자원에서의 거부 결과, 새 참조 또는 교체 상태, 남은 예외, 다음 검토 날짜를 연결한다. 실패한 회수 시도도 남긴다. 숨겨진 실패는 다음 담당자에게 열린 접근 경로를 알려 주지 못한다. 소유자가 없거나 회수 경로가 비어 있는 신원은 새 파일 접근이나 데스크톱 자동화에 연결하기 전에 해결할 항목으로 분류한다. 목록의 품질은 행 수가 아니라 각 행이 어떻게 끝나는지를 설명할 수 있는지로 판단한다.

운영자 메모

오늘 만들 수 있는 가장 작은 산출물은 세 장의 카드다. 첫 장에는 하나의 로컬 파일 작업에 대해 읽기·쓰기·전송을 나누고, 파일 묶음·주체·목적지·승인·만료를 적는다. 둘째 장에는 하나의 데스크톱 자동화에 대해 허용 애플리케이션·계정·도메인·되돌리기 어려운 행동의 승인 지점·중지 조건을 적는다. 셋째 장에는 실제 또는 시험 에이전트 하나의 subject_id부터 revoke_evidence까지 채운다. 세 카드가 완벽한 정책 문서일 필요는 없지만 빈 소유자, 넓은 파일 범위, 알 수 없는 목적지, 없는 회수 경로는 반드시 보이게 해야 한다.

그다음 한 번의 회수 훈련을 실행한다. 안전한 시험 신원으로 허용된 로컬 파일 하나를 읽거나 좁은 데스크톱 작업 하나를 수행하게 하고, 연관된 OAuth 또는 다른 자격증명 경로를 회수한다. 발급자와 대상 자원 양쪽에서 이전 접근이 끝났음을 확인하고, 로그 위치와 결과를 같은 목록 행에 연결한다. 이 작은 훈련은 로컬 파일 통제, 화면 자동화 승인, 신원 종료를 각각의 체크리스트가 아니라 하나의 운영 흐름으로 바꾼다.

오늘의 결론

7월 25일의 결론은 에이전트 권한을 장소나 화면의 편의로 판단하지 않는 데 있다. 로컬 파일은 위치가 아니라 보호할 자원이며, 데스크톱 자동화는 화면 조작 능력이 아니라 제한된 업무 범위이고, OAuth와 다른 신원은 부여된 뒤에도 회수와 거부 확인까지 관리해야 하는 접근 경로다. NIST의 제로 트러스트 원칙은 암묵적 신뢰를 경계하게 하고, Google의 OAuth 문서는 범위 있는 권한과 토큰 회수의 구체적 맥락을 제공한다.

오늘 한 가지를 한다면 낮은 위험의 에이전트 한 개를 골라 파일 범위와 데스크톱 작업 범위를 적고, 그 신원의 회수 경로를 실제로 시험한다. 이전 경로의 요청이 대상 자원에서 거부됐다는 증거까지 남기면, 다음 자동화는 더 많은 권한을 기본값으로 받지 않아도 된다. 접근을 시작하는 일보다 끝낼 수 있는지 확인하는 일이 에이전트 운영의 신뢰를 만든다.