프로덕션 환경에서 권한 및 도구 접근 제어는 어떻게 하나요?

나는 도구 스키마와 앱 권한, 이 두 곳에서 잠가야 한다고 봐. 모델은 'update_lead_status'처럼 좁은 범위의 도구만 볼 수 있어야 하지만, 진짜 안전장치는 허용된 필드, 범위, 되돌릴 수 없는 작업에 대한 승인 게이트를 강제하는 앱 계층이야. 나는 지원 쪽 에이전트 흐름에 채팅 데이터를 사용하는데, 프롬프트 문구보다 이런 분리가 훨씬 중요했어.

팀들이 나중에, 보통 사고가 터졌을 때 뼈아프게 느끼는 두 가지가 있어. 첫째는 권한 드리프트야. 출시할 때는 권한 범위를 신중하게 설정하지만, 에이전트 워크플로우가 점차 확장되거든. 6개월쯤 지나면 원래 권한 모델에는 없던 세 가지 일을 하고 있을 거야. 뭔가 고장 나기 전까지는 아무도 눈치채지 못하지. 해결책은 권한 검토를 일회성 감사가 아니라 정기적인 배포 아티팩트로 취급하는 거야. 둘째는 감사 가독성인데, 컴플라이언스 팀이 왜 에이전트가 그 이메일을 보냈는지 혹은 그 레코드를 업데이트했는지 물어볼 때...

기존 서비스와 자동화 도구들은 어떻게 인증하고 검증하고 있어? 기존의 보안 및 컴플라이언스 프로세스를 재사용해야지. 어떤 재앙을 걱정하는 거야? 현재는 그런 종류의 재앙을 어떻게 막고 있어?

보모 패턴을 써봐. 에이전트에게 정체성을 부여하는 거야. 도구 호출을 요청하고 준비할 수는 있지만, 도구 실행기에게 넘겨서 에이전트가 그걸 할 수 있는지 없는지 결정하게 해(모든 걸 로그로 남기고). 그 외에는 에이전트를 완전히 가둬버려(네트워크 등). 에이전트를 '한니발 렉터'라고 생각하면 돼. 감옥에 갇힌 천재 범죄자지. 그들의 조언과 속도는 필요하지만, 밖으로 내보내면 안 되잖아.

개발 환경에서는 광범위한 키를 써도 괜찮지만, 프로덕션에서는 위험도에 따라 도구 접근 권한을 나눠야 해. 읽기 권한은 느슨해도 되지만, 쓰기, 전송, 게시가 포함된 작업은 도구별로 범위를 제한한 자격 증명을 사용하거나 사람이 직접 승인하는 단계를 거쳐야 해. 대부분의 에이전트 버그는 성가신 정도지만, 같은 실행 과정에서 레코드를 수정하고 메시지까지 보낼 수 있게 되면 그때부터는 비용이 커지는 거야.

두 계층으로 나누는 걸 추천해. 모델은 넓게 추론할 수 있지만, 실행은 좁고 타입이 지정된 기능들을 통해서만 이루어져야 해. 좋은 프로덕션 도구는 'update_record'나 'send_email' 같은 게 아니야. 스키마 검증, 리소스 제한, 멱등성, 감사 로깅, 드라이런 미리보기가 포함된 'propose_customer_status_change(account_id, from, to, reason)' 같은 거지. 권한 관리는 두 가지 제어를 모두 유지해. 도구 스키마는 가장 안전한 최소 단위의 행동을 정의하고, 애플리케이션/정책 계층은 역할, 객체 범위, 위험도를 체크해...

실행 권한을 추천 권한보다 훨씬 좁게 유지해야 해. 내가 본 가장 큰 문제는 에이전트가 허용된 일을 정확히 수행하긴 하는데, 단지 잘못된 맥락에서 실행하는 경우였어. 위험한 작업에 대한 승인 게이트와 앱 계층의 체크가 도구 스키마만 믿는 것보다 훨씬 효과적이었어.

속도가 느려지는 건 도구를 데이터베이스 작업 단위가 아니라 비즈니스 결과 단위로 범위를 잡을 때 발생해. 효과적인 방법은 테이블당 도구가 아니라 워크플로우당 도구를 하나씩 만드는 거야. 예를 들어 'run_qualification_workflow(lead_id, outcome)'처럼 결과값에 enum 검증을 넣는 거지. 에이전트는 좁은 범위만 보지만, 모든 호출은 범위가 제한되고 감사가 가능하며 되돌릴 수 있어. 스키마 강제는 모델 외부에서 일어나야 해. LLM이 매개변수를 환각하면 실행 전에 호출이 실패하게 만드는 거지. 앱 계층은 누가 리드를 소유하고 있는지, 이게...

이 문제를 해결하는 한 가지 원칙은 도구 스키마를 보안 경계로 취급하지 않는 거야. 그건 모델을 안내할 뿐이고, 모델은 결국 인자를 환각할 테니까. 모든 실질적인 강제 조치는 LLM의 결정과는 독립적으로 실행 계층에 있어야 해. 근본적인 문제는 도구의 세분화가 아니라 광범위한 권한을 가진 키야. 각 에이전트에게 최소 권한 자격 증명을 줘서 환각된 호출이 물리적으로 접근하지 말아야 할 곳에 닿지 않게 해. 그러면 'send_email'이나 'update_record' 같은 범용 도구를 유지해도...

최소 권한 원칙이 시작점이지만, 진짜 질문은 실행과 추천 사이의 선을 어디에 긋느냐는 거야. 실제로 효과가 있었던 건, 되돌리기 어려운 부작용이 있는 모든 작업에 기본적으로 확인 게이트를 두는 거였어. 데이터베이스 쓰기, 외부 이메일, 돈이나 고객 데이터에 관련된 모든 것들 말이야. 에이전트가 제안하고 사람이나 다른 계층이 승인하는 방식이지. 번거롭긴 하지만, 안 그러면 새벽 2시에 에이전트가 환각으로 만든 단계를 프로덕션 데이터베이스에 적용하는 꼴을 보게 될 거야.