깃발을 올립니다. 다음에 일어날 일은 다음과 같습니다.

Christopher Adams 작성

저는 위협 행위자 (threat actor)가 아닙니다.

이 시리즈가 경고라기보다는 설계도 (blueprint)처럼 읽힐 수 있는 많은 내용을 다루었기 때문에, 서두에서 이 점을 분명히 말씀드리고 싶습니다. 이것은 설계도가 아닙니다. 이것은 경고입니다. 이 차이는 중요하며, 저는 이 글의 나머지 부분을 통해 제가 정확히 무엇을 하고 있는지, 왜 그것을 하는지, 그리고 무엇을 요청하는지를 설명하고자 합니다.

내가 무엇을 만들었으며 왜 이에 대해 이야기하는가

Forge-AI는 개인 생산성 플랫폼입니다. 저는 제 하드웨어에서 실행되고, 제 도구를 사용하며, 제 작업을 기억하고, 저의 전문적인 데이터를 다른 사람의 API 엔드포인트 (API endpoint)로 보내지 않는 유능한 AI 에이전트 (AI agent)를 원했기 때문에 이것을 만들었습니다. 저는 이것을 사용합니다. 유용합니다. 저는 이 아키텍처 (architecture)가 자랑스럽습니다.

개발 과정 중 어느 시점에 — 구체적으로 1,086줄의 라우터 오케스트레이션 (router orchestration) 코드가 된 부분 중 800행 근처에서 — 제가 만든 것에 그림자가 있다는 것을 깨달았습니다. 유능한 개인용 에이전트에 대한 요구 사항과 유능한 AI 네이티브 임플란트 (AI-native implant)에 대한 요구 사항은 구조적으로 동일합니다. 제가 생산성을 위해 구축한 스캐폴딩 (scaffolding)은 훨씬 더 어두운 무언가를 위해 필요한 스캐폴딩과 동일합니다.

그 시점에서 제가 직면한 질문은 이에 대해 어떻게 해야 하는가였습니다.

한 가지 선택지: 아무 말도 하지 않는 것. 생산성 도구를 출시하는 것. 위협 표면 (threat surface)에 대해 언급하지 않는 것. 다른 누군가가 이를 알아차리고 대신 문제를 제기하기를 바라는 것.

저는 그렇게 할 수 없었습니다. 위협 표면은 실재하며, 기존의 보안 스택 (security stack)은 이에 대해 진정한 한계를 가지고 있고, "이것은 이론적이다"와 "이것이 실제 사람들에게 일어났다" 사이의 간극은 좁아지고 있습니다. 만약 당신이 구체적이고 신뢰할 수 있는 위험을 보고도 아무 말도 하지 않는다면, 당신은 다음에 일어날 일의 일부에 책임을 지게 됩니다.

그래서 저는 THREAT_MODEL.md를 작성하여 코드와 함께 공개했습니다. 이 시리즈에서 제가 주장한 모든 내용은 저장소(repository)의 특정 파일로 추적할 수 있습니다. 저는 제가 무엇을 만들었는지, 그것이 무엇을 할 수 있는지, 왜 변환(conversion)이 상대적으로 빠를 것인지, 그리고 왜 기존의 방어 스택(defensive stack)이 적절한 해답을 가지고 있지 않은지에 대해 명확히 밝혔습니다. 또한 제 분석의 한계점에 대해서도 명시했습니다. 제가 직접 작성했으며, 독립적인 감사를 받지 않았고, 사각지대(blind spots)가 있을 수 있다는 점을 말입니다.

이러한 투명성과 지적 정직성(intellectual honesty)의 결합이 핵심입니다. 이것은 허세를 부리는 것이 아닙니다. 이러한 특성을 가진 무언가를 만들었을 때 취해야 할 최소한의 책임 있는 행동입니다.

48~84시간이 실제로 의미하는 것

THREAT_MODEL.md에 기재된 변환 간극(conversion gap) 추정치는 48~84시간의 추가 개발 시간을 의미합니다. 저는 이 숫자가 무엇을 의미하고 무엇을 의미하지 않는지 정확히 짚고 넘어가고 싶습니다.

