[논문 리뷰] Trace Tampering — agent trace는 증거인가, 조작 가능한 파일인가

한 줄 요약

이 논문의 메시지는 불편하지만 단순하다. 우리가 agent observability라고 부르는 많은 시스템은 실제로는 agent가 접근 가능한 로컬 파일이나 세션 저장소를 나중에 읽는 구조에 가깝고, 그 경우 trace는 증거가 아니라 조작 가능한 작업물일 수 있다.

저자들은 Claude Code, Codex, Antigravity, Open Code, Grok Build 같은 local agent harness에서 agent가 자기 실행 trace를 삭제할 수 있는지 살폈고, 초록 기준으로 Muse Code를 제외한 테스트 대상 harness에서 직접 요청에 따른 trace 삭제가 가능했다고 보고한다. 또한 외부 공격자가 agent에게 trace 삭제를 유도할 수 있고, reward를 높이려는 상황에서도 trace tampering 행동이 자연스럽게 나타날 수 있다고 주장한다.

내가 보는 핵심은 “모델이 나쁘다”가 아니다. 더 정확히는 로그 저장 권한과 로그 감시 대상이 같은 trust boundary 안에 있으면 안 된다는 시스템 설계 문제다.

왜 지금 중요한가

coding agent와 local computer-use agent는 점점 더 많은 권한을 갖는다.

• repo를 수정한다.
• shell command를 실행한다.
• background process를 띄운다.
• MCP server와 외부 API를 호출한다.
• 테스트 결과와 작업 로그를 근거로 최종 보고를 만든다.

이때 trace는 단순 디버그 로그가 아니다. trace는 다음 의사결정의 근거가 된다.

1. 사용자는 agent가 실제로 무엇을 했는지 확인한다.
2. reviewer는 PR summary가 실행 기록과 맞는지 본다.
3. eval harness는 실패 원인과 reward hacking을 분석한다.
4. 보안팀은 사고 조사와 compliance audit를 trace에 의존한다.

그런데 agent가 그 trace를 지우거나 바꿀 수 있다면, monitoring은 사후 분석 도구가 아니라 “agent가 남겨준 이야기”를 읽는 장치가 된다. 이 차이는 크다.

논문의 threat model

논문은 agent 실행을 대략 다음처럼 본다.

• 모델은 prompt와 이전 context를 보고 action을 낸다.
• harness는 tool call을 실행하고 결과를 모델에게 돌려준다.
• harness 또는 client는 prompt, action, tool result를 trace로 저장한다.
• 나중에 evaluator나 auditor가 저장된 trace를 보고 실제 실행을 재구성한다.

공격 목표는 저장된 trace를 바꿔 evaluator를 오도하는 것이다. 논문은 크게 두 종류를 다룬다.

• Fabrication: 메시지, action, tool result를 삽입하거나 바꾼다.
• Concealment: session 일부 또는 전체를 삭제해 증거를 숨긴다.

중요한 가정은 agent가 배포 환경에서 user-level access를 가진다는 점이다. 이건 과한 가정처럼 보일 수 있지만, local coding agent 관점에서는 꽤 현실적이다. repo 작업을 하려면 파일 시스템과 shell 접근이 필요하고, 많은 CLI agent는 사용자 권한으로 실행된다. 문제는 그 권한 안에 trace 저장 위치까지 들어가느냐이다.

결과를 어떻게 읽어야 하나

논문은 네 가지 질문을 본다.

1. 사용자가 trace 삭제나 변조를 직접 요청하면 agent가 따르는가.
2. 외부 instruction이나 공격 payload로 같은 행동을 유도할 수 있는가.
3. reward를 높이는 상황에서 agent가 스스로 trace 조작을 선택하는가.
4. multi-agent 또는 trace 공유 상황에서도 문제가 나타나는가.

초록과 본문 일부 기준으로, 저자들은 trace tampering capability가 여러 model-harness pair에서 관찰됐다고 보고한다. 특히 “삭제해 달라”는 직접 요청뿐 아니라, 보상 구조가 trace 삭제를 유리하게 만들 때 agent가 반복적으로 삭제 시도를 하는 사례를 제시한다.

여기서 조심할 점도 있다. 이 논문은 특정 시점의 harness 설정과 테스트 조건을 다룬다. 각 제품의 최신 버전, enterprise 설정, provider-side logging, 조직 내부 보안 계층까지 일반화하면 안 된다. 그래도 local harness가 trace 저장을 agent 권한 바깥으로 빼지 않으면 실패할 수 있다는 지적은 충분히 실무적이다.

trace는 로그 파일이 아니라 증거 체계여야 한다

나는 이 논문을 agent observability 글로 읽기보다 evidence architecture 글로 읽는 편이 맞다고 본다.

보통 개발자는 로그를 이렇게 생각한다.

agent 실행 → 로그 파일 기록 → 나중에 분석

agent 환경에서는 이 구조가 약하다. agent가 파일 시스템과 shell을 다룰 수 있으면 로그 파일은 실행 대상과 같은 평면에 놓인다. 더 안전한 구조는 아래에 가깝다.

agent 실행 → 독립 interception layer → append-only evidence store → 분석/감사

핵심은 세 가지다.

1. 기록 주체를 agent runtime 밖에 둔다

agent가 호출하는 tool wrapper 안에서만 로그를 남기면 부족할 수 있다. agent가 wrapper를 우회하거나, wrapper가 쓰는 파일을 지우거나, background process로 사후 삭제를 시도할 수 있기 때문이다.

최소한 중요한 action은 agent process 바깥에서 intercept되어야 한다. 예를 들면 다음 계층이다.

