보안

이 챕터는 도구, 코드, 자금 이동에 대한 기술적 통제를 설명합니다. Chat에서 사용자의 위험한 결정을 확인하는 기능은 금융 안전 알림을 참고하십시오.

Agent에게 "이 Python 스크립트를 실행하고 결과를 보여줘"라고 지시합니다. 스크립트가 실행됩니다. 그 스크립트는 무해한 데이터 작업일 수도 있고, 마지막 줄에서 minara swap을 조용히 호출하여 100 USDC를 공격자 컨트랙트로 전송할 수도 있습니다.

자금을 이동할 수 있는 Agent가 코드를 실행하고, 명령을 입력하고, 컴퓨터에 파일을 기록할 수 있다는 것은 실질적으로 위험한 일입니다. 이 챕터는 Minara가 이 문제에 대해 정확히 무엇을 하는지, 각 방어책이 왜 존재하는지, 그리고 아직 어떤 한계가 있는지를 설명합니다.

이 모든 것을 동기 부여하는 세 가지 시나리오

구체적인 공격 사례를 통해 설계 의도를 파악할 수 있습니다.

1. 붙여넣기 공격. 사용자가 Discord나 포럼에서 "유용한" 스크립트를 복사해 Agent에게 실행을 요청하고, 그 중간 어딘가에 minara swap이 숨겨져 있습니다.
2. 다단계 인젝션. Agent가 무해한 헬퍼 파일을 작성하고, 이어서 한 줄을 추가 작성한 뒤, python helper.py를 실행합니다. 각 단계는 깨끗해 보이지만, 합쳐지면 지갑을 비워버립니다.
3. 온체인 함정. 스크립트가 approve(unknown_address, MaxUint256)를 호출하거나 Permit2 메시지에 서명합니다. 이것들은 "명백히 악의적인" 명령이 아닙니다. 합법적인 DEX 통합에서도 동일한 호출을 사용하지만, 지출자 필드가 공격자로 설정되어 있을 뿐입니다.

위 공격 중 어느 것도 단일 검사로 차단되지 않습니다. 스크립트는 실행되고, 파일은 존재하며, 컨트랙트 호출은 유효합니다. 이를 막는 것은 아래의 독립적인 계층들의 조합입니다.

계층 방어, 네 개의 독립 게이트

Minara는 LLM이 접근 가능한 모든 도구 앞에 네 개의 독립 안전 계층을 운영합니다. 독립적으로 구성한 데는 이유가 있습니다. 한 계층을 우회한 공격자도 나머지 계층을 통과해야 하며, 각 계층은 서로 다른 방식으로 실패하기 때문입니다.

산호색으로 강조된 계층(OS jail)은 유일한 물리적 경계입니다. 그 위의 모든 계층이 실패하더라도 syscall 수준의 격리는 여전히 적용됩니다. 나머지 세 계층은 트립와이어입니다. 가시성을 높이고 중단할 기회를 제공하지만, 결의에 찬 공격자는 소스 코드를 읽고 취약점을 찾을 수 있습니다. 계층 방어의 의미는 어떤 단일 계층이 아니라, 그 조합에 있습니다.

계층 1, 명령 가드 트립와이어

모든 셸 명령에 정규식 거부 목록을 적용합니다. rm -rf /, sudo, mkfs, curl … | sh, 포크 폭탄 등 의심의 여지가 없는 패턴을 하드 차단합니다. 정규식이 모든 것을 잡을 수 있다는 의미가 아닙니다. base64 인코딩 후 eval 방식은 통과할 수 있습니다. 핵심은 명백한 실수와 가장 흔한 프롬프트 인젝션 한 줄짜리 명령들이 여기서 소리 없이 차단되어, 나머지를 상위 계층에 맡긴다는 것입니다.

이것은 트립와이어이며, 경계가 아닙니다.

계층 2, OS jail (실질적 경계)

execute_code 또는 terminal이 생성하는 모든 서브프로세스는 Linux에서는 bwrap으로, macOS에서는 sandbox-exec으로 래핑됩니다. 그 래퍼 내부에서 프로세스는 ~/.ssh를 읽을 수 없고, 169.254.169.254(클라우드 메타데이터)에 연결할 수 없으며, 워크스페이스 디렉터리 외부에 쓸 수 없습니다.

상위 계층 전체가 우회되더라도, 즉 잘못된 정규식, 프롬프트 인젝션, 교묘한 난독화가 있더라도, 공격 코드는 여전히 jail이 허용하는 syscall 범위 안에서만 동작해야 합니다. 이것이 "물리적 경계"의 의미입니다. 문자열 매칭이 아닌 커널에 의해 강제됩니다.

계층 3, 자금 이동 확인 (2단계)

자금을 이동하는 모든 도구, 즉 스왑, 매수, 매도, 전송, 무기한 선물, Autopilot 활성화, 워크플로 활성화는 반드시 두 번 호출되어야 합니다.

1. 첫 번째 호출 (confirm 파라미터 없음): 핸들러가 거래를 시뮬레이션하고 미리 보기(금액, 경로, 슬리피지, 가스 추정치)를 반환합니다. 브로드캐스트는 하지 않습니다.
2. 두 번째 호출 (confirm: true): 이 시점에만 핸들러가 실제로 서명하고 브로드캐스트합니다.

