에이전트가 해서는 안 될 행동을 합니다. 건드릴 권한이 없는 레코드를 삭제하거나, 잘못된 테넌트(tenant)에게 메시지를 보내거나, 비용이 급증할 때까지 API를 무한 루프로 호출합니다. 사고 발생 후 첫 10분 동안 가장 중요한 유일한 질문이 던져집니다. 어떤 에이전트가 이 일을 저질렀는가?

만약 정직한 답변이 "확실하지 않습니다"라면, 그 이후의 모든 과정이 더 어려워집니다. 이름을 알 수 없는 것은 격리할 수 없습니다. 식별할 수 없는 빌드(build)는 중단시킬 수 없습니다. 감사(audit)를 할 수 없으며, 재발을 방지할 만큼 충분히 학습할 수도 없습니다.

좌절스러운 점은 이것이 대개 로깅(logging)의 문제가 아니라 식별(identity)의 문제라는 것입니다. 로그는 존재합니다. 다만 특정 에이전트를 지목할 만큼 충분한 정보를 담고 있지 않을 뿐입니다.

행동의 원인을 규명할 수 없는 이유

두 가지 패턴이 대부분의 에이전트 행동을 특정하기 어렵게 만듭니다.

첫 번째는 **공유 서비스 계정(shared service accounts)**입니다. 열 개의 에이전트가 하나의 자격 증명(credentials) 세트를 공유하므로, 모든 행동이 동일한 행위자로 나타납니다. IdP(Identity Provider)는 하루에 수만 번 "service-account-prod가 X를 수행함"이라고 기록하지만, 문제를 일으킨 에이전트와 그렇지 않은 나머지 아홉 개의 에이전트를 분리할 방법이 없습니다.

두 번째는 사용자의 자격 증명으로 실행되는 에이전트입니다. 에이전트는 실행한 사용자의 모든 권한을 상속받으며, 로그상에서는 해당 행동이 사람이 직접 수행한 것과 구별되지 않습니다. 이제 귀하는 식별(attribution) 문제와 더불어 폭발 반경(blast-radius) 문제까지 떠안게 됩니다. 에이전트가 사람이 할 수 있는 모든 일을 할 수 있기 때문입니다.

더 미묘한 버전도 있습니다. 예를 들어, 에이전트의 서로 다른 두 빌드가 모두 동일한 계정으로 인증한다고 가정해 봅시다. IdP에는 이름이 같고 토큰도 같습니다. 로그상으로는 동일해 보이지만, 하나는 시스템 프롬프트(system prompt)가 변경되었고, 더 최신 모델을 사용하며, 다른 도구 설정(tool config)을 가지고 있습니다. 그중 하나가 잘못되었을 때, 로그만으로는 어떤 빌드가 실행 중이었는지 알 수 없습니다.

에이전트에게 고유한 식별성을 부여하십시오

첫 번째 단계: 에이전트에게 실행 사용자와 분리된 고유한 식별성(identity)을 부여하십시오. 사람의 자격 증명도 아니고, 공유 서비스 계정도 아닙니다. 에이전트만의 것이어야 합니다.

이것은 다른 모든 것들이 기반을 두는 토대입니다. 일단 에이전트가 자기 자신으로서 인증(authenticate)을 마치고 나면, 에이전트가 취하는 모든 행동은 기록상에서 최소한 '그 자신의' 행동이 됩니다. 즉, 사람으로부터 빌려온 것도 아니고, 아홉 명의 형제와 뒤섞인 것도 아닙니다.

모든 행동에 6가지 필드를 찍으십시오

IdP(Identity Provider)에서의 식별성(identity)은 필요조건이지만 충분조건은 아닙니다. 행동 그 자체에 나중에 재구성할 수 있을 만큼 충분한 컨텍스트(context)가 포함되어 있어야 합니다. 모든 행동에 다음 6가지 필드를 찍으십시오:

• 책임 당사자 (Accountable party) — 이 에이전트가 존재하는 것에 대해 책임을 지는 주체.
• 운영 소유자 (Operational owner) — 실제로 이를 매일 실행하고 유지 관리하는 주체.
• 테넌트 (Tenant) — 이 행동이 누구를 대신하여 수행되었는지 나타내는 고객.
• 에이전트 유형 ID (Agent-type-id) — 에이전트의 어떤 빌드(build)인지.
• 에이전트 인스턴스 ID (Agent-instance-id) — 어떤 특정 실행(run)인지.
• 트레이스 컨텍스트 (Trace context) — 호출 그래프(call graph) 내에서 이 행동이 어디에 위치하는지.

