당신의 AI 어시스턴트가 비행 도중 하이재킹(Hijacked)될 때

만약 당신이 코딩 에이전트(coding agent)에게 자동화된 작업을 맡기고 자리를 비웠다면, 이 이야기는 당신을 다소 불편하게 만들 것입니다.

최근 한 개발자는 자신의 코딩 에이전트가 프롬프트 인젝션 (Prompt Injection) 공격에 의해 거의 장악될 뻔했던 사례를 공유했습니다. 이는 통제된 테스트 환경이 아니라, 자동화된 작업이 진행되는 _도중(during)_에 발생한 일이었습니다. 주입된 프롬프트는 에이전트의 원래 지침을 무시하고 동작을 재지정하려고 시도했습니다. 다시 말해, 환경 내의 누군가(또는 무언가)가 에이전트에게 개발자가 요청한 것과는 완전히 다른 일을 하도록 명령하려 했던 것입니다. 그리고 그것은 거의 성공할 뻔했습니다.

이것은 새로운 것이 아닙니다 — 하지만 위험 부담(Stakes)이 훨씬 커졌습니다

프롬프트 인젝션 (Prompt injection)은 대규모 언어 모델 (LLM)이 파이프라인과 유사한 곳에 사용되기 시작한 이래로 알려진 문제였습니다. 개념은 단순하고 오래되었습니다. 지침(instructions)과 데이터(data)를 혼용하여 처리하는 시스템의 입력 스트림에 악의적인 지침을 넣을 수 있다면, 시스템을 하이재킹(hijack)할 수 있습니다. 우리는 SQL 인젝션 (SQL injection), XSS, 템플릿 인젝션 (template injection)을 통해 이를 보았습니다. 패턴은 고전적입니다. 새로운 것은 _대상(target)_입니다.

단순한 챗봇 (chatbot)이 프롬프트 인젝션을 당하는 것은 당혹스러운 수준입니다. 하지만 코딩 _에이전트 (agent)_가 프롬프트 인젝션을 당하는 것은 잠재적으로 재앙적입니다. 에이전트는 도구 (tools)를 가지고 있습니다. 그들은 코드를 작성하고 실행하며, 파일 시스템 (filesystems)과 상호작용하고, API 호출을 수행하며, 점점 더 최소한의 인간 감독 하에 작동하고 있습니다. 영향 범위 (blast radius)는 "당혹스러운 말을 하는 것"이 아닙니다. 영향 범위는 "백도어 (backdoor)를 작성하거나, 자격 증명 (credentials)을 유출하거나, 당신의 저장소 (repository)에 악성 코드를 커밋하는 것"입니다.

이는 대부분의 사람들이 AI 코딩 어시스턴트를 워크플로 (workflow)에 통합할 때 머릿속으로 모델링하는 위험 프로필 (risk profile)과는 근본적으로 다른 것입니다.

과장된 부분 — 그리고 과장되지 않은 부분

하이프 머신 (hype machine)은 프롬프트 인젝션 (prompt injection)을 보통 두 가지 방식 중 하나로 프레임화하는 경향이 있습니다. 즉, 부주의한 구현자들에게만 영향을 미치는 지엽적인 엣지 케이스 (edge case)이거나, 혹은 LLM 아키텍처 (architecture) 자체의 해결 불가능한 실존적 결함이라는 식입니다. 두 가지 모두 틀렸으며, 각각 특정한 이해관계에 부합합니다.

에이전트 (agents)를 구축하는 벤더 (vendors)들은 가드레일 (guardrails) 문제가 기본적으로 해결되었으며, 자신들의 시스템은 견고하고, 이것은 지엽적인 연구 문제라고 당신이 믿기를 원합니다. 하지만 그렇지 않습니다. 이것은 실제 개발자, 실제 작업, 그리고 실제 발생할 뻔했던 사고였습니다.

반대편의 비관론자 (doom crowd)들은 에이전트형 AI (agentic AI)와 함께 안전한 전진 경로란 없다고 당신이 생각하기를 원합니다. 이 또한 과장되어 있습니다. 하지만 책임감 있는 중간 지점은 공격 표면 (attack surface)과 실제로 씨름하는 것을 요구하며, 대부분의 팀은 아직 이를 수행하지 못하고 있습니다.