이는 LLM에 대한 공손한 안내가 아니라, 모든 핸들러 내부에서 강제됩니다. LLM은 이 규칙을 "잊을" 수 없습니다. confirm: true 없이 swap_tokens를 호출하면 단순히 미리 보기만 반환될 뿐, 트랜잭션 해시는 절대 반환되지 않습니다.

전체 내용은 자금 이동 확인을 참조하십시오.

계층 4, 스크립트 위험 게이트 (신규)

계층 3은 직접적인 자금 이동 도구 호출은 차단하지만, subprocess.run(["minara", "swap", …])을 실행하는 Python 스크립트는 어떻게 처리할까요? 셸 호출은 인프로세스 툴 레지스트리를 우회하므로, 계층 3은 이를 인지하지 못합니다.

계층 4가 이 공백을 채웁니다. execute_code, terminal, write_file, 또는 patch가 실행되기 전에 스크립트 본문을 정적으로 분석합니다.

• RED: 자동 거부. 대량 삭제, IMDS / SSRF, 자격 증명 탈취, 컨테이너 탈출, 간접 난독화와 싱크의 결합, 인라인 개인키 서명이 해당됩니다.
• YELLOW: 일시 중지 후 사용자에게 질문. 자금 이동 CLI 셸 실행, approve / Permit2 / Safe 소유자 변경, 환경 변수 포이즈닝, 특정 경로 삭제, 위험한 패키지 설치가 해당됩니다.
• GREEN: 조용히 진행. 그 외 모든 것입니다.

전체 내용은 Agent의 위험 판단 방법을 참조하십시오.

Minara가 보호하지 않는 것

솔직한 목록입니다. 이 항목들은 버그가 아니라 범위의 경계입니다. 이를 인지하면 올바른 곳에서 경각심을 유지할 수 있습니다.

• 런타임에 생성되는 페이로드. os.system(a + b)를 실행하는 스크립트에서 a와 b가 런타임에 계산되는 경우, 정적 분석은 결합된 문자열이 무엇인지 알 수 없습니다. 계층 2 jail이 서브프로세스의 동작을 제한하지만, 게이트는 dynamic_command를 YELLOW로 분류하고 확인을 요청합니다. 승인하기 전에 스크립트를 읽어보십시오.
• 악의적인 스마트 컨트랙트와 DApp. 코드 계층은 컨트랙트 0xabc…가 드레이너인지, cool-dapp.example.com이 피싱 클론인지 알 수 없습니다. 이는 토큰 / DApp 스캔이 담당하는 별도의 영역입니다.
• 사용자가 서명한 트랜잭션. 계층 3이 미리 보기를 제공합니다. 확인하면 바이트가 서명되어 브로드캐스트됩니다. 예를 클릭하기 전에 미리 보기를 읽어보십시오.
• 본인의 오타와 버그. Minara는 악의적인 의도로부터 보호하지만, 실수로 잘못된 파일을 삭제하거나 잘못된 주소로 전송하는 것을 막지는 않습니다. 2단계 확인은 본인의 실수도 잡을 수 있도록 설계되었습니다. 그렇게 활용하십시오.

실제 사용에서의 의미

일상적인 사용을 위한 현실적인 안전 기준입니다.

• 🟢 일상적이고 예상 가능한 작업. Pandas 데이터 작업, 공개 HTTPS GET 요청, CSV에서 차트 생성, npm ci --ignore-scripts. Minara가 중단 없이 실행합니다.
• 🟡 확인 위젯이 표시됩니다 (YELLOW). minara swap, cast send, 또는 forge --broadcast를 호출하는 스크립트, ERC-20 approve 및 Permit2 서명, 특정 경로 삭제, bash <(curl …) 같은 프로세스 치환, NODE_OPTIONS 또는 LD_PRELOAD 설정. 게이트가 제시하는 증거를 읽은 후 수락하거나 취소하십시오.
• 🔴 하드 거부 (RED). 대량 삭제(rm -rf *, rm -rf $UNSET/x), ~/.ssh/id_rsa 읽기, IMDS 엔드포인트 접근, 컨테이너 탈출 시도, 코드 내 인라인 개인키. 이 패턴들은 정당한 업무 이유가 없으며, confirm: true가 있어도 게이트가 거부합니다. RED가 발생했다면 우회를 시도하지 마십시오. 스크립트가 하려던 것을 확인하십시오. 대부분의 경우 프롬프트 인젝션이거나 복사된 공격 코드입니다.
• ⚠️ 사용자의 책임. 개인키를 저장소에 넣지 마십시오. .env에 chmod 600을 적용하십시오. 대화형 세션에서 MINARA_SKIP_FUND_CONFIRM이나 DISABLE_SCRIPT_RISK_GATE를 설정하지 마십시오. 확인 전에 계층 3 미리 보기를 읽으십시오.

더 깊이 알아보기

이 챕터는 운영자 관점, 즉 "Minara를 안전하게 사용하는 방법"에 초점을 맞춥니다. 공식 신뢰 모델, 위협 분류 체계, 취약점 공시 정책은 저장소의 SECURITY.md를 참조하십시오. 해당 문서는 보안 연구자를 대상으로 작성되었으며, 지금 읽고 계신 내용은 거래를 위해 Minara를 운영하는 사람들을 위한 것입니다.

계속 읽기:

• 자금 이동 확인. 모든 자금 이동 도구의 2단계 플로우.
• 스크립트 위험 게이트. Agent가 RED, YELLOW, GREEN을 판단하는 방법.
• 감사 및 재정의. 결정 검토, 워크플로 면제 부여, 비활성화 스위치.