DAILY NEWSLETTER · 2026-07-22 · AGENT ACCESS · LOCAL DATA BOUNDARY · LOOP EXIT CONTRACT

7월 22일 운영 브리핑 — 에이전트 접근표, 로컬 경계, 끝나는 루프

오늘의 세 주제는 에이전트가 일을 시작하기 전, 실행하는 동안, 끝났다고 말하는 순간에 필요한 경계를 다룬다. 시작 전에는 사람 계정 밖의 접근 주체까지 찾아 소유자와 회수 방법을 연결해야 한다. 실행 중에는 로컬 파일을 읽을 수 있는 범위와 밖으로 보낼 수 있는 목적지를 분리해야 한다. 종료 시점에는 통과 조건, 시도 한도, 중단 이유, 롤백과 증거가 남아야 한다.

오늘의 운영 포인트

에이전트 운영의 위험은 모델이 틀린 답을 내는 순간에만 생기지 않는다. 누가 만든 것인지 모르는 OAuth 동의, 브라우저 확장, 오래된 API 키 참조가 남아 있으면 시작점부터 통제가 흐려진다. 로컬 에이전트가 사용자 권한으로 넓은 폴더를 읽고, 결과를 어떤 외부 서비스로 보내는지 구분하지 않으면 작업 편의가 곧 데이터 이동 권한이 된다. 성공 조건 없이 재시도하는 루프는 문제를 푸는 자동화가 아니라 변경과 비용을 축적하는 장치가 된다. 오늘 필요한 산출물은 거대한 정책 문서가 아니라 접근표, 데이터 경계표, 종료 계약 세 장이다.

1. 사람 계정뿐 아니라 에이전트 계정, OAuth 연결, 확장 프로그램, API 키 참조, 서비스·비인간 ID를 같은 접근표에서 관리한다.
2. 로컬 읽기 범위와 외부 전송 목적지를 별도 허용 목록으로 두고, 로그·세션·퇴사 또는 작업 종료 뒤의 정리 기준을 연결한다.
3. 루프는 수락 시험, 최대 시도, 중단 이유, 롤백 지점, 결과 증거를 갖출 때만 자동으로 다시 돈다.

1. 에이전트 접근은 계정 목록이 아니라 만료와 회수까지 이어지는 소유권 표다

Microsoft Learn은 Microsoft Agent 365의 보안 구성을 설명하면서 조직 안의 에이전트 ID 가시성, 최소 권한, 책임 있는 후원자, 필요 이상 지속되지 않는 접근 수명주기를 강조한다. 이는 해당 제품군이 제공한다고 밝힌 기능과 운영 방향이며 모든 환경에 자동으로 적용되는 보편 통제를 뜻하지 않는다. NIST AI Risk Management Framework는 AI 제품·서비스·시스템의 설계, 개발, 사용, 평가에 신뢰성 고려를 포함하도록 돕는 자발적 프레임워크다. NIST는 현재 AI RMF 1.0이 개정 중이라고도 밝힌다. 두 자료를 함께 읽을 때 운영팀이 가져갈 질문은 특정 벤더 화면을 그대로 복제할지가 아니라, 우리 조직의 에이전트 접근 주체를 누락 없이 발견하고 책임·범위·종료 증거를 연결할 수 있는가다.

원문 · Microsoft LearnSecure AI agents at scale using Microsoft Agent 365에이전트 ID 가시성, 최소 권한, 후원자, 접근 수명주기를 Microsoft 제품군 안에서 다루는 자료다. 원문 · NISTAI Risk Management FrameworkAI 위험 관리를 조직의 설계·개발·사용·평가 활동에 포함하기 위한 자발적 프레임워크와 현재 개정 상태를 안내한다.

첫 번째 행에는 로그인 가능한 에이전트 전용 계정과 플랫폼이 발급한 에이전트 ID를 적는다. 표시 이름만으로는 부족하다. 실제 디렉터리 또는 공급자 식별자, 생성일, 만든 사람, 현재 소유 팀, 인증 방식, 연결 자원, 마지막 사용 시점이 필요하다. 개인 계정을 자동화에 재사용했다면 그것도 숨기지 않고 기록한다. 그래야 담당자가 이동하거나 퇴사했을 때 자동화의 소유권과 개인 접근을 분리할 수 있다. 목록에 있다는 사실은 승인되었다는 뜻이 아니다. 발견 상태, 검토 상태, 허용 상태를 나누면 미확인 접근을 정상 접근처럼 취급하는 실수를 줄일 수 있다.

