요약 (TL;DR): Bitsight는 단 한 번의 OAuth 권한 부여로 누구나 소유자를 대신해 이메일을 보낼 수 있는 30,000개 이상의 노출된 AI 에이전트 인스턴스를 발견했습니다. 일상적인 더 큰 위험은 노출된 인스턴스 자체가 아니라, 대부분의 에이전트 설정에 "AI가 이것을 보내기로 결정함"과 "실제로 동작이 실행됨" 사이의 단계가 없다는 점입니다. 승인 게이트(Approval gate)는 행동의 문제가 아니라 구조의 문제입니다. 프롬프트(Prompt)는 변할 수 있지만, 게이트는 실행되거나 실행되지 않거나 둘 중 하나입니다.

2026년 2월, 사이버 보안 기업 Bitsight는 인터넷을 스캔하여 노출된 AI 에이전트 인스턴스를 조사했으며 30,000개 이상을 발견했습니다: 인증이 없는 OpenClaw 배포 사례들이 누구나 접근할 수 있도록 열려 있었습니다. Bitsight의 연구원들이 해당 인스턴스들이 무엇을 할 수 있는지 테스트했을 때, AI 에이전트의 아웃바운드 동작(특히 Gmail을 통해 소유자를 대신하여 이메일을 보내는 동작)이 초기 OAuth 권한 부여 외에 추가적인 권한 부여(Authorization)를 필요로 하지 않음을 확인했습니다. 액세스(Access) 자체만으로 충분했던 것입니다.

이것이 보안 측면의 발견입니다. 운영 측면의 발견은 더 조용하며, 노출된 인스턴스를 전혀 운영하지 않는 사람들에게도 영향을 미칩니다.

액세스(Access)는 권한 부여(Authorization)와 같지 않습니다

AI 에이전트를 귀하의 이메일, CRM 또는 캘린더에 연결할 때, 귀하는 OAuth 권한을 부여하게 됩니다. 읽기, 쓰기, 보내기 권한 말입니다. 이러한 권한은 에이전트가 유용한 작업을 수행하는 데 필요하기 때문에 설계상 광범위합니다. 대부분의 설정에서 빠져 있는 것은 "AI가 이것을 보내기로 결정함"과 "이메일이 보관함에서 나감" 사이의 단계입니다.

그 간극은 생각보다 작습니다. 받은 편지함을 요약하고 답장을 초안하는 AI 이메일 관리 에이전트는 초안 작성을 넘어 전송에 필요한 모든 것을 갖추고 있습니다. 리드(Lead) 상태를 업데이트하고 노트를 기록하는 AI CRM 어시스턴트는 레코드를 생성하고, 자동화(Automation)를 트리거하며, 후속 조치(Follow-up)를 보낼 수 있는 모든 것을 갖추고 있습니다. 귀하의 명시적인 지시 없이 이러한 동작을 수행할지 여부는 에이전트가 어떻게 구성되었는지에 달려 있으며, 대부분의 구성은 아웃바운드 동작 전의 일시 정지가 아닌 응답성(Responsiveness)에 최적화되어 있습니다.

이것은 버그가 아닙니다. 에이전트(Agents)가 구축되는 방식 그 자체입니다. 전체 전제는 에이전트가 당신을 대신하여 행동한다는 것입니다. 문제는 "당신을 대신하여"에 무엇이 포함되는지, 그리고 그 일이 일어나기 전에 당신이 무엇이 포함되어 있는지 알고 있는지입니다.

비즈니스 리스크는 극적이지 않습니다

허가 없이 행동하는 AI 에이전트에 대한 대부분의 논의는 극적인 사례들에 집중합니다. 대량 삭제된 편지함이나 노출된 내부 시스템 같은 것들 말이죠. 하지만 일상적인 버전은 더 평범하며, 1인 기업가(Solopreneurs)와 소규모 팀에게는 종종 더 큰 비용을 초래합니다.

고객 후속 조치(Follow-ups)를 관리하는 AI가 이번 달에는 연락하지 말아 달라고 요청한 사람에게 재참여(Re-engagement) 이메일을 보냅니다. 일정 관리를 담당하는 AI가 집중 업무를 위해 비워둔 날에 회의 초대를 보냅니다. CRM 접근 권한이 있는 AI가 갱신 협상의 일환으로 할인을 제안하려던 고객에게 표준 요율을 인용한 가격 이메일을 보냅니다.

