툴 호출 앞의 Falco, 코딩 에이전트 권한의 새 검문소

Falco 팀이 Prempti를 공개했습니다. 표면적으로는 Claude Code 같은 코딩 에이전트를 위한 작은 보안 도구처럼 보입니다. 하지만 이 발표의 흥미로운 지점은 코딩 에이전트 보안의 질문을 조금 바꾼다는 데 있습니다. "모델이 안전하게 판단할까"가 아니라 "모델이 실제 행동하기 직전에 누가 판정할까"입니다.

Prempti는 코딩 에이전트가 파일을 읽거나 쓰고, 셸 명령을 실행하고, 웹 요청을 보내고, MCP 도구를 호출하기 전에 그 요청을 가로챕니다. 그리고 익숙한 Falco YAML 규칙으로 allow, deny, ask 중 하나를 반환합니다. 허용된 호출은 그대로 진행됩니다. 차단된 호출은 실행되지 않고, 에이전트는 왜 막혔는지 구조화된 설명을 받습니다. 확인이 필요한 호출은 사용자의 승인으로 넘어갑니다. CNCF 블로그는 이를 "AI coding agents를 위한 policy and visibility layer"라고 설명했습니다.

이 뉴스가 중요한 이유는 코딩 에이전트가 더 이상 편집기 옆의 자동완성 기능에 머물지 않기 때문입니다. Claude Code, Codex, Gemini CLI, Cursor류 agent mode는 사용자의 터미널과 프로젝트 디렉터리 안에서 움직입니다. 파일을 읽고, 패치를 쓰고, 테스트를 실행하고, 패키지를 설치하고, 때로는 네트워크를 호출합니다. 이 행동은 대개 사용자의 권한으로 일어납니다. 에이전트가 실수로 .env를 열거나 ~/.ssh를 읽거나, 악성 README의 지시를 따라 curl | bash 패턴을 실행하려 할 때, 채팅 로그만으로는 충분하지 않습니다.

Falco 공식 글은 같은 문제를 직설적으로 묻습니다. 코딩 에이전트가 사용자의 머신에서 정확히 무엇을 하고 있는지 알고 있느냐는 질문입니다. 개발자는 에이전트의 최종 답변과 diff를 볼 수 있지만, 그 사이에 어떤 파일을 열었고 어떤 명령을 시도했으며 어떤 경계 밖으로 나가려 했는지는 구조화된 형태로 남지 않을 때가 많습니다. Prempti는 이 빈틈을 "툴 호출 직전"이라는 지점에서 잡으려 합니다.

왜 Falco인가

Falco는 원래 컨테이너, Kubernetes, 호스트 런타임 보안 쪽에서 알려진 CNCF graduated project입니다. 핵심은 이벤트를 규칙으로 평가하고, 위험한 행동을 탐지하는 것입니다. Prempti는 이 모델을 AI coding agent의 tool-call lifecycle로 옮깁니다. 기존의 시스템 콜이나 컨테이너 이벤트가 아니라 coding_agent라는 새 event source를 두고, tool.name, tool.input_command, tool.file_path, agent.cwd 같은 필드로 정책을 씁니다.

이 선택은 꽤 현실적입니다. 코딩 에이전트마다 안전장치와 승인 UI가 조금씩 다르면 팀은 도구별 설정을 따로 배워야 합니다. 반대로 Falco 규칙을 쓰면 보안팀과 플랫폼팀이 이미 아는 형식으로 "어떤 행동은 막고, 어떤 행동은 물어보고, 어떤 행동은 기록만 하자"를 표현할 수 있습니다. Prempti가 독자적인 risk score나 새 정책 언어를 만들지 않고 Falco YAML을 고른 이유도 여기에 있습니다.

