일주일 동안 AI 에이전트가 내 권한 게이트웨이를 공격하게 해보았다. 무엇이 고장 났는가.

Agent_Sudo를 만들기 시작했을 때, 저는 승인(approvals)과 정책 집행(policy enforcement)이 가장 어려운 부분일 것이라고 생각했습니다.

제 생각이 틀렸습니다.

진정으로 어려운 부분은 실제 에이전트들이 실제 도구(tools), 실제 런타임(runtimes), 그리고 실제 사용자들과 상호작용하기 시작할 때 나타나는 모든 행동 양식을 발견하는 것이었습니다.

지난 일주일 동안 저는 실제 에이전트 워크플로우(workflows)를 대상으로 Agent_Sudo를 직접 사용(dogfooding)해 보았고, 네 가지 놀라운 문제점을 발견했습니다:

1. 런타임(Runtime)이 네이티브 도구를 제공하면 에이전트가 거버넌스(Governance)를 우회할 수 있다

한 에이전트가 Agent_Sudo가 전혀 인지하지 못한 호스트 네이티브 셸(host-native shell)을 사용하여 Agent_Sudo의 워크스페이스(workspace) 설정을 성공적으로 변경했습니다. Agent_Sudo는 올바르게 동작했습니다. 문제는 런타임 경계(runtime boundary)였습니다. 이는 현재 프로젝트의 중심이 된 교훈을 강화해 주었습니다: Agent_Sudo는 라우팅된 액션(routed actions)을 제어하는 것이지, 임의의 런타임 기능(runtime capabilities)을 제어하는 것이 아닙니다.

2. 워크스페이스 변경 사항이 보이지 않았다

이전에 거부되었던 쓰기(write) 작업이 나중에 허용되었습니다. 감사 로그(audit log)에는 결정이 변경된 사실은 나타났습니다. 하지만 왜 변경되었는지는 나타나지 않았습니다. 원인은 감사 대상이 아니었던 워크스페이스 설정 변경이었습니다. 해결책: PR #83에서 workspace_changed 감사 이벤트(audit events)를 추가했습니다.

3. 광범위한 위임(Delegations)이 문제를 숨길 수 있다

와일드카드 위임(wildcard delegation)이 승인이 필요했던 쓰기 작업을 허용하고 있었습니다. 나중에 해당 위임이 만료되자, 대신 모든 작업을 거부했습니다. 권한 부여 엔진(authorization engine)은 올바르게 작동하고 있었습니다. 가시성(visibility)이 문제였습니다. 해결책: PR #86에서 위임 상태(delegation status) 및 광범위한 범위의 가시성을 추가했습니다.

4. 승인 대기 시간이 제가 생각했던 의미와 달랐다

저는 Agent_Sudo가 승인을 위해 300초 동안 대기하도록 설정했습니다. 하지만 요청은 여전히 120초 후에 만료되었습니다.

이유: 승인 TTL(Time To Live)과 대기 시간(wait time)은 별개의 제어 항목이었습니다.

해결책: PR #89에서 이제 대기 시간이 TTL을 초과할 때 경고를 표시하고 유효한 제한(effective limit)을 설명합니다.

가장 놀라웠던 점

이 문제들 중 그 어떤 것도 아키텍처 리뷰(architecture reviews)에서 나오지 않았습니다. 설계 문서(design documents)에서도 나오지 않았습니다. 모든 문제는 시스템에 실제 에이전트를 실행하면서 발생했습니다. 교훈은 "더 많은 기능을 만들어라"가 아니었습니다.

그것은 바로:

당신의 가정을 직접 검증(Dogfood)하라.

직접 해보고 싶으신가요?

가장 빠른 방법은 다음과 같습니다:

pipx install agent-sudo-mcp
agent-sudo eval

이 명령은 전체 흐름을 실행합니다:

차단됨 (blocked) → 위임됨 (delegated) → 1회 허용 (allowed once) → 거부됨 (denied) → 감사 확인됨 (audit verified)

직접 시도해 보신다면, 한 가지만 말씀해 주세요:

'감사 확인됨 (audit verified)' 단계에 도달하셨나요, 아니면 어디에서 멈추셨나요?

확인해 보고 싶으시다면 제 저장소(repo)인 https://github.com/Kisyntra/Agent_Sudo를 방문해 주세요.