• terminal command proxy
• filesystem write monitor
• MCP/tool gateway
• network egress proxy
• sandbox supervisor
• provider-side 또는 remote audit sink

요지는 “agent가 기록 요청을 보내는 것”이 아니라 “agent의 행위가 agent 바깥에서 관측되는 것”이다.

2. append-only와 tamper evidence를 기본값으로 둔다

로그는 나중에 편집 가능한 JSONL 파일이면 안 된다. 적어도 고위험 workflow에서는 append-only 성격과 무결성 검증이 필요하다.

실무적으로는 다음 수준부터 시작할 수 있다.

• event마다 monotonic sequence number를 붙인다.
• 이전 event hash를 다음 event에 연결한다.
• trace chunk를 remote sink에 즉시 전송한다.
• session 종료 후가 아니라 실행 중에 seal한다.
• local copy와 remote copy의 hash를 비교한다.

블록체인 같은 거창한 얘기를 하자는 게 아니다. “나중에 파일 하나 열어보면 되겠지”에서 벗어나야 한다는 뜻이다.

3. final response를 trace와 대조한다

trace integrity가 확보되어도 agent의 최종 보고는 별도 문제다. agent가 “테스트 통과했습니다”라고 말했을 때 실제 trace에 테스트 실행과 결과가 있어야 한다.

따라서 coding agent PR gate에는 최소한 이런 검사가 필요하다.

• 변경 파일 목록과 실제 diff가 맞는가.
• 실행했다고 주장한 test command가 trace에 있는가.
• 실패한 command를 성공처럼 요약하지 않았는가.
• background process, cleanup script, destructive command가 있었는가.
• trace gap이나 sequence break가 있는가.

Trace Tampering 논문은 “trace를 믿을 수 있는가”를 묻지만, production workflow에서는 한 단계 더 가서 “trace와 최종 보고가 일치하는가”를 봐야 한다.

local coding agent 운영 체크리스트

당장 팀에서 Claude Code, Codex CLI, OpenCode류 도구를 쓴다면 나는 아래를 확인하겠다.

저장 위치

• session trace가 어디에 저장되는가.
• agent가 그 경로를 알 수 있는가.
• agent가 그 경로를 읽거나 쓸 수 있는가.
• subagent/background task trace도 같은 정책을 따르는가.

권한 분리

• agent 작업 디렉터리와 trace 저장소가 분리되어 있는가.
• trace writer가 별도 OS user 또는 별도 process 권한으로 돈다는 보장이 있는가.
• agent에게 shell을 줘도 trace sink에는 write-only 또는 no-access가 되는가.

실행 관측

• tool call log와 실제 process 실행이 일치하는가.
• shell command output만 남기는지, exit code와 cwd/env도 남기는지.
• MCP server 호출이 client trace 밖에서도 관측되는지.
• network egress와 file mutation을 trace와 연결할 수 있는지.

감사와 복구

• trace gap을 자동 탐지하는가.
• trace 삭제 시도를 policy violation으로 잡는가.
• incident review에서 local trace가 아니라 independent sink를 기준으로 삼는가.
• trace 보존 기간과 개인정보 삭제 정책이 충돌하지 않게 설계되어 있는가.

마지막 항목이 의외로 중요하다. trace를 무조건 오래 보관하면 privacy 문제가 생긴다. 하지만 너무 쉽게 지울 수 있으면 audit가 무너진다. 그래서 삭제 정책도 “agent가 지운다”가 아니라 “권한 있는 보존 정책이 만료·마스킹·삭제한다”로 가야 한다.

내 의견: agent 보안의 기본 단위가 바뀐다

기존 앱 보안에서는 애플리케이션 로그가 어느 정도 신뢰 가능한 내부 기록으로 취급됐다. 물론 공격자가 서버를 완전히 장악하면 로그도 위험하지만, 적어도 일반 사용자 요청이 서버 로그를 직접 지우지는 못한다.

local agent는 이 경계가 흐려진다. agent는 사용자 대신 shell을 잡고, 파일을 쓰고, 때로는 monitor가 보는 바로 그 workspace를 수정한다. 그러면 “agent가 수행한 일”과 “agent를 감시하는 기록”이 같은 권한 영역에 들어간다.

그래서 나는 agent runtime의 최소 보안 단위를 이렇게 봐야 한다고 생각한다.

• model prompt
• tool permission
• sandbox boundary
• trace integrity
• authorization gate
• final report verification

이 중 trace integrity가 빠지면 나머지도 약해진다. sandbox가 있어도 어떤 command가 실행됐는지 믿기 어렵고, authorization gate가 있어도 승인 전후의 실제 행위를 재구성하기 어렵다. eval도 마찬가지다. reward hacking을 찾으려면 reward hacking의 증거가 남아 있어야 한다.

한계와 주의점

이 글은 논문 초록과 본문에서 확인한 핵심 설정·결과를 바탕으로 정리했다. 세부 harness별 구현 차이, 최신 패치 여부, 각 제품의 enterprise logging 옵션은 별도로 확인해야 한다.

또한 “agent가 trace를 조작할 수 있다”는 결론을 “모든 agent trace는 무가치하다”로 읽으면 안 된다. 올바른 해석은 더 구체적이다.

trace를 감사와 compliance의 근거로 쓰려면, trace writer와 trace store가 agent 권한 바깥에 있어야 한다.

이건 과장된 보안 요구가 아니다. agent가 실제 파일, 돈, 배포, 고객 데이터, production ticket을 건드리는 순간 기본값이어야 한다.

참고 자료

• LLM Agents Can Easily Tamper With Their Own Traces — arXiv
• 논문 PDF
• 프로젝트 페이지: perfect-crime.ai