에이전트가 오작동할 때, 어떤 에이전트가 그랬는지 알고 계십니까?
에이전트가 건드려서는 안 될 레코드를 삭제합니다. 잘못된 테넌트에게 메시지를 보냅니다. API를 루프(loop)로 호출하여 비용을 급증시킵니다.
장애 발생 10분 후, 당신은 한 가지 질문을 던지게 됩니다. "어떤 에이전트가 이 일을 저질렀는가?"
모른다면 해결할 수 없습니다. 빌드를 중단할 수도, 오류를 감사(audit)할 수도, 실수로부터 배울 수도 없습니다.
이것은 정체성(identity)의 문제입니다.
대부분의 팀은 에이전트의 행동을 숨기는 세 가지 패턴에 직면합니다:
- 공유 서비스 계정: 10개의 에이전트가 하나의 자격 증명 세트를 사용합니다. 로그에는 모든 작업이 동일하게 나타납니다.
- 사용자 자격 증명: 에이전트가 사용자의 로그인을 사용합니다. 로그에는 에이전트의 이름이 아닌 사용자의 이름이 표시됩니다. 이는 심각한 보안 리스크를 초래합니다.
- 사이런트 드리프트(Silent drift): 서로 다른 두 빌드가 동일한 이름을 사용합니다. 하나는 새로운 모델이나 새로운 프롬프트를 사용하지만, 로그에는 동일한 정체성으로 표시됩니다.
이를 해결하려면 다음 단계를 따르십시오:
모든 에이전트에 고유한 정체성을 부여하십시오. 사용자 자격 증명을 사용하지 마십시오. 공유 계정을 사용하지 마십시오. 에이전트는 자기 자신으로서 인증해야 합니다.
모든 작업에 다음 6가지 특정 필드를 기록하십시오:
- 책임 주체(Accountable party): 이 에이전트에 대한 책임은 누구에게 있습니까?
- 운영 소유자(Operational owner): 누가 매일 이를 유지 관리합니까?
- 테넌트(Tenant): 어떤 고객을 위한 것입니까?
- 에이전트 유형 ID(Agent-type-id): 이것은 어떤 특정 빌드입니까?
- 에이전트 인스턴스 ID(Agent-instance-id): 이것은 어떤 특정 실행(run)입니까?
- 트레이스 컨텍스트(Trace context): 호출 체인(call chain) 중 어디에 위치합니까?
버전 관리에 해시(hash)를 사용하십시오. 에이전트 이름을 "support-agent-v2"와 같이 지정하지 마십시오. 시스템 프롬프트를 변경하더라도 이름은 그대로 유지되지만 동작은 변합니다. 대신 콘텐츠 해시를 사용하십시오. 컨테이너 이미지, 프롬프트, 모델 및 설정을 기반으로 해시를 생성하십시오. 코드 한 줄만 변경해도 ID가 변경됩니다. 이를 통해 사이런트 드리프트를 가시화할 수 있습니다.
계보(lineage)를 기록하십시오. 에이전트는 하위 에이전트를 생성합니다. 어떤 부모 에이전트가 하위 에이전트를 시작했는지 기록해야 합니다. 또한 부모가 하위 에이전트에게 전달한 프롬프트도 기록해야 합니다. 이것이 주입된 지시 사항(injected instructions)이나 오염된 데이터(poisoned data)를 찾아낼 수 있는 유일한 방법입니다.
정체성은 여러분의 복구 기반(recovery surface)입니다. 이를 통해 킬 스위치(kill switch)를 사용하고 감사 추적(audit trail)을 구축할 수 있습니다. 장애가 발생하기 전에 이를 설정해야 합니다. 위기 상황에서 정체성을 추가하는 것은 너무 늦습니다.
지금 바로 로그를 확인하십시오. 한 시간 전의 작업을 살펴보십시오. 해당 작업을 수행한 특정 빌드의 이름을 말할 수 있습니까? 만약 그렇지 못하다면, 메워야 할 격차가 있는 것입니다.
Source: https://dev.to/brennhill/when-your-agent-does-something-bad-can-you-tell-which-agent-did-it-37a2
Optional learning community: https://t.me/GyaanSetuAi