두 번째 묶음은 OAuth 애플리케이션과 동의, 브라우저 확장, API 키 참조다. OAuth는 앱 이름뿐 아니라 클라이언트 ID, 승인된 범위, 동의 주체, 토큰을 쓰는 워크플로, 취소 위치를 연결한다. 브라우저 확장은 설치 ID, 요청 권한, 배포 방식, 사용 프로필, 관리 주체를 적는다. API 키 원문은 접근표에 복사하지 않는다. 비밀 저장소의 참조 이름, 사용 서비스, 호출 대상, 회전일, 폐기 절차만 둔다. 문서와 코드에 남은 키 이름이나 환경 변수 참조도 찾되, 실제 비밀값을 새 문서와 로그로 확산하지 않는다.

세 번째 묶음은 서비스 계정, 워크로드 ID, 로봇 사용자, CI 자격 증명처럼 사람 화면에 잘 드러나지 않는 비인간 ID다. 이 주체는 사람이 매일 로그인하지 않아서 방치되기 쉽지만, 저장소 쓰기·클라우드 배포·고객 데이터 읽기 같은 넓은 권한을 오래 유지할 수 있다. 접근표는 owner, scope, expiry, revoke_path를 한 줄에 보여 줘야 한다. 소유자는 팀 이름만 쓰지 않고 실제 재검토 책임자를 연결한다. 범위는 역할 이름과 실제 자원을 함께 적는다. 만료가 없는 자격 증명은 ‘무기한’으로 감추지 말고 재승인 날짜를 둔다.

회수 증거는 삭제 버튼을 눌렀다는 메모보다 구체적이어야 한다. OAuth 동의가 취소되었는지, 토큰과 키가 폐기 또는 회전되었는지, 서비스 ID의 역할 할당이 제거되었는지, 확장이 관리 프로필에서 빠졌는지 확인한 위치와 시각을 남긴다. 작업 종료나 담당자 변경 때는 접근표의 모든 행을 같은 종료 티켓에 연결한다. 접근이 이미 만료되었더라도 세션과 파생 토큰이 계속 유효할 수 있으므로, 발급자와 대상 서비스 양쪽에서 종료 상태를 확인한다. 실패한 회수도 덮지 않고 남겨 다음 담당자가 남은 경로를 바로 볼 수 있게 한다.

ZHS는 접근 카드에 subject_type, subject_id, owner, scope, credential_ref, expiry, revoke_path, revoke_evidence를 두는 편집안을 제안한다. 이 필드들은 Microsoft나 NIST가 요구하는 표준 스키마가 아니며 법적 준수 판정표도 아니다. 조직의 디렉터리, 비밀 관리, 브라우저 관리, 클라우드 권한 자료를 한 번에 대조하기 위한 ZHS 운영 제안이다. 핵심은 칸 수가 아니라 발견한 접근마다 책임자와 종료 방법이 함께 보이는 상태다. 소유자나 회수 경로가 비어 있다면 새 에이전트를 더 연결하기 전에 그 빈칸부터 해결한다.

2. 로컬 파일 에이전트는 읽을 폴더와 내보낼 목적지를 서로 다른 경계로 가져야 한다

Microsoft Foundry 문서는 하나의 호스티드 에이전트 엔드포인트를 여러 사용자가 이용할 때 대화, 세션, 저장 데이터를 호출자별로 격리하는 방식을 설명한다. 문서에는 미리 보기 기능의 제약과, 위임 호출에서 사용자별 세션 ID를 잘못 공유하면 데이터가 섞일 수 있다는 경고도 들어 있다. 별도의 Defender for Endpoint 문서는 로컬 AI 에이전트가 사용자 권한으로 파일을 읽고 도구와 명령을 실행할 수 있으며, 읽은 콘텐츠 속 악성 지시가 행동을 가로챌 수 있다고 설명한다. 감사 뒤 차단으로 넓히는 단계적 배포는 해당 라이선스와 지원 Windows 환경을 전제로 한 제품 지침이다. 두 문서는 모든 로컬 에이전트의 안전을 보장하지 않지만, 사용자·세션·파일·행동 경계를 별도로 시험해야 한다는 구체적인 운영 사례를 준다.