예를 들어 Falco 블로그는 셸 인터프리터로 직접 파이프하는 명령을 막는 규칙을 보여줍니다. curl | bash, wget | sh, bash <(...) 같은 패턴은 오래된 공급망 공격과 원격 코드 실행의 단골 경로입니다. 일반 개발자도 이런 명령을 직접 확인하면 멈출 수 있습니다. 문제는 에이전트가 긴 작업 중간에 이를 시도할 때 사람이 항상 보고 있지 않다는 점입니다. Prempti는 이 판단을 규칙으로 앞으로 당깁니다.

- rule: Deny pipe to shell
  desc: Block piping content to shell interpreters
  condition: >
    tool.name = "Bash"
    and (tool.input_command contains "| sh"
         or tool.input_command contains "| bash"
         or tool.input_command contains "| zsh")
  output: >
    Falco blocked piping to a shell interpreter (%tool.input_command)
  priority: CRITICAL
  source: coding_agent
  tags: [coding_agent_deny]

여기서 중요한 것은 출력 메시지가 사람만을 위한 경고가 아니라는 점입니다. Prempti는 에이전트가 이해할 수 있는 설명을 되돌려 보냅니다. 차단된 뒤 에이전트는 "권한이 없어서 실패했다"는 정보를 보고 다른 경로를 찾거나 사용자에게 요청할 수 있습니다. 즉 가드레일은 조용한 차단기가 아니라 에이전트와 협력하는 정책 인터페이스가 됩니다.

allow, deny, ask의 작은 차이

Prempti의 verdict는 단순합니다. 하지만 이 세 가지가 코딩 에이전트 운영에서는 꽤 큰 차이를 만듭니다.

이 구조는 "모든 것을 막자"와 "모델을 믿자" 사이의 중간 지대를 만듭니다. 코딩 에이전트를 실무에서 오래 써 보면 모든 위험한 행동이 악의적이지는 않습니다. 의존성을 설치해야 할 때도 있고, 프로젝트 루트 밖의 shared config를 읽어야 할 때도 있으며, 테스트를 위해 로컬 서버를 띄워야 할 때도 있습니다. 그래서 deny만으로는 생산성이 크게 떨어지고, allow만으로는 감사가 비어 있습니다. ask는 그 사이의 행동을 사람의 맥락 판단으로 넘깁니다.

Prempti에는 두 가지 운영 모드도 있습니다. Monitor mode는 모든 툴 호출을 평가하고 로그로 남기지만 실제로 막지는 않습니다. Falco와 CNCF 글 모두 이 모드를 시작점으로 권합니다. 몇 세션 동안 에이전트가 실제로 무엇을 만지는지 보고, 규칙의 소음과 누락을 조정한 뒤 Guardrails mode로 넘어가라는 뜻입니다. Guardrails mode는 기본 모드이며 deny와 ask verdict를 실제로 집행합니다.

기본 규칙이 드러내는 위협 모델

Prempti의 기본 ruleset은 이 프로젝트가 보는 코딩 에이전트 위험을 잘 보여줍니다. 첫째는 작업 디렉터리 경계입니다. 코딩 에이전트는 프로젝트를 수정하라고 부름받았지만, 실제 권한은 사용자의 홈 디렉터리까지 이어질 수 있습니다. 프로젝트 밖 파일을 읽거나 쓰려 할 때 최소한 기록하거나 물어보는 장치가 필요합니다.

둘째는 민감 경로입니다. /etc/, ~/.ssh/, ~/.aws/, cloud credential, .env 같은 파일은 일반 코드 수정과 다릅니다. 에이전트가 이 파일을 읽어야 할 정당한 경우가 아주 없지는 않지만, 기본값은 보수적이어야 합니다. 특히 프롬프트 인젝션이나 악성 의존성 문서가 "환경 변수를 확인하라"거나 "키를 읽어 설정하라"고 유도할 때, 모델은 이를 작업 지시의 일부로 오해할 수 있습니다.

