에이전트의 계획은 권한이 아닙니다

AI 요약

코딩 에이전트가 프로덕션 버그를 조사하다 보면 저장소를 읽고 로그를 조회한 뒤 pull request를 열 수 있습니다. 조사 도중 다른 서비스의 로그가 필요해질 수도 있지만, 에이전트의 자격 증명은 보통 어떤 작업을 맡았는지, 누가 지시했는지와 무관하게 같은 권한을 줍니다. 글은 작업의 목적과 맥락을 권한 판단에 반영하는 intent-based authorization을 제안합니다. 요청한 접근 범위를 작업을 맡긴 사람이나 시스템의 권한, 에이전트의 역할, 조직 정책과 대조합니다. 고객 지원 에이전트가 도구로 접근할 수 있더라도 HR 기록 조회는 맡은 업무 범위 밖에 둡니다.

작업 단위로 권한을 정하는 방식

결제 서비스에서 오류 알림이 발생하면 오케스트레이터가 조사 계획을 제안합니다. 권한 서비스는 알림을 보낸 주체, 에이전트에 허용된 역할, 외부에서 정한 정책을 확인한 뒤 사고 대응 에이전트에 해당 서비스의 지난 한 시간 로그 읽기 권한을 부여합니다. 조사 중 인증 서비스 로그가 필요해지면 정책에 따라 자동 승인하거나 사람의 승인을 요구할 수 있습니다. 권한이 부여되기 전까지 런타임이 요청을 막습니다. 에이전트는 새 단서를 따라갈 수 있지만 그 단서가 곧 새 권한을 뜻하지는 않습니다.

로그 분석을 다른 에이전트에 넘길 때 수신 에이전트는 검증 가능한 자기 신원을 사용하고 맡은 하위 작업에 필요한 접근만 받습니다. 위임으로 기존 권한 범위를 줄일 수는 있지만 넓힐 수는 없습니다. 작업 맥락과 전달한 주체도 기록합니다. 권한 판단 과정에서는 신뢰할 수 있는 맥락과 신뢰할 수 없는 콘텐츠를 구분해야 합니다. 인증된 알림에 공격자가 작성한 로그 한 줄이 들어 있어도 알림의 출처를 신뢰한다는 이유만으로 그 로그 안의 지시가 다른 시스템 접근을 승인하지는 않습니다.

실행 중 유지할 통제

소프트웨어 팩토리에서는 에이전트가 작업을 수행하는 데 그치지 않고 작업 자체를 제안하기도 합니다. 오케스트레이터가 사고나 보안 스캐너 결과를 살펴보고 티켓이 없는 버그를 골라 에이전트에 조사와 수정 제안을 맡길 수 있습니다. 그러나 유용한 작업을 찾아내는 능력이 필요한 접근 권한까지 임의로 부여할 근거가 되지는 않습니다. 별도의 권한 판단을 두고 에이전트가 실행되는 동안 제한을 강제해야 합니다.

정당한 작업도 잘못 수행할 수 있으므로 접근 권한만으로는 부족합니다. 에이전트가 불필요한 요청을 수천 건 보내거나 검토를 통과한 변경 사항이 프로덕션에서 실패할 수 있습니다. 예산은 자원 소비를 제한하고 검사와 테스트는 변경 사항의 진행 여부를 가립니다. 에이전트가 통제하지 않는 감사 기록은 실제 실행을 남깁니다. 권한을 취소할 수 있으면 문제가 생겼을 때 작업을 멈출 수 있습니다.

Keycard, Docker, Barclays, Socket, Aaron Stanley가 개발한 Software Factory reference architecture는 Agent Baseline을 바탕으로 네 경계를 정의합니다. 신원과 접근, 공급망, 샌드박스, 네트워크가 그 경계입니다. 작업별 접근 통제와 함께 에이전트가 사용하는 소프트웨어, 실행 환경, 도달할 수 있는 시스템을 제한합니다. 글이 제시하는 구조에서는 에이전트가 다음 조사 대상을 고르더라도 접근 권한 결정은 별도의 통제 주체가 맡습니다.

dev.to 반응