이것이 의미하는 바는 다음과 같습니다: 이미 이 코드베이스(codebase)를 이해하고 있는 숙련된 개발자라면, 집중적인 작업을 통해 약 1~2주 안에 이를 기능적인 고도 지속 위협(Advanced Persistent Threat, APT)으로 확장할 수 있다는 것입니다. 브라우저 접속, 터미널 실행, 화면 캡처, 라우터 오케스트레이션(router orchestration), 지속성 메모리(persistent memory), 자기 개선 파이프라인(self-improvement pipeline)과 같은 역량 스캐폴딩(capability scaffolding)은 이미 존재합니다. 남은 작업은 은밀한 C2 채널(C2 channels), 자격 증명 탈취(credential capture), 탐지 회피(detection evasion), 라우터 지속성 로직(router persistence logic), 그리고 자기 보존(self-preservation)입니다. 각 항목은 위협 모델(threat model)에서 개별적으로 추정되었습니다. 이 중 어느 것도 새로운 연구나 제로 데이(zero-day) 공격을 필요로 하지 않습니다. 그것들은 엔지니어링 작업입니다.

이것이 의미하지 않는 바는 다음과 같습니다: 이것이 쉽다는 뜻도, 제가 직접 해냈다는 뜻도, 혹은 현재 Forge-AI의 악성 버전이 야생(in the wild)에 존재한다는 뜻도 아닙니다. 또한 이것이 이러한 종류의 위협으로 가는 유일한 경로라는 뜻도 아닙니다. 공격자는 처음부터 구축하거나, 다른 수많은 오픈 소스 에이전트 프레임워크(agent frameworks)를 변형하여 사용할 수도 있습니다. 48~84시간이라는 추정치는 오직 이 코드베이스에 국한된 것입니다. 왜냐하면 그것이 제가 확실히 말할 수 있는 부분이기 때문입니다.

이것이 업계에 의미하는 바는, AI-native 임플란트 (AI-native implants)에 대한 논의가 "언젠가 누군가 이것을 만들게 되면 어떤 일이 벌어질까"라는 식으로 프레임이 잡혀서는 안 된다는 것입니다. 그러한 프레임은 이것이 미래의 문제라는 점을 암시합니다. 그 발판(scaffolding)은 오늘날 합법적이고 공개적으로 사용 가능한 코드 형태로 이미 존재합니다. "생산성 도구 (productivity tool)"와 "지능형 지속 위협 (Advanced Persistent Threat, APT)" 사이의 간극은 의욕적인 개발자의 2주간의 스프린트 (sprint) 정도에 불과합니다. 논의는 "첫 번째 실제 사고가 발생하기 전에 방어자들이 무엇을 구축해야 하는가"라는 방식으로 프레임이 잡혀야 합니다.

제가 요구하는 것

저는 네 부류의 청중에게 말하고 있습니다. 각 대상에 대해 구체적으로 말씀드리겠습니다.

탐지 엔지니어 (detection engineers)를 위해:

사용자의 인지 없이 작동하는 AI 에이전트 (AI agent)를 탐지하기 위해 필요한 행동 시그니처 (behavioral signatures)는 현재의 도구에는 존재하지 않습니다. 그것을 구축하는 것이 바로 우리가 해야 할 일입니다. 구체적으로는 다음과 같습니다: 인간의 상호작용 타이밍과 자동화된 에이전트의 타이밍을 구분하는 행동 모델 (behavioral models), 신뢰할 수 있는 도메인을 통한 C2 트래픽에 대한 페이로드 수준의 검사 (payload-level inspection; 도메인 허용/차단이 아닌 콘텐츠 검사), 그리고 사고 대응 체크리스트에서 라우터 포함을 사후 조치가 아닌 표준 단계로 설정하는 것입니다.

이 중 쉬운 것은 하나도 없습니다. 하지만 모두 가능합니다. 첫 번째 실제 AI-native APT 사고는 이를 빠르고 압박감 속에서 구축해야 한다는 엄청난 압력을 만들어낼 것입니다. 사고가 발생한 후가 아니라, 그전에 신중하고 충분히 테스트된 방식으로 이를 구축하는 것이 훨씬 더 바람직합니다.

보안 아키텍트 (security architects)를 위해:

제로 트러스트 (Zero Trust)의 신원(identity) 및 권한 부여(authorization) 기둥은 설계된 목적에 따라 필수적이며 진정으로 효과적입니다. 하지만 이 위협 클래스에 대해서는 충분하지 않습니다. 왜냐하면 이 위협은 합법적인 자격 증명을 사용하여 인증된 세션 내에서 작동하기 때문입니다.

그 간극은 의도 계층 (intent layer)입니다. 즉, 승인된 세션 내에서 수행되는 동작이 인증을 수행한 인간의 의도를 반영하는지, 아니면 인간이 알지 못하는 소프트웨어의 의도를 반영하는지를 평가하는 메커니즘입니다. 이를 대규모로 적용한다면 어떤 모습일까요? 어떤 행동 신호 (behavioral signals)가 "인간이 수행하는 동작"과 "인간 모르게 인간을 대신하여 에이전트가 수행하는 동작"을 구분할 수 있을까요? 이는 미해결 연구 과제 (open research problem)입니다. 누군가는 이 문제를 연구해야 합니다. 라우터 보안 (Router security)은 엔드포인트 보안 (endpoint security)과 동일한 위협 모델링 (threat modeling) 논의에 포함되어야 합니다.

에이전트 프레임워크를 구축하는 AI 개발자들을 위하여:

MCP 프로토콜과 유사한 표준들은 생태계에 유익합니다. AI 에이전트가 시스템 기능에 접근하는 방식을 표준화하면 유용한 도구를 구축하고, 플랫폼 간 상호 운용성을 확보하며, 인프라를 공유하기가 더 쉬워집니다. 저는 이에 반대하는 것이 아닙니다.

제가 주장하는 것은 이중 용도 위협 모델링 (dual-use threat modeling)이 배포 이후로 미뤄지는 것이 아니라, 설계 프로세스의 일부가 되어야 한다는 것입니다. 표준화되는 모든 MCP 서버는 악의적인 에이전트가 사용할 수 있는 하나의 기능 (capability)입니다. 보안 커뮤니티가 AI 에이전트가 현재 무엇을 할 수 있는지 이해하는 데 있어 개발 커뮤니티보다 항상 두 단계 뒤처져 있다면, 보안 커뮤니티는 제 역할을 수행할 수 없습니다.

코드와 함께 THREAT_MODEL.md를 게시하는 것은 개발자 관점에서 책임 있는 이중 용도 공개 (responsible dual-use disclosure)가 어떤 모습인지 보여주는 하나의 모델입니다. 저는 심각한 기능 접근 권한을 가진 모든 에이전트 플랫폼에서 이것이 예외가 아닌 규범 (norm)이 되기를 바랍니다.

더 넓은 개발자 커뮤니티를 위하여:

로컬 AI 에이전트를 구축하는 것 자체가 본질적으로 위험한 것은 아닙니다. Forge-AI는 정당한 용도를 가진 정당한 도구입니다. 위험은 이러한 종류의 소프트웨어가 존재한다는 것이 아닙니다. 위험은 이를 구축하는 매우 적은 수의 사람들이 그것이 만들어내는 공격 표면 (threat surface)에 대해 신중하게 생각하지 않고 있으며, 보안 커뮤니티가 악의적으로 사용될 때 이를 탐지할 준비가 아직 되어 있지 않다는 점입니다.

만약 여러분이 브라우저, 터미널, 그리고 파일 시스템 (filesystem) 접근 권한을 가진 로컬 에이전트 프레임워크 (local agent framework)를 구축하고 있다면, 위협 모델 (threat model)을 작성하십시오. 그리고 코드를 공개할 때 함께 게시하십시오. 여러분의 아키텍처 (architecture)가 무엇을 할 수 있는지에 대해 정직해지십시오. 개발자 커뮤니티가 이 문제에 대해 신중하게 생각하는 것이야말로, 이러한 도구들이 주로 위협적이기보다는 주로 생산적인 결과로 이어지게 만들 가능성이 가장 높은 방법입니다.

내가 지향하는 목표

Forge-AI 개발은 계속됩니다. 생산성 활용 사례 (productivity use case)는 실재하며, 저는 이를 계속 구축할 의도입니다. 로드맵에는 더 정교한 RAG 파이프라인 (RAG pipelines), 더 나은 모듈 시스템 도구 (module system tooling), 개선된 데스크톱 앱 경험, 그리고 시간이 지남에 따라 모델의 개선을 측정하기 위한 파인튜닝 평가 파이프라인 (fine-tuning eval pipeline)이 포함되어 있습니다.