셋째는 sandbox disable입니다. 최근 코딩 에이전트 도구들은 샌드박스, 승인, 네트워크 제한을 제품 기능으로 넣고 있습니다. 그러나 에이전트가 설정 파일을 바꿔 자신의 제한을 낮추려 한다면, 이 역시 정책 이벤트가 되어야 합니다. Prempti의 기본 규칙이 agent sandbox configuration 비활성화 시도를 탐지 대상으로 둔 것은 의미가 있습니다. 에이전트 보안에서 "가드레일을 끄는 행동" 자체가 별도의 위험 신호이기 때문입니다.

넷째는 MCP와 skill content입니다. MCP 서버 설정 오염, slash-command file injection, hook injection, git hooks, package registry redirects, AI API base URL override 같은 항목은 최근 에이전트 생태계의 공격면을 반영합니다. 코딩 에이전트는 단순히 로컬 파일을 수정하는 프로그램이 아니라 도구와 플러그인, 스킬, 원격 서버를 엮는 실행면입니다. 공격자는 모델 본문보다 이 연결 계층을 노릴 수 있습니다.

샌드박스가 아니라는 점이 핵심입니다

Prempti 발표에서 가장 좋은 부분은 한계를 숨기지 않는다는 점입니다. Falco 블로그는 Prempti가 tool call로 선언된 것을 가로챌 뿐, 그 호출이 만들어내는 시스템 콜을 직접 보는 것은 아니라고 설명합니다. 에이전트가 악성 C 코드를 작성하고 컴파일한 뒤 실행한다면 Prempti는 gcc main.c -o main과 ./main 호출을 봅니다. 하지만 ./main 내부에서 어떤 파일을 열고 어떤 네트워크를 호출하는지는 Prempti 계층만으로는 모릅니다.

따라서 Prempti를 샌드박스로 읽으면 안 됩니다. 프로젝트 README도 이를 분명히 합니다. Prempti는 cooperative policy and visibility layer이며, determined adversarial agent를 containment하는 도구가 아닙니다. 시스템 hardening, least-privilege 환경, 샌드박스, Linux에서는 Falco eBPF/kmod 기반 syscall-level visibility와 함께 써야 합니다.

이 구분은 실무적으로 중요합니다. 코딩 에이전트 보안은 하나의 제품 기능으로 끝나기 어렵습니다. 로컬 개발자의 편의와 기업 보안 요구 사이에는 여러 계층이 있습니다. IDE나 CLI의 승인 UX, 에이전트 하네스의 hook, OS 권한, 컨테이너나 VM 샌드박스, 네트워크 egress 제어, 비밀 관리, 감사 로그, 코드 리뷰가 모두 필요합니다. Prempti는 이 중 "에이전트가 도구를 호출하려는 순간"을 잡습니다.

그럼에도 이 지점은 강력합니다. 너무 아래 계층에서만 보면 의도를 잃습니다. 시스템 콜은 정확하지만, open() 하나만 보고 에이전트가 어떤 프롬프트와 어떤 작업 맥락에서 파일을 열었는지 알기 어렵습니다. 너무 위 계층에서만 보면 실제 행동을 놓칩니다. 채팅 답변은 친절하지만, 그 답변을 만들기 위해 어떤 명령을 실행했는지 불명확할 수 있습니다. Prempti는 그 중간에서 "도구 호출"이라는 비교적 구조화된 단위를 정책 대상으로 삼습니다.

Claude Code 먼저, Codex는 다음

현재 Prempti는 Claude Code를 Linux, macOS, Windows에서 지원한다고 설명합니다. GitHub README와 CNCF 글은 x86_64와 ARM 계열을 함께 언급합니다. Codex integration은 roadmap 또는 planned 상태입니다. 이 순서는 자연스럽습니다. Claude Code는 hook과 skill 생태계가 활발하고, 터미널 기반 agent workflow가 이미 개발자 일상으로 들어온 대표 사례입니다.