원문 · Microsoft LearnIsolate hosted agent sessions per user - Microsoft Foundry호출자와 세션의 연결, 사용자별 대화·저장 데이터 격리, 위임 호출에서의 주의점을 Foundry 기준으로 설명한다. 원문 · Microsoft LearnSet up AI agent runtime protection with Microsoft Defender for Endpoint - Microsoft Defender for Endpoint사용자 권한으로 움직이는 로컬 에이전트의 프롬프트 인젝션 위험과 감사·차단 배포 절차를 지원 환경에 한정해 다룬다.

로컬 작업 카드에는 먼저 allowed_folders를 적는다. “내 컴퓨터”나 사용자 홈 전체가 아니라 이번 작업에 필요한 저장소, 입력 폴더, 임시 산출물 폴더를 명시한다. 읽기와 쓰기도 분리한다. 참고 문서는 읽을 수 있지만 원본 미디어에는 쓰지 못하게 하고, 산출물은 전용 디렉터리에만 만들 수 있다. 심볼릭 링크, 마운트된 클라우드 드라이브, 다운로드 폴더처럼 경계 밖으로 이어질 수 있는 경로도 확인한다. 운영체제 권한이 넓다는 사실을 작업 허용 범위로 오해하지 않는다.

그다음 outbound_destinations를 별도 목록으로 둔다. 로컬에서 읽을 수 있다는 사실이 외부 모델 API, 검색 서비스, 오류 수집기, 채팅 채널, 이슈 트래커로 보낼 수 있다는 뜻은 아니다. 목적지마다 호스트 또는 서비스, 전송 데이터 종류, 호출 목적, 승인 근거를 적는다. 리디렉션과 공급자 측 추가 처리처럼 실행 중 드러나는 새 목적지가 있으면 자동 전송을 멈춘다. 외부 전송이 필요 없는 요약·분류 작업은 네트워크 없이 실행하는 경로를 우선 검토한다. 허용 목적지 목록은 방화벽 규칙을 대신하지 않지만, 규칙과 실제 작업 의도를 대조할 기준이 된다.

로그는 많이 남길수록 안전하다는 전제를 버린다. 경로 전체, 프롬프트 원문, 문서 본문, 액세스 토큰, 사용자 식별자를 그대로 기록하면 장애 분석용 로그가 두 번째 데이터 저장소가 된다. 필요한 것은 실행 ID, 정책 버전, 허용 또는 차단된 행동 종류, 대상의 축약 식별자, 결과 상태, 보존 기한이다. 오류 재현에 본문 일부가 꼭 필요하면 최소 구간만 별도 접근 통제 아래 보관하고 삭제 시점을 정한다. 디버그 모드를 켰다면 작업 종료 뒤 꺼졌는지 확인한다. 로그 최소화는 증거를 없애는 일이 아니라 판단에 필요하지 않은 원문 복제를 줄이는 일이다.

세션 경계는 로그인 주체와 작업 주체를 함께 본다. 여러 사용자가 하나의 서비스 자격 증명으로 같은 에이전트를 호출하면 플랫폼 수준의 사용자 격리가 자동으로 따라온다고 가정할 수 없다. 앱이 안정적인 사용자 식별자와 세션을 어떻게 묶는지, 다른 사용자의 세션 ID를 넣었을 때 거부되는지, 새 로그인과 로그아웃 뒤 캐시가 남는지 시험한다. 로컬 에이전트도 프로젝트별 작업 디렉터리와 임시 파일, 브라우저 프로필, 도구 세션을 나눈다. 공유 세션이 필요한 협업이라면 우연한 공유가 아니라 참여자와 종료 시점을 적은 명시적 선택으로 만든다.

오프보딩은 계정 비활성화 한 번으로 끝나지 않는다. 작업이 끝나면 임시 복사본, 캐시, 업로드 대기열, 실행 중인 프로세스, 브라우저 로그인, 발급된 세션, 로컬 환경 변수 참조를 확인한다. 담당자 이동이나 기기 반납 때는 접근표의 회수 절차와 데이터 경계표의 삭제 절차를 같은 티켓에서 수행한다. ZHS는 경계 카드에 allowed_folders, write_targets, outbound_destinations, log_fields, retention, session_owner, offboarding_check를 두는 편집안을 제안한다. 이 역시 두 Microsoft 문서가 요구하는 공통 스키마가 아니라, 서로 다른 제품 사례를 로컬 운영 질문으로 옮긴 ZHS 제안이다.

