에이전트의 권한 제한하기

접근 권한을 부여하기 전에 작업을 설명하세요

코드를 읽는 에이전트와 서비스를 배포하는 에이전트에는 서로 다른 권한이 필요합니다. 같은 제품이 두 작업을 모두 지원한다는 이유로 두 종류의 권한을 모두 부여하지 마세요.

작업, 리소스, 조건이라는 세 부분으로 권한을 정하세요. 가상의 보고서 수정 작업에서 에이전트는 작업이 진행되는 동안 하나의 기능 브랜치에 쓸 수 있습니다. 승인된 저장소 파일을 읽을 수 있습니다. 프로덕션 데이터나 저장소 보호 규칙은 수정할 수 없습니다.

구체적인 강제 방법은 도구에 따라 달라집니다. 토큰에 브랜치 제한을 지정할 수 없다면 추가적인 저장소 통제나 실행 서비스를 사용하세요. 여전히 남아 있는 권한을 정확히 문서화하세요.

프롬프트는 접근 통제 시스템이 아닙니다. 실행 구성 요소는 요청된 작업과 대상을 현재 권한과 대조해야 합니다. 모델이 이미 승인을 받았다고 말하는 것만으로 승인된 것으로 처리하면 안 됩니다.

AWS는 적절한 워크로드에 제한된 권한과 임시 자격 증명을 사용하도록 권장합니다. OWASP도 에이전트와 도구에 비슷한 최소 권한 원칙을 적용합니다. 이 원칙은 실제 ID 및 실행 시스템에 구현해야 합니다. AWS IAM 지침, OWASP 에이전트 지침.

지원되는 경우 수명이 짧은 자격 증명을 사용하세요. 관련 없는 비밀 정보는 환경에 넣지 마세요. 저장소를 읽기만 하는 작업에 개발자 셸의 프로덕션 데이터베이스 비밀번호가 전달되어서는 안 됩니다.

변경 준비 승인이 배포 승인까지 의미하지는 않습니다. 배포 결정에는 아티팩트, 대상 환경, 관련 조건을 명시해야 합니다. 이 중 하나가 바뀌면 이전 결정이 더는 유효하지 않을 수 있습니다.

안전한 데이터베이스 읽기를 제안한 뒤 승인을 받고는 다른 쿼리를 실행하는 에이전트를 생각해 보세요. 유용한 승인 체계는 실제로 실행되는 작업을 확인합니다. 대상이 정해지지 않은 일반적인 ‘계속’ 메시지는 이런 차이를 가릴 수 있습니다.

ID와 실행 능력도 구분하세요. 어떤 사람이나 워크로드가 실행을 시작했는지 기록하세요. 작업이 실행되는 시점에도 시작 주체의 ID에 권한이 있는지 검증하세요. 사람의 접근 권한을 제거했을 때 대기 중인 작업에 어떤 영향이 있는지 명확해야 합니다.

성공 경로만 검증하지 마세요. 격리된 테스트 환경에서 허용된 리소스 범위 밖의 작업을 시도하세요. 실행 시스템이 거부하는지 확인하세요. 자격 증명을 기록하지 않으면서 감사 이벤트를 살펴보세요.

그런 다음 취소나 자격 증명 만료를 테스트하세요. 어떤 작업이 즉시 멈추고 어떤 작업은 완료될 수 있는지 확인하세요. 중지 버튼이 다른 시스템에 이미 도달한 작업을 반드시 되돌리는 것은 아닙니다.

작업과 함께 간단한 권한 기록을 보관하세요. 담당자, 승인된 범위, 실제 통제, 거부 테스트, 만료 시점을 포함하세요. 그러면 나중에 작업 흐름을 개선할 만큼 구체적인 검토를 할 수 있습니다.