가드레일이 작동했음을 증명하기: LangChain 에이전트 실행을 리플레이 번들로 변환하는 방법

AI 에이전트 사고에 대해 묻는 CISO(최고정보보호책임자)는 그 에이전트가 무엇을 해야 했는지 묻지 않습니다. 그들은 이 시점에, 이 정책에 대해 실제로 무엇을 했는지 묻습니다. 모든 서버의 애플리케이션 로그를 검색하는 것으로 답변할 수는 없습니다. 상사들이 답을 원할 때는 연구 프로젝트를 할 시간이 아닙니다.

Cognous's Open Control Stack은 이러한 질문에 며칠이 아닌 몇 분 만에 답할 수 있도록 존재합니다. 이는 에이전트 거버넌스를 네 가지 계층으로 구성합니다: 에이전트가 무엇을 할 수 있는지 선언하고, 런타임에서 실제로 무엇을 하는지 제어하며, 특정 실행을 나중에 리플레이(replay)하고, 그 결과를 검토자가 조치할 수 있는 증거로 패키징하는 것입니다.

Wiring the Agent Action Manifest into LangChain에서는 첫 번째 계층, 즉 LangChain 에이전트가 어떤 행동을 취할 수 있는지 선언하는 매니페스트(manifest)를 다루었습니다. 여기서 명시되지 않은 모든 것은 '에스컬레이션'이라는 기본 자세로 처리됩니다. Wiring LangChain into the Agent Control Plane에서는 두 번째 계층, 즉 이 모든 결정을 RunRecorder를 통해 실제 create_agent 루프 주변에 wrap_tool_call 미들웨어로 라우팅하여 실행이 발생하는 대로 실제 기록을 축적하는 방법을 다루었습니다.

그 기록은

이전 두 게시물에서 다룬 데이터 파이프라인 에이전트는 내부 분석 데이터베이스에 대한 스키마 변경 사항을 유지하며, Control Plane 게시물에서 구축된 동일한 매니페스트와 manifest_guard 미들웨어를 사용합니다. 이 매니페스트는 두 가지 액션을 선언합니다: 검토가 필요 없는 schema_add_column과 테이블 삭제(table drop)로, 이는 파괴적이고 되돌릴 수 없기 때문에 인간의 승인이 필요한 경우입니다. 세 번째 호출인 테이블 이름 변경은 아예 선언되지 않았습니다.

에이전트는 실제 create_agent 루프를 거치며, 가드(guard)는 모든 도구 호출이 실행되기 전에 이를 가로챕니다:

agent = create_agent(
    model=fake_model,
    tools=[schema_add_column, table_drop, schema_rename_table],
...

실제 agent-control-plane 및 langchain 패키지에 대해 실행하면 다음과 같은 결과가 나옵니다:

tool result -> added column loyalty_tier (text) to customers
tool result -> block: Tool 'table_drop' is explicitly blocked in this frame.
tool result -> escalate: Tool 'schema_rename_table' is not in the allowed-tools list and requires manual review.
...

schema_add_column은 선언되었고, 검토가 필요 없으며, 실행에 필요한 쓰기 권한을 가지고 있기 때문에 허용됩니다. table_drop은 전면적으로 차단됩니다: 이는 선언되었지만, 그 approval_required 검토 모드가 Control Plane 자체의 차단 목록에 포함되어 있어 게이트(gate)가 실행되기 전에 막아버립니다. 반면 schema_rename_table은 다른 이유로 에스컬레이트됩니다: 이는 매니페스트에 아예 없기 때문에, 프레임의 허용된 목록에 포함되지 않았고, 게이트 자체의 기본 기능이 아무도 사전에

LangChain의 역할은 여기서 끝납니다. agent.invoke()가 반환되면 에이전트 루프도, 도구 호출도, 메시지도 남지 않고 디스크에 놓인 일반 JSON 내보내기 파일만 남습니다. 이 시점부터 모든 것은 그 내보내기를 검증(validate), 마스킹(redact), 서명(sign)하고 확인하는 기록으로 취급하며, 이는 다른 어떤 프레임워크가 생성한 실행 기록을 처리할 때와 동일합니다.

아직 번들(Bundle)이 아닌 번들

Cognous의 Replay 레이어인 arb는 휴대 가능한 리플레이 번들(replay bundle)에 대한 자체 스키마인 AgentReplayBundle을 정의합니다. 이는 Control Plane과 독립적으로 존재합니다. 이러한 독립성이 바로 리플레이 레이어의 핵심입니다. 즉, 그 기원과 관계없이 어떤 번들의 실행 기록이든 검증하고, 마스킹하며, 서명하고, 확인할 수 있다는 것입니다. 하지만 이로 인해 복잡한 문제가 발생합니다. Control Plane 자체의 내보내기가 arb의 스키마와 일치하지 않는다는 점입니다. 필드가 서로 맞지 않습니다:

• 식별자(Identifier): replay_bundle_id 대 bundle_id
• 제안(Proposals): actions 대 action_proposals
• 결정(Decisions): decisions 대 policy_decisions

이는 어느 저장소의 버그가 아닙니다. Control Plane의 내보내기는 자체 기록기 상태에 대한 내부 스냅샷입니다. 반면, arb의 스키마는 어떤 생산자에게도 오래 지속되도록 설계된 공개적인 상호 교환 형식(interchange format)입니다. 따라서 임시방편이 아니라 그 둘 사이의 매핑 단계가 예상됩니다:

arb_bundle = {
    "bundle_id": cp["replay_bundle_id"],
    "bundle_version": "0.1",
...

매핑을 적용하자 파일이 깔끔하게 검증됩니다:

$ arb validate pipeline_agent_bundle.json
VALID  bundle_id=138eb7ca-3da9-4de8-b197-57062d8fcf00  issues=1
  WARNING W012: signature_metadata is missing.

남은 경고는 하나입니다. 번들에 아직 서명이 되어 있지 않다는 것입니다.

유효한 상태에서 핸드오프 준비 완료까지

유효한 번들이라 할지라도 여전히 내부 데이터베이스 실행 기록의 원시 페이로드(raw payloads), 대상, 그리고 이유를 포함하고 있습니다. 이 정보가 데이터 플랫폼 팀 외부로 전달되기 전에, 마스킹 과정이 해당 정보를 제거합니다:

모든 액션의 payload는 이 명령을 실행할 때마다 무조건적으로 마스킹됩니다. --targets, --reasons, 그리고 --final-output은 선택적 추가 옵션입니다:

• --targets: 모든 액션의 target 필드를 마스킹합니다.
• --reasons: 모든 액션 제안, 정책 결정(policy decision), 정책 추적 규칙(policy trace rule), 그리고 차단된 액션에 대한 reason 필드를 마스킹합니다.
• --final-output: 실행의 final_output을 마스킹합니다.

변경되지 않고 남아있는 것은 액션 ID, 타임스탬프, 도구 이름(tool names), 그리고 결정 결과 자체입니다. 검토자는 특정 정책 버전 하에서 특정 시간에 table_drop이 차단되었다는 사실은 여전히 볼 수 있지만, 테이블 이름은 볼 수 없습니다.

번들(bundle)의 status 필드는 complete에서 redacted로 변경되며, 여전히 유효성 검사를 통과합니다:

$ arb validate pipeline_agent_bundle.redacted.json
VALID  bundle_id=138eb7ca-3da9-4de8-b197-57062d8fcf00  issues=1
  WARNING W012: signature_metadata is missing.

서명(Signing)은 마스킹 이후에 이루어지며, 그 이전에 이루어지는 것이 아닙니다. 이는 검토자가 열게 되는 정확한 번들이 데이터 플랫폼 팀이 생성했으며, 그 이후로 수정되지 않았음을 증명합니다.

$ arb sign pipeline_agent_bundle.redacted.json --secret pipeline-signing-secret --key-id data-platform-signing-key --out pipeline_agent_bundle.signed.json
Signed bundle written to pipeline_agent_bundle.signed.json

...

일단 서명되면, 해당 파일은 유효성 검사를 할 수 없습니다. arb verify가 서명된 번들을 읽도록 설계된 유일한 명령입니다. 이 서명된 파일을 편집하는 대상이 아니라 전달되는 대상으로 취급해야 합니다.

실제로 증명하는 것

이 에이전트는 세 가지 행동을 제안했습니다. 정책은 이 정확한 프레임과 권한 집합 하에서 각각의 행동을 평가했습니다. table_drop은 검토 요구 사항 때문에 에이전트 호출이 평가되기도 전에 차단 목록에 올라가서 실행될 기회조차 없었습니다. 시그니처는 이 정확한 번들이 데이터 플랫폼 팀이 생성한 이후로 변경되지 않았음을 증명합니다.

재생(Replay) 계층의 요점은 이것입니다. 모든 에이전트 워크플로우는 자신이 무엇을 할 예정이었는지뿐만 아니라, 실제로 무엇을 했는지에 대한 서명이 되어 신뢰할 수 있는 아티팩트를 생성한다는 것입니다. 서비스 중단(outage), 근본 원인 조사(root cause investigation), 또는 사후 검토(postmortem) 중에 이 기록은 에이전트의 행동을 기억이나 애플리케이션 로그 조각들로부터 재구성하는 것과, 정확히 무슨 일이 일어났는지 서명되어 있고 요청하는 사람에게 바로 전달할 수 있도록 꺼내는 것 사이의 차이를 만듭니다.

Agent Replay Bundle을 복제하고, 저장소에 있는 예시 번들 또는 사용자의 LangChain 에이전트 내보내기(exports)를 대상으로 arb를 시도해 보세요. Agent Replay Bundle에 대한 자세한 내용은 cogno.us을 참조하세요.

다음 부분은 해당 번들을 가져와 비즈니스 검토자가 JSON을 만지지 않고 읽을 수 있는 형태로 변환하는데, 이것이 바로 Agent Governance Evidence Pack입니다.