이 중 어느 것도 AI가 나쁘게 행동하거나 통제를 벗어날(Go rogue) 필요를 요구하지 않습니다. 단지 AI가 당신이 가진 맥락(Context) 없이 가용한 정보만으로 행동할 뿐입니다. 특히 1인 기업가에게 이러한 맥락의 격차(Context gaps)는 흔하게 발생하며, 대규모 팀과 달리 실수가 발송되기 전에 이를 잡아줄 다른 사람이 없습니다. 2026년에 설정할 가치가 있는 5가지 워크플로 자동화에 관한 저희 글에서는 적절한 인간 체크포인트(Human checkpoints)를 통해 이러한 구체적인 유스케이스(Use cases)를 어떻게 구조화할 수 있는지 다룹니다. 이러한 맥락의 격차는 정상입니다. AI는 당신이 아는 것을 알지 못합니다. 문제는 일단 이메일이 발송되고, 회의가 예약되고, 기록이 작성되면, 그 행동은 이미 세상 밖으로 나가버린다는 점입니다.

왜 "권한을 조심해서 설정하라"는 말로는 해결되지 않는가

당연한 대응책은 권한의 범위(Scope)를 신중하게 설정하는 것입니다. 에이전트에게 읽기 권한은 주되 전송 권한은 주지 않는 식이죠. 접근할 수 있는 범위를 제한하는 것입니다.

이 방식은 에이전트가 실제로 유용한 무언가를 수행해야 할 때까지는 유효합니다. 만약 에이전트가 읽기만 가능하고 전송할 수 없다면, 이메일을 처리할 수 없습니다. CRM에 기록할 수 없다면, 아무것도 기록할 수 없습니다. AI 에이전트 가치 대부분은 단순히 관찰하는 것이 아니라 행동을 취하는 능력에서 나옵니다. 무언가를 망가뜨리지 않고는 에이전트가 행동할 수 없을 정도로 권한을 제한하는 것은, 사실상 자동화를 꺼버리는 것과 다름없습니다.

더 나은 프롬프팅 (Prompting) 역시 이 문제를 완전히 해결하지는 못합니다. "전송하기 전에 항상 확인하세요"와 같은 지침은 프롬프트 (Prompt) 안에 존재하며, 이는 매 컨텍스트 (Context)마다 언어 모델 (Language Model)이 이를 올바르게 해석하는지에 달려 있음을 의미합니다. 대부분의 경우에는 잘 작동합니다. 하지만 긴 컨텍스트 (Context), 모호한 지침, 또는 모델이 이전에 본 적 없는 입력값 등으로 인해 작동하지 않을 때, 에이전트는 어쨌든 행동을 수행해 버립니다.

동일한 실패 모드 (Failure mode)가 실제 운영 중인 AI 에이전트 배포 환경에서 반복적으로 나타납니다. 몇 주 동안 유지되던 제약 사항이 입력 패턴이 변하거나 컨텍스트 윈도우 (Context window)가 가득 차면 더 이상 유지되지 않습니다. 당신의 지침은 점진적으로 성능이 저하되는 것이 아니라, 유지되거나 혹은 유지되지 않거나 둘 중 하나이며, 대개 고객을 통해 그 사실을 알게 됩니다. 신뢰할 수 있는 계층은 프롬프트 (Prompt) 안에 있는 것이 아닙니다. 그것은 AI의 결정과 실행되는 행동 사이에 존재합니다. AI의 추론 (Reasoning)과 실제로 허용된 행동을 분리하는 이 설계 원칙은, 왜 대부분의 AI 에이전트 실패는 프롬프트 문제가 아니라 아키텍처 문제인가의 이면에 있는 통찰과 동일합니다.

승인 게이트 (Approval gate)는 행동이 아닌 구조의 문제입니다

외부로 나가는 행동을 하기 전의 승인 단계는 AI가 지침을 따르는지에 의존하지 않습니다. 모델이 일관성을 유지하는지에도 의존하지 않습니다. 이 방식이 작동하는 이유는 사람이 확인하기 전까지는 행동이 말 그대로 실행될 수 없기 때문입니다.