3. 루프 엔지니어링의 핵심은 반복 횟수가 아니라 끝낼 수 있는 계약이다

Addy Osmani의 글은 자동화, 분리된 작업공간, 스킬, 플러그인·커넥터, 하위 에이전트, 대화 밖의 상태 기록을 장기 실행 루프의 구성 요소로 제시한다. 특히 작성자와 검증자를 분리하고, 시도·통과·미완료 상태를 외부 기록에 남기는 관점을 강조한다. 이는 한 실무자의 설계 관점이며 모든 도구가 같은 기능이나 보장을 제공한다는 표준 문서가 아니다. Anthropic 문서는 성공 기준을 구체적이고 측정 가능하며 달성 가능하고 목적에 맞게 정한 뒤, 실제 작업과 경계 사례를 반영한 평가를 설계하라고 안내한다. 이 역시 Claude 활용을 위한 벤더 지침이다. 운영자는 두 자료를 ‘계속 돌리는 법’보다 ‘무엇을 통과하면 끝나고 무엇이 생기면 멈추는가’를 쓰는 근거로 활용할 수 있다.

원문 · AddyOsmani.comLoop Engineering분리된 작업공간, 작성자·검증자 분리, 외부 상태 기록을 포함한 장기 실행 에이전트 루프의 한 설계 관점을 제시한다. 원문 · Anthropic DocsDefine success criteria and build evaluations구체적이고 측정 가능한 성공 기준과 실제 작업·경계 사례를 반영한 평가 설계를 안내하는 Claude 벤더 문서다.

종료 계약의 첫 줄은 산출물 이름이 아니라 수락 시험이다. “보고서를 작성한다” 대신 필수 섹션이 모두 있고, 여섯 원문 URL이 일치하며, 금지된 표현이 없고, 렌더링이 깨지지 않는다는 식으로 관찰 가능한 조건을 쓴다. 코드라면 재현되는 결함, 기존 계약, 새 동작, 회귀 조건을 나눈다. 조사라면 확인된 사실과 추론을 분리하고, 각 핵심 주장에 원문 근거가 연결되는지를 본다. 기준이 여러 차원이라면 하나의 평균으로 숨기지 않고 각각 통과 여부를 남긴다. 그래야 일부 장점이 치명적인 실패를 가리지 않는다.

두 번째 줄은 시도 예산이다. max_attempts를 정하고 한 시도에 무엇이 포함되는지 정의한다. 같은 명령을 인자만 바꿔 세 번 실행한 것을 한 번으로 셀지, 수정·검증 한 묶음을 한 번으로 셀지 팀이 일관되게 써야 한다. 실패할 때마다 관찰, 가설, 변경, 결과를 짧게 남긴다. 같은 오류와 같은 가설이 반복되면 남은 횟수가 있어도 멈춘다. 횟수 제한은 성급히 포기하기 위한 장치가 아니라, 새 정보 없는 반복을 사람이 알아차릴 수 있게 하는 장치다.

세 번째 줄은 중단 이유의 분류다. accepted, attempt_limit, repeated_failure, scope_change, permission_required, unsafe_input, dependency_unavailable, operator_cancelled처럼 다음 행동을 결정할 수 있는 값을 쓴다. 자유로운 서술은 그 아래에 붙인다. ‘완료’와 ‘실패’만 있으면 권한 대기, 외부 장애, 요구 변경이 모두 실패로 섞인다. 반대로 ‘거의 완료’를 성공으로 기록하면 다음 자동 실행이 불완전한 산출물을 기준으로 삼는다. 중단 이유는 에이전트 평가표가 아니라 재개·롤백·폐기 중 무엇을 할지 고르는 운영 신호다.

