에이전트 도구에 지금 즉시 공급망 제어가 필요합니다
통제되지 않은 에이전트 도구가 있는 저장소를 더 나은 프롬프트가 구해줄 수는 없습니다.
코딩 에이전트는 진화했습니다. 이제 더 이상 채팅창 안에만 머물지 않습니다. 지침을 읽고, 도구를 호출하며, 마켓플레이스에 연결합니다. 파일, 풀 리퀘스트(PR), 내부 API에 접근하는 워크플로우 내에서 실행됩니다.
이제 질문은 "모델이 충분히 똑똑한가?"가 아닙니다.
진짜 질문은 다음과 같습니다:
- 누가 이 도구를 워크플로우에 허용했는가?
- 이 도구가 어디까지 접근할 수 있는가?
- 접근 권한이 변경되었을 때 어떻게 알아챌 것인가?
이것은 프롬프트 엔지니어링이 아닙니다. 이것은 공급망 제어(supply-chain control)입니다.
잘못된 제안은 그 자체로도 문제지만, 셸(shell), 저장소 토큰(repo token) 또는 패키지 설치기에 대한 접근 권한을 가진 잘못된 제안은 차원이 다른 문제입니다. 모델은 이제 단순히 텍스트를 생성하는 것에 그치지 않습니다. 모델은 실행 능력(capability)의 전면에 서 있습니다.
에이전트 도구를 의존성(dependencies)처럼 취급하십시오.
느낌만으로 패키지를 설치하지는 않습니다. 레지스트리, 유지 관리자, 그리고 버전을 확인합니다. 에이전트 도구도 똑같은 의구심을 가져야 합니다.
에이전트 도구가 저장소, 파일 시스템 또는 네트워크에 영향을 미칠 수 있다면 다음 규칙을 따르십시오:
• 에이전트 도구 인벤토리를 유지하십시오. 출처와 소유자를 문서화하십시오. • 에이전트 지침에 버전을 부여하십시오. 지침의 변경 사항을 CI 설정 변경과 동일하게 취급하십시오. • 도구 출처를 허용 목록(allowlist)에 등록하십시오. 알려진 마켓플레이스를 사용하십시오. • 읽기 도구와 쓰기 도구를 분리하십시오. 검색 도구는 편집 도구와 다른 권한이 필요합니다. • 도구 호출을 명확하게 기록하십시오. 사람이 실제로 읽을 수 있는 감사 추적(audit trail)이 필요합니다. • 위험한 기능은 명확하게 드러나게 하십시오. 셸 접근 및 파일 시스템 쓰기 권한은 검토 시 눈에 띄어야 합니다. • 비활성화 경로를 만드십시오. 도구가 실패할 경우 즉시 제거할 수 있어야 합니다.
목표는 우연한 신뢰에서 의도적인 신뢰로 전환하는 것입니다.
다음 세대의 큰 우위는 가장 화려한 프롬프트를 가진 팀에게 돌아가지 않을 것입니다. 지루한 인벤토리, 지루한 허용 목록, 그리고 지루한 로그를 가진 팀에게 돌아갈 것입니다.
그것이 실제 프로젝트에서 살아남는 방식입니다.
Source: https://dev.to/hefty_69a4c2d631c9dd70724/agent-tools-need-supply-chain-controls-now-1co2
Optional learning community: https://t.me/GyaanSetuAi