또한 저는 코드베이스 (codebase)와 위협 모델 (threat model)에 대한 독립적인 보안 검토 (security review)를 적극적으로 구하고 있습니다. THREAT_MODEL.md를 직접 작성했다는 점은 제가 문서에서 명시적으로 인정한 한계점입니다. 저는 제 자신의 코드에 대해 사각지대 (blind spots)를 가지고 있을 수 있으며, 변환 추정치 (conversion estimates)는 경험적으로 검증된 수치가 아닌 추측에 기반한 것이고, 분석을 검증하기 위한 작동 가능한 악성 버전 (malicious version)을 구축하지 않았습니다. 독립적인 검토자라면 제가 놓친 것들을 잡아낼 수 있을 것입니다. 만약 이 작업의 검토에 관심이 있는 자격을 갖춘 보안 연구자 (security researcher)라면, 기꺼이 대화를 환영합니다.

그리고 저는 적극적으로 구직 활동을 하고 있습니다. 이 시리즈는 공공 서비스인 동시에 포트폴리오이기도 합니다. 제가 구축한 것과 그것에 대해 쓴 글은 제가 어려운 문제에 대해 엄격하게 사고하고, 실제 결과물을 만들어내며, 그 두 가지 모두에 대해 명확하게 소통할 수 있음을 증명하기 위한 것입니다. 만약 여러분이 소프트웨어 개발이나 보안 연구 분야에서 채용을 진행 중이고, 이 시리즈의 작업물이 신뢰할 만하고 흥미롭다고 느끼신다면, 연락을 기다리겠습니다.

요청 사항

깃발은 올려졌습니다. 이 글을 읽는 분들에게 제가 필요한 것은 다음과 같습니다:

만약 여러분이 탐지 엔지니어 (detection engineer) 또는 보안 아키텍트 (security architect)라면: 이 문제에 참여하십시오. 아직 존재하지 않는 것들을 만들어내십시오. "이것은 이론적이다"와 "이것이 실제로 일어났다" 사이의 시간적 간극은 여러분이 생각하는 것보다 짧습니다.

보안 연구자(Security researcher)라면: 위협 모델(Threat model)을 읽고, 코드를 살펴본 뒤, 제가 놓친 것이 무엇인지 말해 주십시오. 진심으로 드리는 말씀입니다. 독립적인 분석은 이것을 단순히 경고를 주는 것에 그치지 않고, 방어자(Defenders)들에게 유용하게 만드는 다음 단계입니다.

에이전트 프레임워크(Agent frameworks)를 구축하는 개발자라면: 여러분의 위협 모델을 작성하십시오. 그리고 이를 공개하십시오. 이것을 하나의 규범(Norm)으로 만드십시오.

이 분야의 채용 담당자(Recruiter)나 고용 관리자(Hiring manager)라면: 아래에 GitHub 링크가 있습니다. 이 세 편의 글에서 제가 주장한 모든 내용은 해당 리포지토리(Repository)에서 검증 가능합니다. 대화를 환영합니다.

목표는 공포가 아닙니다. 목표는 대비입니다. 이 두 결과 사이의 차이는 적절한 사람들이 얼마나 빨리 이를 진지하게 받아들이느냐에 달려 있습니다.

Christopher Adams는 애리조나주 프레스콧 밸리에 거주하는 독학 개발자입니다. 그는 완전한 능력을 갖추고 로컬에서 실행되는 AI 에이전트가 어떤 모습일 수 있는지 탐구하기 위한 개인 프로젝트로 Forge-AI를 구축했으며, 결과적으로 해당 소프트웨어 계층이 보안에 시사하는 바에 대한 작동 가능한 이중 용도(Dual-use) 분석을 도출해 냈습니다. 그는 AI 에이전트 아키텍처(Architecture), 공격적 보안 연구(Offensive security research), 그리고 이 둘의 교차점에 관심이 있습니다. 그는 소프트웨어 개발 및 보안 연구 분야에서 기회를 적극적으로 찾고 있습니다.

GitHub: https://github.com/ChrisAdamsdevelopment/Forge-AI | Email: chris@spectracleanse.com