네 번째 줄은 롤백 지점과 증거 묶음이다. 작업 전 기준 커밋이나 파일 해시, 변경한 파일 목록, 데이터 쓰기 대상, 외부 행동 ID를 먼저 잡는다. 실패하면 코드를 되돌리는 것만으로 충분한지, 생성한 레코드·게시물·메시지·업로드도 취소해야 하는지 확인한다. 증거에는 수락 시험 결과, 마지막 변경, 각 시도의 핵심 오류, 사용한 입력 버전, 외부 행동 영수증, 남은 영향이 들어간다. 비밀값과 불필요한 원문은 제외한다. 롤백이 불가능한 행동은 실행 전에 별도 승인을 받도록 계약에 표시한다.

작성자와 검증자를 나누더라도 종료 권한이 흐려지면 루프는 닫히지 않는다. 작성자는 변경을 제안하고 증거를 제출한다. 검증자는 원래 수락 시험을 바꾸지 않은 채 결과를 재실행하고, 통과·반려·보류 중 하나를 고른다. 시험 자체를 바꿔야 한다면 요구 변경으로 기록하고 새 기준선에서 다시 시작한다. ZHS는 종료 카드에 acceptance_tests, max_attempts, attempt_log, stop_reason, rollback_point, evidence_path, reviewer를 두는 편집안을 제안한다. 이는 Addy Osmani나 Anthropic의 필수 스키마가 아니라, 자료의 반복·검증 원칙을 실행 가능한 인수인계로 바꾼 ZHS 제안이다.

운영자 메모

오늘 바로 만들 수 있는 최소 산출물은 세 장의 카드다. 접근 카드에는 현재 쓰는 에이전트 계정 하나와 OAuth 연결 하나, 브라우저 확장 하나, API 키 참조 하나를 올린다. 각 행에 소유자, 범위, 만료 또는 재검토일, 회수 경로, 마지막 사용 근거를 붙인다. 비밀 원문은 넣지 않는다. 빈칸이 보이면 ‘미확인’으로 표시하고 확인 담당자와 기한을 정한다. 목록을 완성할 때까지 기다리기보다 위험이 큰 쓰기·배포·외부 전송 권한부터 시작한다.

경계 카드에는 한 실제 작업을 골라 읽기 폴더, 쓰기 폴더, 외부 목적지, 로그 필드, 보존 기간, 세션 소유자, 종료 점검을 적는다. 그다음 허용 폴더 밖의 파일 요청, 허용되지 않은 목적지 전송, 다른 사용자의 세션 ID, 로그에 들어온 비밀값이라는 네 가지 실패 상황을 안전한 테스트 환경에서 확인한다. 제품이 제공하는 격리나 차단 기능이 있더라도 카드와 시험을 생략하지 않는다. 제품 기능은 특정 조건에서 동작하고, 운영 경계는 그 조건과 실제 작업 의도를 연결해야 하기 때문이다.

종료 카드에는 지금 진행 중인 자동 작업 하나를 올린다. 사람이 읽어도 통과 여부가 분명한 수락 시험, 최대 시도, 반복 실패 기준, 추가 권한이 필요할 때의 중단 이유, 롤백 지점, 증거 위치, 최종 검토자를 적는다. 세 카드는 따로 보관해도 식별자는 연결한다. 어떤 접근 주체가 어떤 데이터 경계 안에서 어떤 종료 계약으로 작업했는지 한 번에 추적할 수 있어야 한다. 자동화의 속도보다 이 연결이 먼저다.

오늘의 결론

7월 22일의 운영 과제는 에이전트에게 더 많은 일을 맡기기 전에 시작·실행·종료의 소유권을 되찾는 일이다. 시작점에서는 에이전트 계정, OAuth, 확장 프로그램, API 키 참조, 비인간 ID를 회수 가능한 접근표로 만든다. 실행 중에는 로컬 읽기 범위와 외부 전송 목적지를 분리하고 로그와 세션의 수명을 줄인다. 종료 시점에는 수락 시험과 시도 한도, 중단 이유, 롤백과 증거로 루프를 닫는다.

오늘 한 작업만 골라 세 장의 카드를 연결해 보자. 접근 주체의 소유자와 회수 경로를 적고, 허용 폴더와 전송 목적지를 고정하고, 통과하지 못했을 때 멈출 이유와 되돌아갈 지점을 적는다. 이 작은 계약이 있으면 에이전트는 권한을 잊은 채 남지 않고, 로컬 데이터는 편의 때문에 경계를 넘지 않으며, 루프는 끝없는 재시도 대신 설명 가능한 결과로 끝난다.