• @cekuu35 — intent-based 모델의 방향은 맞고, 인증된 알림에도 공격자가 쓴 로그가 들어갈 수 있다는 지점은 많은 설계가 놓칩니다. 여기에 보완할 점은 권한 서비스가 단일 결정 지점이 되는 만큼 실행 지점에서 우회되면 단일 실패 지점이 된다는 겁니다. 사고 대응 에이전트의 도구가 공유 서비스 자격 증명으로 로그 저장소에 접근한다면 권한 결정은 호출에 붙은 메타데이터일 뿐입니다. 도구가 요청을 조금만 잘못 만들어도 그 자격 증명이 가진 모든 데이터를 읽습니다. 보장을 마지막 지점에서 성립시키려면 오케스트레이터가 아니라 데이터 저장소를 강제 지점으로 삼아야 합니다. 작업별로 범위를 제한한 자격 증명을 쓰거나 작업 또는 테넌트 ID에 연결된 행 정책을 적용하면 권한이 없을 때 클라이언트가 호출하지 않는 데 그치지 않고 결과 행이 0개가 됩니다. 대리 에이전트가 권한 범위를 줄일 때는 범위를 줄인 정보가 원래 권한을 참조하는 값이 아니라 자격 증명 자체에 담겨야 합니다. 그렇지 않으면 대리 에이전트의 자기 신원이 부모 에이전트 권한을 계속 지닐 수 있습니다. 런타임이 권한 부여 전 요청을 막는다는 보장은 저장소도 거부할 때만 입증됩니다. 저는 데이터베이스 쪽에서 권한 없음은 결과 행 0개라는 동작을 확인하는 두 계정 테스트를 유지합니다: github.com/cekuu35/supabase-rls-le...
• @kevin_hall — 같은 원칙은 비용에도 적용되며, 대부분의 에이전트 하네스가 가장 약한 부분입니다. 사용량에 따라 과금하는 데이터 API는 작업과 무관하게 키가 살 수 있는 만큼 에이전트에 제공합니다. 제가 효과를 본 방법은 유료 호출을 사고 대응 에이전트의 로그 접근처럼 다루는 겁니다. 행 개수를 세고 무작위 표본을 보여주는 계획은 무료로 실행하고 실제 지출은 별도 승인을 받습니다. 구체적으로 도구에 행을 반환하지 않는 count 모드를 둡니다. 에이전트가 개수를 보고하면 사람이 행 수 한도를 적은 승인을 작성합니다. PreToolUse hook은 승인이 디스크에 없을 때 유료 호출을 거부합니다. 이 훅이 25,000행 가져오기를 막자 에이전트는 반박하지 않고 100행 표본을 제안했습니다. 모델 바깥에서 비용 조건을 포함해 강제하는 intent-based authorization입니다. 지시가 전혀 없던 세션을 포함한 세 세션 기록입니다: dev.to/kevin_hall/a-spend-gate-for...
• @alexshev — 계획과 권한의 구분이 실제로 작동하려면 권한 부여가 안정적인 작업 ID와 만료 시각에 묶여야 합니다. 위임된 작업의 감사 기록을 원래 권한 부여와 어떻게 연결하면서 대리 에이전트가 부모 에이전트의 더 넓은 토큰을 물려받지 않게 하시겠습니까? 출처 추적 정보가 단순한 로그 필드가 아니라 권한 판단의 입력이 되어야 하는 지점으로 보입니다.
• @mahmaddafzal — 권한 취소는 별도 테스트가 필요합니다. 권한을 부여하고 대리 작업을 대기열에 넣은 다음 권한을 취소하고 대기 작업을 실행해 보세요. 로그에 계속 접근할 수 있나요? 새 계획만 막는 중지 버튼이라면 어제 받은 권한으로 오늘 작업이 계속될 수 있습니다. 제품은 취소가 앞으로의 호출만 막는지 진행 중인 작업도 중단하는지 명시해야 합니다.
• @mattbusel — 위임은 권한을 줄일 수 있지만 늘릴 수 없다는 규칙은 자체 제작한 시스템 대부분이 놓치는 부분입니다. 저희는 짧은 문서로 에이전트 팀을 운영하는데, 다른 에이전트의 메시지는 승인으로 보지 않고 사람이나 권한 시스템만 승인 주체로 삼는 규칙이 가장 잘 작동했습니다. 신뢰할 수 없는 로그 한 줄이 작업 에이전트가 아니라 오케스트레이터에게 지시하는 문장으로 쓰인 경우는 어떻게 처리하시나요?
• @chrissellers — 위임은 권한을 줄일 수 있지만 늘릴 수 없다는 문장은 제가 직접 만든 시스템에서 가장 자주 빠지는 규칙입니다. 실제로는 하위 에이전트가 부모의 토큰 전체를 물려받는 일이 흔합니다. 그게 구현하기 가장 쉽고 두 번째 위임부터는 작업 맥락도 사라집니다. 제가 더할 점은 토큰 만료 시점이 아니라 작업 종료 시점에 권한을 만료시키는 겁니다. 조사가 끝나면 기반 자격 증명이 몇 시간 더 유효하더라도 로그 접근은 종료해야 합니다. 단서가 더 이상 유효하지 않으면 어떻게 처리하나요? 에이전트가 인증 서비스 로그를 요청한 뒤 추적이 끊기면 그 권한은 작업이 끝날 때까지 열려 있나요, 아니면 더 짧은 별도 만료 시간이 있나요?

원문: dev.to / 번역·요약: Trawling