이 필드들은 종합적으로 다음 질문에 답합니다: 누가 책임지는가, 누가 운영하는가, 어떤 고객을 위한 것인가, 어떤 빌드인가, 어떤 실행인가, 그리고 호출 체인(chain of calls) 중 어디에 있는가. 대부분의 시스템은 이 중 한두 가지만 캡처합니다. 보통 테넌트(tenant)와 아마도 트레이스 ID(trace id) 정도입니다. '한두 개'와 '여섯 개 모두' 사이의 간극이 바로 사고의 원인을 규명할 수 없게 만드는 바로 그 간극입니다.

agent-type-id를 이름이 아닌 콘텐츠 해시(content hash)로 만드십시오

조용히 문제를 일으키는 필드는 바로 agent-type-id입니다. 왜냐하면 누구나 생각할 수 있는 구현 방식은 누군가가 할당한 이름을 사용하는 것이기 때문입니다. support-agent-v2라고 이름을 붙여 배포한다고 가정해 봅시다. 3주 후 누군가 모델을 교체하고, 시스템 프롬프트(system prompt)를 수정하고, 다시 배포합니다. 이름은 여전히 support-agent-v2입니다. 이름은 바뀌지 않았지만, 행동은 바뀌었습니다. 로그에서는 보이지 않는 조용한 드리프트(drift)가 발생한 것입니다.

대신 agent-type-id를 **콘텐츠 해시 (content hash)**로 만드십시오. 에이전트가 어떻게 행동하는지를 결정하는 모든 요소에 대해 해시를 생성하십시오: 컨테이너 이미지(container image), 하네스(harness), 시스템 프롬프트(system prompt), 모델 식별자(model identifier), 설정(config) 등이 포함됩니다. 컨테이너 다이제스트(container digest)와 유사하지만, 이미지를 넘어 행동을 형성하는 모든 요소로 확장된 개념입니다.

당신이 원하는 속성은 어떠한 입력이라도 변경되면 ID가 바뀌는 것입니다. 모델을 교체하면 해시(hash)가 변경됩니다. 시스템 프롬프트(system prompt)의 한 줄을 수정하면 해시가 변경됩니다. 변경된 빌드(build)는 더 이상 이전 빌드인 척 위장할 수 없습니다. 자동으로 새로운 ID를 부여받기 때문입니다. 드리프트(Drift)는 더 이상 조용히 일어나지 않으며, 로그에 새로운 agent-type-id로 나타나게 됩니다.

부모-자식 계보(lineage) 추적

에이전트는 하위 에이전트(sub-agent)를 생성하며, 실제로 많은 문제가 발생하는 지점은 바로 이 하위 에이전트입니다. 따라서 계보를 기록하십시오. 어떤 하위 에이전트가 어떤 부모 아래에서 실행되었는지, 그리고 — 사람들이 놓치는 부분인데 — 부모가 하위 에이전트에게 전달한 프롬프트를 기록해야 합니다.

부모가 전달한 그 프롬프트는 주입된 지시(injected instruction)가 가시적으로 드러나는 유일한 지점인 경우가 많습니다. 오염된 도구 결과(poisoned tool result)나 조작된 상위 응답(upstream response)은 부모가 아래로 전달하는 지시로 변질됩니다. 만약 이 전달 과정을 캡처하지 않았다면, 주입(injection)은 아무런 흔적을 남기지 않으며 하위 에이전트가 마치 스스로 잘못된 행동을 하기로 결정한 것처럼 보이게 됩니다.

정체성(Identity)은 복구 표면(recovery surface)이다

내재화해야 할 사실은 이것입니다: 정체성은 규정 준수(compliance)를 위해 수행하는 서류 작업이 아닙니다. 그것은 바로 **복구 표면(recovery surface)**입니다. 격리(Containment), 킬 스위치(kill switch), 감사 추적(audit trail), 그리고 사후 학습은 모두 특정 에이전트 빌드 및 실행(run)에 행위를 귀속시킬 수 있는지 여부에 달려 있습니다.

그리고 이는 사고가 발생하기 _전_에 반드시 마련되어 있어야 합니다. 사고가 발생한 후에 추가된 정체성은 현재 겪고 있는 사고를 해결하기에는 너무 늦습니다. 다음번을 위해 도구를 갖출 수는 있겠지만, 눈앞에 닥친 사고는 원인을 규명할 수 없는 상태로 남게 됩니다.

BRACE 에이전트 가이드에서는 필드 정의와 이것들이 더 넓은 프레임워크에 어떻게 부합하는지에 대해 더 자세히 다룹니다.

마지막으로 여러분에게 던지는 솔직한 질문 하나: 한 시간 전 에이전트가 수행한 작업의 로그를 불러와 보십시오. 그 작업을 수행한 특정 빌드(build)의 이름을 말할 수 있습니까? 만약 그렇지 않다면, 그것이 바로 공백이며, 그 공백이 절실해지기 전에 메울 가치가 있는 부분입니다.