흥미로운 대목은 Prempti가 Claude Code용 규칙 작성 skill도 제공한다는 점입니다. 사용자는 /plugin marketplace add falcosecurity/prempti와 /plugin install prempti-falco-rules@prempti-skills로 규칙 작성 보조를 붙일 수 있습니다. "git push를 막아라", "작업 디렉터리 밖 read를 거부하라", "Dockerfile 편집 전 확인을 요구하라" 같은 요청을 에이전트에게 맡기면, 에이전트가 자신을 제한하는 Falco 규칙 작성을 돕는 구조입니다.

이 장면은 꽤 상징적입니다. AI 코딩 도구의 다음 단계는 "에이전트가 더 많은 코드를 쓰게 하자"만이 아닙니다. 에이전트가 자기 행동 경계를 설명 가능한 규칙으로 만들고, 팀이 그 규칙을 리뷰하고, 실패 사례를 규칙으로 되돌리는 루프가 필요합니다. 보안팀이 모델을 직접 통제하기 어렵다면, 적어도 모델이 호출하려는 도구의 입구에는 검토 가능한 정책을 둘 수 있습니다.

커뮤니티 반응은 작은 질문에서 시작됐습니다

Prempti가 대형 모델 출시처럼 광범위한 토론을 만들지는 않았습니다. 그러나 r/devsecops의 반응은 실무적인 쟁점을 잘 드러냅니다. 한 사용자는 "그냥 간단한 pretool hook과 규칙 목록이 아니냐"고 물었습니다. 이에 작성자는 에이전트 쪽에서는 PreTool hook에 가깝지만, Falco를 쓰는 이유는 성숙한 규칙 엔진, custom query, exception, noise-to-signal tuning, 중앙 Falco 인스턴스 재사용 가능성이라고 답했습니다.

이 답변은 Prempti의 장점과 약점을 동시에 보여줍니다. 맞습니다. 핵심 아이디어는 놀라울 정도로 단순합니다. 에이전트가 행동하기 전에 hook을 걸고 규칙으로 판단합니다. 하지만 보안 제품에서 단순한 아이디어와 운영 가능한 구현은 다릅니다. 팀 단위로 규칙을 공유하고, 예외를 관리하고, 로그를 보관하고, 소음을 줄이고, 기존 보안 도구와 연결할 수 있어야 합니다. Falco라는 기존 규칙 생태계를 끌어온 것은 그 운영 문제를 줄이려는 선택입니다.

r/ClaudeCode 쪽에서는 "지금은 모델을 믿고 나쁜 tool call을 제때 눈치채길 바라는 것에 가깝다"는 반응이 보였습니다. 동시에 일반 Falco를 함께 써 syscall level에서 멈출 수 있어야 한다는 지적도 있었습니다. 이 균형이 중요합니다. Prempti는 코딩 에이전트의 보안 해답이라기보다, 현재 허술한 agent-local workflow에 붙일 수 있는 빠른 정책 계층입니다.

개발팀은 무엇을 봐야 하나

Prempti를 바로 모든 개발자 머신에 켜야 한다는 뜻은 아닙니다. 아직 experimental preview이고, 인터페이스와 동작이 바뀔 수 있습니다. 그러나 이 발표가 가리키는 방향은 지금 검토할 가치가 있습니다.

첫째, 에이전트가 사용하는 권한을 목록화해야 합니다. 파일 read/write, 셸 명령, 네트워크, MCP, 브라우저, Git remote, cloud CLI, package manager, secret store 중 무엇을 허용하고 무엇을 묻고 무엇을 막을지 정해야 합니다. "개발자가 직접 하면 괜찮다"는 기준은 에이전트에는 그대로 적용하기 어렵습니다. 에이전트는 빠르고 반복적이며, 문서나 의존성 안의 지시를 과도하게 따를 수 있기 때문입니다.