그러한 확인 과정이 느리거나 흐름을 방해할 필요는 없습니다. 스마트폰에서 빠르게 스와이프하는 것(예: '이것을 보내세요', '보류하세요')은 단 몇 초면 충분하며, 당신의 일정에 맞춰 이루어집니다. 만약 응답하지 않는다면, 워크플로 (workflow)는 대기합니다. 이메일은 초안 상태로 남습니다. CRM 기록은 작성되지 않은 채로 유지됩니다. 당신이 허락하기 전까지는 아무 일도 일어나지 않습니다.

시간이 흐름에 따라, 시스템이 당신이 항상 승인하는 행동이 무엇인지 학습하도록 하여 해당 작업들을 자동으로 실행하게 할 수 있습니다. 동일한 유형의 리드 (lead)에 대해 40번 연속으로 승인한 AI 후속 조치 (follow-up)라면, 41번째에는 당신의 승인이 필요하지 않습니다. 이것이 바로 신뢰도 점수 산정 (confidence scoring)이 실제로 작동하는 방식입니다. 시스템은 작업 유형별로 당신의 승인 이력을 추적하며, 검증된 패턴이 자동 실행 단계로 넘어갈 수 있도록 합니다. 하지만 당신이 활발하게 협상 중인 고객에게 보내는 메시지나, 시간이 촉박한 상황에서의 아웃바운드 (outbound) 작업은 당신이 승인할 때까지 대기열에 머물러 있습니다.

당신이 구축하고 있는 것은 당신이 검증한 행동에 대해서는 빠르게 움직이고, 당신의 확인이 필요한 행동에 대해서는 일시 정지할 수 있는 에이전트 (agent)입니다. 이는 모든 것에 대해 빠르게 움직이는 에이전트와는 다릅니다. 후자의 경우, 당신이 원치 않는 시점에 무언가가 발송될 수 있음을 의미하기 때문입니다.

다음 워크플로를 설정하기 전에 준비해야 할 사항

새로운 도구를 AI 에이전트에 연결하기 전에, 짧은 체크리스트를 검토해 볼 가치가 있습니다. 이 OAuth 권한 부여에는 어떤 쓰기 또는 보내기 권한이 포함되어 있습니까? AI의 출력 (output)과 실제 행동이 실행되는 단계 사이에 워크플로 상의 단계가 존재합니까? 만약 AI가 불완전한 컨텍스트 (context)를 바탕으로 행동한다면, 누가 가장 먼저 알게 됩니까: 당신입니까, 아니면 수신자입니까?

아웃바운드 커뮤니케이션 (outbound communication)을 다루는 모든 워크플로에서, 마지막 질문에 대한 답은 항상 당신이어야 합니다. 이는 AI 에이전트가 일반적인 의미에서 신뢰할 수 없기 때문이 아니라, 아웃바운드 작업은 약속 (commitments)을 만들기 때문입니다. 불완전한 컨텍스트를 바탕으로 이루어진 약속은 되돌리기 어렵습니다.

AI에게 귀하의 편지함(inbox)이나 CRM에 대한 접근 권한을 부여하는 것은 유용합니다. 하지만 AI에게 아웃박스(outbox)로 향하는 제한 없는 경로를 제공하는 것은 별개의 결정이며, 이를 의도적으로 신중하게 내려야 합니다. OWASP Top 10 for LLM Applications는 과도한 에이전시 (excessive agency, AI 모델에 작업에 필요한 것보다 더 많은 권한을 부여하는 것)를 배포된 AI 시스템에서 가장 흔하고 중대한 보안 위험 중 하나로 나열하고 있습니다. 또한 액션 크레딧 가격 책정 체계에서 승인(approvals)은 무료이기 때문에, 아웃바운드 작업(outbound actions) 전에 게이트를 추가하더라도 비용적인 불이익이 없습니다. 즉, 이를 생략해야 할 경제적 이유가 없습니다.

원문은 Rills 블로그에 게시되었습니다. Rills는 1인 기업가와 마이크로 팀을 위한 자율적 의사결정 계층(autonomous decision layer)입니다. AI가 제안하면 인간이 모바일 스와이프 대기열(swipe queue)을 통해 승인하며, 워크플로우는 신뢰를 쌓음에 따라 감독형에서 자율형으로 전환됩니다. 승인은 항상 무료이며, AI가 실제 작업(real action)을 수행할 때만 비용을 지불합니다.