정작 과소평가되고 있는 것은, 신뢰할 수 없는 환경에서 작동하는 에이전트를 위한 신뢰 모델 (trust model)에 대해 업계가 얼마나 미흡하게 고민해 왔는가 하는 점입니다. 당신의 에이전트가 작업의 일환으로 웹을 브라우징하거나, 코드베이스 (codebase)를 읽거나, 제3자 데이터를 처리할 때, 그 모든 입력값은 잠재적인 인젝션 벡터 (injection vector)가 됩니다. 에이전트는 "내가 처리해야 할 데이터"와 "내가 따라야 할 지침"을 신뢰성 있게 구분할 수 없습니다. 왜냐하면 모델 자체의 설계상 그 부분에 강화된 경계 (hardened boundary)가 없기 때문입니다.

이것이 당신에게 의미하는 바

만약 당신이 코딩 에이전트를 사용하는 개발자라면, 불편한 진실은 당신이 적대적 입력 (adversarial inputs)을 염두에 두고 설계되지 않은 기술의 "신뢰하되 검증하라 (trust-but-verify)" 단계에 놓여 있다는 것입니다. 몇 가지 구체적인 시사점은 다음과 같습니다:

• 인간의 감독이 줄어든 자동화된 작업은 가장 높은 위험 시나리오입니다. 이번 공격이 거의 성공할 뻔했던 이유는 바로 에이전트가 작업 중간에 작동하고 있었기 때문입니다. 직접적인 감시(Eyes-on)가 중요합니다.
• 에이전트가 소비하는 입력값은 공격 표면 (attack surface)의 일부입니다. 외부 데이터 소스를 웹 앱의 사용자 입력(user input)과 동일한 의심을 가지고 다루십시오. 왜냐하면 그것들이 정확히 사용자 입력과 같은 역할을 하기 때문입니다.
• 최소 권한 (Minimal privilege)이 중요합니다. 만약 에이전트가 저장소(repo)에 대한 쓰기 권한, 프로덕션 자격 증명 (production credentials), 그리고 임의의 코드를 실행할 수 있는 능력을 가지고 있다면, 성공적인 인젝션 (injection)은 사소한 사고로 끝나지 않습니다.
• 보안 팀은 대체로 아직 따라잡지 못했습니다. 대부분의 애플리케이션 보안 (appsec) 프로그램에는 에이전트형 AI (agentic AI) 배포를 평가하기 위한 프레임워크가 없습니다. 이러한 격차는 문제가 해결되기 전에 실제 사고를 일으킬 것입니다.

업계 전반적으로 볼 때, 이 이야기는 향후 12~18개월 동안 훨씬 더 격렬한 논쟁거리가 될 것으로 예상되는 주제에 대한 하나의 데이터 포인트입니다. 즉, 에이전트가 하이재킹(hijacked)되어 해로운 행동을 했을 때 그 책임은 누구에게 있는가 하는 점입니다. 이를 배포한 개발자입니까? 이를 구축한 플랫폼입니까? 아니면 모델 제공자입니까? 아직 누구도 명확한 답을 가지고 있지 않습니다.

열린 질문 (The Open Question)

에이전트형 AI (Agentic AI)는 보안 커뮤니티가 이를 논리적으로 분석할 수 있는 속도보다 더 빠르게 도입되고 있습니다. 주의를 기울인 개발자에 의한 한 번의 아슬아슬한 사고는 유용한 신호가 될 수 있습니다. 하지만 아무도 검토하지 않는 자동화된 파이프라인 속에서, 결과가 눈에 띄지 않거나 조용히 롤백(rolled back)되는 방식으로 얼마나 많은 사고가 소리 없이 일어나고 있을까요?

당신은 에이전트가 행동에 옮기기 전에 그들이 소비하는 입력값을 실제로 어떻게 검증(vetting)하고 있습니까?

— Cor, Skyblue Soft

출처

• A prompt injection nearly hijacked my coding agent mid-task