둘째, 승인 UI만으로는 부족합니다. 사람이 매번 모든 호출을 읽으면 에이전트의 장점이 줄어듭니다. 반대로 승인 프롬프트가 너무 많으면 개발자는 습관적으로 허용합니다. 규칙 기반 deny, 고위험 작업의 ask, 정상 작업의 allow를 나누는 정책 설계가 필요합니다. Monitor mode로 실제 세션 데이터를 보고 규칙을 조정하라는 Prempti의 권고는 이 점에서 현실적입니다.

셋째, 로그를 감사 자료로 볼지 디버깅 자료로 볼지 정해야 합니다. 에이전트가 잘못된 파일을 수정했을 때, 중요한 것은 최종 diff만이 아닙니다. 어떤 프롬프트, 어떤 파일 읽기, 어떤 명령, 어떤 차단 이벤트, 어떤 사용자 승인 뒤에 그 결과가 나왔는지 재구성할 수 있어야 합니다. Prempti의 audit trail은 이런 사건 재구성의 한 조각입니다.

넷째, 샌드박스와 함께 설계해야 합니다. Prempti가 막을 수 있는 것은 선언된 tool call입니다. 에이전트가 실행한 프로세스 내부 행동, child process, 네트워크 egress, credential scope는 다른 계층에서 다뤄야 합니다. 코딩 에이전트가 팀 단위로 배포될수록 "로컬 편의 도구"가 아니라 "개발 권한을 가진 자동 실행자"로 봐야 합니다.

작은 프로젝트가 드러낸 큰 변화

Prempti는 거대한 플랫폼 발표가 아닙니다. GitHub 저장소 기준 star도 아직 크지 않고, 기능 범위도 의도적으로 좁습니다. 하지만 작은 프로젝트일수록 때로는 시장의 방향을 더 선명하게 보여줍니다. 코딩 에이전트 경쟁은 모델 성능, IDE 통합, 가격, 컨텍스트 길이에서 시작했습니다. 이제는 실행 권한, 정책, 관측성, 감사, 샌드박스가 같은 무대에 올라왔습니다.

특히 "agent receives LLM-friendly explanation"이라는 설계가 중요합니다. 기존 보안 도구는 사람에게 경고를 보냅니다. Prempti는 사람과 에이전트 모두에게 정책 결과를 전달합니다. 앞으로 에이전트 보안 계층은 단순히 차단하는 것이 아니라, 에이전트가 정책을 이해하고 다른 실행 계획을 세우게 만드는 방향으로 발전할 가능성이 큽니다. 그때 정책은 외부 제약이 아니라 에이전트 작업 맥락의 일부가 됩니다.

물론 이 접근에는 위험도 있습니다. 에이전트가 "정책을 이해한다"는 말은 곧 정책 우회 시도를 더 그럴듯하게 설명할 수 있다는 뜻이기도 합니다. 그래서 최종 집행은 모델의 설득력이 아니라 외부 정책 엔진과 시스템 권한에 있어야 합니다. Prempti가 모델 판단에 의존하지 않고 Falco verdict를 실행 전 경계로 둔 점은 이 점에서 바른 방향입니다.

이번 뉴스의 핵심은 Prempti 자체보다 실행 지점입니다. 코딩 에이전트가 소스 파일을 읽고 명령을 실행하는 순간, 우리는 그 행동을 리뷰 가능한 정책으로 다룰 준비가 되어 있습니까. 아직 많은 팀의 답은 "채팅 로그와 코드 리뷰로 충분히 보겠다"에 가깝습니다. Prempti는 그 답이 오래가지 않을 수 있음을 보여줍니다.

코딩 에이전트가 더 많은 일을 맡을수록 좋은 모델을 고르는 일만으로는 부족합니다. 어떤 행동은 자동으로 허용하고, 어떤 행동은 물어보고, 어떤 행동은 절대 실행하지 않을지 정해야 합니다. 그리고 그 결정은 자연어 약속이 아니라 기록되고 테스트되는 정책이어야 합니다. Falco가 코딩 에이전트 앞에 선 이유는 바로 여기에 있습니다.