Barracuda 이메일 프롬프트 인젝션 경고, AI 받은편지함 권한에 대한 검토 촉발

Barracuda는 공격자들이 직원의 판단이 아닌 AI 어시스턴트의 권한을 노리고 채용 이메일에 은닉 명령을 삽입했다고 밝혔다. Barracuda 이메일 프롬프트 인젝션 경고는 확인된 계정 침해가 아니라 관찰된 시도에 관한 내용이다.

Barracuda의 AI 및 자동화 부문 이사인 Merium Khalid는 11월 7일 Cybersecurity Insiders 기고에서 기계 독자를 겨냥해 설계된 메시지를 설명했다. 숨겨진 내용은 무단 전달과 암호화폐 보관 정보 검색을 유도하려 했다. 어시스턴트가 이에 따랐는지는 확인되지 않았다.

이 사안의 충돌 지점은 유용한 위임과 강제 가능한 제한 사이에 있다. Microsoft가 이전에 수정한 EchoLeak 취약점은 역사적 참고 사례를 제공하며, Google은 Gemini를 위한 지속적인 방어 조치를 설명하고 있다. 기업 구매자에게 질문은 점점 더 구체적이다. 어시스턴트가 적대적인 콘텐츠를 읽을 때, 그 콘텐츠가 권한으로 바뀌는 것을 무엇이 막는가?

Barracuda 이메일 프롬프트 인젝션 경고가 확인해 주는 것

Khalid의 설명은 익숙한 브랜드를 사칭한 채용 미끼를 다룬다. 눈에 보이는 메시지 아래에서 숨겨진 HTML은 승인된 내부 절차인 것처럼 지시사항을 제시했다. 의도된 결과에는 동료들의 받은편지함을 통한 확산과 민감한 지갑 정보의 외부 공개가 포함됐다.

공개된 증거는 공격자의 의도를 뒷받침할 뿐, 성공적인 실행을 입증하지는 않는다.

이 설명은 영향을 받은 어시스턴트를 특정하지 않고, 완료된 전송을 문서화하지도 않으며, 측정된 성공률을 제시하지도 않는다. 또한 보호 장치와 권한에 따라 준수 여부가 달라진다고 명시한다. 독자는 관찰된 이메일 공격을 검토할 수 있지만, 요청된 행동을 이미 발생한 사실로 간주해서는 안 된다.

이러한 증거의 경계는 제목의 의미를 바꾼다. 어시스턴트를 겨냥한 공격 시도는 선택된 표적과 원하는 행동을 드러내기 때문에 뉴스 가치가 있다. 그렇다고 해당 메시지를 읽는 모든 어시스턴트가 실패했음을 입증하는 것은 아니다.

이 구분은 사고 대응에도 중요하다. 받은편지함에서 악성 텍스트가 발견되면 이후 활동을 조사해야 한다. 그러나 그것이 정보가 조직 밖으로 유출됐다는 공개적 주장으로 자동 전환되어서는 안 된다.

유용한 조사는 메시지 전달, 어시스턴트 노출, 시도된 작업, 완료된 작업을 구분해야 한다. 이 단계들은 방어 체계가 작동했는지에 대해 서로 다른 질문에 답한다. 이를 하나의 레이블로 뭉뚱그리면 실패와 성공적으로 차단된 사례 모두를 이해하기 어려워진다.

모델이 외부 메시지를 제안하는 것과 서비스가 실제로 이를 전송하는 것의 차이를 생각해 보자. 제안은 추론 실패를 나타낸다. 전송이 차단됐다면 다른 통제 장치가 그 결과를 억제했음을 뜻하기도 한다.

반대로 무해한 최종 응답만으로는 그 전에 아무 일도 일어나지 않았다고 단정할 수 없다. 조사자는 어시스턴트의 마무리 설명만이 아니라 거부된 요청을 포함한 작업 기록이 필요하다.

따라서 Barracuda 이메일 프롬프트 인젝션 설명은 분명한 결론을 뒷받침한다. 공격자들은 위임된 AI 접근 권한을 중심으로 메시지를 설계하고 있다. 이는 자율적으로 확산되는 대규모 사태가 벌어지고 있다는 주장을 뒷받침하지는 않는다.

구매자에게는 이 결론만으로도 더 면밀한 평가를 할 이유가 충분하다. 조직이 자체 설정이 의도된 결과를 허용하는지 점검하기 전에 공개된 피해자 수가 반드시 필요하지는 않다.

당장의 질문은 아키텍처에 관한 것이다. 외부 서신은 단지 어시스턴트의 답변에 정보를 제공하는가, 아니면 어시스턴트가 사용할 수 있는 기능의 방향을 바꿀 수 있는가? 이 질문은 그러한 기능에 권한을 부여하는 직원과 팀으로 곧바로 이어진다.

받은편지함 자동화는 관리자와 구매자에게 압박을 가한다

압박은 어시스턴트의 접근 권한과 행동 능력을 승인하는 사람에게 돌아간다.

직원들은 의사결정을 찾고, 답장을 작성하며, 주의가 필요한 업무를 식별하는 데 도움을 원한다. 관리자는 어떤 권한이 그러한 업무를 지원하는지 결정해야 한다. 이후 보안팀은 그 결정의 결과를 떠안게 된다.

제품이 두 기능을 함께 묶더라도, 읽기와 보내기는 별개의 비즈니스 요구다. 요약 작업이 본질적으로 외부 전송을 요구하는 것은 아니다. 이 기능들을 결합하면 편의성은 더 큰 보안 가정에 의존하게 된다.

그 가정은 조직이 통제하지 않는 사람이 보낸 메시지를 처리하는 동안에도 어시스턴트가 사용자의 의도를 일관되게 보존할 것이라는 점이다. 구매자는 공급업체가 제품에서 이 분리를 어떻게 강제하는지 설명할 것을 기대해야 한다.

비즈니스상 위험은 기밀 데이터에만 그치지 않는다. 왜곡된 요약은 어떤 요청에 주의를 기울일지, 어떤 고객이 불만을 품고 있는지, 어떤 승인이 완료된 것처럼 보이는지를 바꿀 수 있다. 이는 보고된 사례에서 확인된 결과가 아니라 잠재적 영향이다.

조달 어시스턴트가 낯선 공급업체의 메시지를 검토한다고 상상해 보자. 검증되지 않은 지급 정보를 승인된 변경 사항으로 제시한다면, 직원은 근거 없는 확신이 실린 권고를 받게 된다. 어시스턴트는 주장에 수반됐어야 할 불확실성을 압축해 버린 셈이다.

이 가정은 전송 권한이 없는 시스템도 위험을 만들 수 있는 이유를 보여 준다. 직원은 오해를 부르는 요약에 의존한 뒤 최종 실행자가 될 수 있다. 권한 제한은 노출을 줄이지만, 출력 품질에 관한 문제를 해결해 주지는 않는다.

따라서 제품 설계자에게는 두 번째 의무가 생긴다. 의미 있는 판단에 필요한 맥락을 충분히 보존하는 것이다. 요약은 발신자의 주장과 독립적으로 확인된 사실을 구분해야 한다. 또한 판단을 위해 검토가 필요한 경우 원본 메시지에 접근할 수 있게 해야 한다.

같은 우려는 AI 지식 기반에도 적용된다. 검색된 자료는 답변을 뒷받침할 수 있지만, 그 자체로 후속 행동을 지시할 권한을 얻는 것은 아니다. 외부 콘텐츠가 워크플로에 들어오는 모든 곳에서 이 경계는 제품 평가에 포함되어야 한다.

기업 구매자에게 요구되는 대응은 더 큰 구체성이다. 어시스턴트가 안전한지 묻는 것은 포괄적인 보증을 낳는다. 수신 메시지가 외부 전송을 시작할 수 있는지 묻는 것은 검증 가능한 답을 낳는다.

조달 요건에는 허용된 결과, 승인 조건, 이용 가능한 증거를 기술해야 한다. 또한 누가 이러한 설정을 변경할 수 있는지도 식별해야 한다. 그렇지 않으면 면밀히 검토된 배포 환경도 통합 기능이 새로운 역량을 추가한 뒤에는 다른 시스템이 될 수 있다.

이 상충 관계는 철학적 문제가 아니라 실무적 문제다. 더 폭넓은 위임은 직원 업무에서 단계를 줄인다. 위임을 제한하면 검증 지점은 유지되지만 마찰이 늘어난다.

어느 한쪽도 구호만으로 이 상충 관계를 해결할 수는 없다. 유용한 기준은 조직이 관련 없는 행동을 막으면서 의도한 생산성 이점을 얻을 수 있는지다. 이를 위해서는 모델 개선과 함께 워크플로 전반의 통제가 필요하다.

핵심 경계는 읽기와 권한을 구분한다

간접 프롬프트 인젝션은 승인된 사용자 요청이 아니라 AI 시스템이 처리하는 자료 안에 악성 지시사항이 도착하는 것을 뜻한다. 핵심 문제는 잘못 부여된 권한이다.

메시지는 관련 증거일 수 있지만, 승인된 지시사항이 되어서는 안 된다.

숨겨진 서식은 공격을 더 놓치기 쉽게 만들지만, 보이지 않는다는 점이 본질은 아니다. 눈에 명확히 보이는 문단도 어시스턴트의 방향을 바꾸려 할 수 있다. 따라서 은닉 텍스트를 제거하는 것은 전달 기법을 다루는 것이지, 문제 전체를 해결하는 것은 아니다.

더 깊은 문제는 어시스턴트가 외부 언어를 자신의 행동을 위한 지침으로 해석할 때 나타난다. 비즈니스 절차를 설명하는 문서는 그 절차를 실행할 권한과 다르다. 발신자가 승인을 주장하는 것은 인증된 승인과 다르다.

정상적인 메시지에도 요청이 담겨 있을 때 이 구분은 더 어려워진다. 직원들은 동료, 고객, 공급업체로부터 일상적으로 지시를 받는다. 어시스턴트는 모든 요청이 모든 사용 가능한 작업을 승인한다고 가정하지 않으면서 이를 해석해야 한다.

고객이 송장 사본을 요청하는 것은 일반적인 업무다. 어시스턴트가 이를 보내야 하는지는 신원, 접근 권한, 수신처, 회사 정책에 달려 있다. 요청의 문구만으로는 이런 조건을 모두 충족할 수 없다.

도구를 선택하고 호출하는 AI 시스템인 에이전트는 또 다른 의사결정 지점을 만든다. 도구 호출은 작업 수행을 위한 구조화된 요청이다. 그 권한 부여는 분석 대상 메시지 밖의 규칙에 따라야 한다.

예를 들어 애플리케이션은 초안 작성을 허용하면서 전송 전에는 별도의 승인을 요구할 수 있다. 모델이 제안한 작업은 여전히 유용하지만, 애플리케이션은 해당 작업을 허용할지 결정할 책임을 유지한다.

이 아키텍처는 모델의 판단이 완벽하다고 가정하지 않는다. 모델이 실수할 수 있음을 전제로 하고 그 결과를 제한한다. 이는 모델에게 모든 악성 문장을 인식하라고 요구하는 것과는 다른 보안 명제다.

과거 연구는 확산 우려가 주목받을 만한 이유를 보여 준다. 2024년에 발표된 AI 웜 연구는 실험적인 이메일 어시스턴트 환경에서 자기 복제 프롬프트를 연구했다. 연구진은 기밀 데이터 추출과 연결된 시스템을 통한 확산을 평가했다.

이 실험은 상용 어시스턴트가 모두 같은 행동을 허용한다는 증거가 아니라 연구 선례를 확립했다. 그 관련성은 실패 패턴에 있다. 생성된 출력이 적대적 자료를 다른 시스템으로 옮길 수 있다는 점이다.

이는 까다로운 설계 선택을 만든다. 어시스턴트는 분석이나 증거를 위해 의심스러운 콘텐츠를 인용해야 할 수 있다. 하지만 그러한 콘텐츠를 실행 가능한 채널로 복사하면 다른 어시스턴트가 같은 방향 전환 시도에 노출될 수 있다.

적절한 경계는 목적지와 용도에 따라 달라진다. 명확히 표시된 사고 기록에 보존된 자료는 일반적인 발신 메시지에 삽입된 자료와 다른 역할을 한다. 시스템은 이 구분을 유지해야 한다.

이메일 에이전트 하이재킹은 이메일 처리 어시스턴트의 해석이나 행동을 다른 방향으로 돌리려는 시도를 뜻한다. 이 용어는 관찰 가능한 실패를 가리킬 때에만 유용하다. 시스템이 무엇을 읽고, 제안하고, 실제로 수행했는지를 설명하는 일을 대체해서는 안 된다.

Microsoft와 Google은 방어에 여러 계층이 필요한 이유를 보여 준다

관련 업계 비교는 경쟁 어시스턴트의 순위가 아니라 방어 접근 방식에 관한 것이다. 제품마다 노출하는 도구, 콘텐츠 소스, 승인 경로가 다르다.

Microsoft의 AI 애플리케이션 보안 설명은 CVE-2025-32711로 추적되는 EchoLeak이 수정됐다고 밝힌다. 특정 조건에서 조작된 이메일은 Copilot이 피해자가 이미 접근할 수 있는 제한된 정보를 공개하도록 만들 수 있었다.

같은 지침은 상속된 권한과 과도한 접근의 위험을 강조한다. 이는 패치된 취약점과 어시스턴트가 검색할 수 있는 대상을 통제하는 지속적인 관리 업무를 구분한다.

특정 취약점을 해결하는 일과 어시스턴트의 권한을 제한하는 일은 문제의 서로 다른 부분을 해결한다.

Google의 2026년 4월 Workspace injection defenses 논의는 지속적인 테스트와 개선을 설명합니다. 이 접근 방식에는 모델 개선, 사용자 확인, URL 정제, 도구 사용 순서를 규율하는 정책이 포함됩니다.

Google은 공격 방식이 변화함에 따라 이러한 방어 체계도 계속 업데이트되어야 한다고 말합니다. 이 설명은 모델 업그레이드가 적대적 지시를 영구적으로 제거한다는 주장보다는 다층적 접근 방식을 뒷받침합니다.

이러한 입장은 책임을 애플리케이션 전반에 배분합니다. 모델은 콘텐츠를 해석하고, 주변 소프트웨어는 작업을 통제하며, 관리자는 접근 권한을 구성합니다. 한 계층의 취약점이 다른 계층에서 차단된다면 반드시 완료된 유해 행위로 이어질 필요는 없습니다.

이 구분은 제품 비교에 맥락이 필요한 이유도 설명합니다. 요약으로 제한된 어시스턴트와 리포지토리를 검색하고 문서를 전송할 권한을 받은 어시스턴트는 서로 다른 결과에 직면합니다. 일반적인 시연은 이러한 차이를 가릴 수 있습니다.

Check Point의 email agent hijacking 백서는 악성 콘텐츠가 전달되기 전에 차단해야 한다고 주장합니다. 이후 정리 과정에서 메시지가 제거되기 전에 자동화된 처리가 시작될 수 있다고 경고합니다.

이러한 시점에 관한 주장은 수집이 즉시 시작되는 모든 환경과 관련이 있습니다. 그러나 전달 전 보호만이 유일하게 효과적인 접근 방식이라는 더 강한 벤더의 주장은 면밀한 검토가 필요합니다. 전달을 막더라도 검사에서 무언가를 놓쳤을 때 작업을 통제해야 할 필요성이 사라지지는 않습니다.

따라서 구매자는 예방과 억제를 함께 평가해야 합니다. 필터는 노출을 줄일 수 있습니다. 독립적으로 강제되는 전송 제한은 노출된 어시스턴트가 무단 전송을 완료하지 못하게 할 수 있습니다.

복구 문제도 있습니다. 받은편지함에서 메시지를 제거했다고 해서 파생된 모든 요약이나 보류 중인 초안까지 사라졌다는 뜻은 아닙니다. 조직은 제품이 영향을 받은 후속 자료를 어떻게 식별하고 무효화하는지 물어야 합니다.

이는 모든 제품이 그러한 자료를 보존한다는 주장이 아니라 평가 요건입니다. 구현 방식은 다릅니다. 벤더는 고객이 활성화하려는 특정 기능의 동작을 설명해야 합니다.

사람의 승인 역시 이 비교에 포함되어야 합니다. 그 가치는 승인 화면이 무엇을 보여주는지에 달려 있습니다. 수신자나 첨부 파일을 숨기는 확인 절차는 실제 작업을 제시하는 절차보다 의미 있는 감독을 덜 제공합니다.

따라서 경쟁 압력은 구체적입니다. 벤더는 시스템이 어디에서 경계를 강제하는지, 실패가 기록에 어떻게 나타나는지, 무엇이 관리자 통제하에 남는지를 보여줘야 합니다. 책임 있는 AI에 관한 일반적 보장만으로는 이러한 질문에 답할 수 없습니다.

관찰된 페이로드는 확인된 침해가 아니다

Barracuda의 이메일 프롬프트 인젝션 경고는 여러 질문을 남깁니다. 공개된 설명은 공격의 유행 정도를 입증하지 않고, 표적이 된 어시스턴트를 식별하지 않으며, 완료된 확산을 보여주지도 않습니다.

공격자의 목적이 분명하더라도 결과에 관한 증거가 부족하면 결론에는 한계가 있습니다.

이 한계는 보도와 구매 결정을 좌우해야 합니다. 상세한 악성 메시지는 기능을 추구하는 행위를 입증할 수 있습니다. 그러나 현재 운영 환경의 시스템이 얼마나 자주 이에 따르는지는 독립적으로 입증할 수 없습니다.

독립 연구는 이러한 증거 공백을 메우지 않으면서도 근본적인 우려를 검증하는 데 도움이 됩니다. 2026년 10월 개정된 LLMail-Inject benchmark에는 839명의 참가자로부터 수집한 서로 다른 사람이 작성한 공격 프롬프트 208,095개가 포함되어 있습니다.

이 평가에는 이메일 데이터베이스에서의 검색, 방어 체계 통과, 그리고 필요한 인수를 갖춘 무단 도구 호출이라는 일련의 사건이 필요합니다. 이 설계는 모델이 의심스러운 텍스트를 반복하는지 여부 이상을 검토합니다.

벤치마크가 보고한 결과는 테스트된 구성에 한정됩니다. 이를 기업 받은편지함의 예상 침해율로 바꿔서는 안 됩니다. 배포 권한, 검색 동작, 애플리케이션 통제는 공격이 달성할 수 있는 범위에 영향을 미칩니다.

실패한 공격은 여러 지점에서 실패할 수 있습니다. 메시지가 모델의 컨텍스트에 전혀 들어가지 않을 수 있습니다. 모델이 시도된 방향 전환을 거부할 수 있습니다. 제안된 작업이 독립적인 권한 확인을 통과하지 못할 수도 있습니다.

이러한 결과는 미래 위험에 서로 다른 의미를 가집니다. 필터 누락 후 성공적인 권한 차단은 억제를 보여줍니다. 모델의 거부는 해당 시도에 관한 증거를 제공하지만, 주변의 작업 경계는 검증되지 않은 상태로 남습니다.

마찬가지로 성공적인 실험실 공격이 고객을 겨냥한 활성 캠페인을 입증하지는 않습니다. 이는 해결할 가치가 있는 실패를 식별합니다. 보도는 실험적 취약성과 관찰된 운영상 피해의 차이를 유지해야 합니다.

모든 측면에는 상업적 유인이 있습니다. 보안 공급업체는 새롭게 부상하는 노출을 강조할 유인이 있습니다. 어시스턴트 벤더는 성공적인 방어를 강조할 유인이 있습니다. 어느 쪽의 유인도 그들의 증거를 무효화하지는 않지만, 둘 다 명확한 방법론의 가치를 높입니다.

구매자는 버전, 활성화된 기능, 공격 조건, 완료된 결과에 관한 정보를 찾아야 합니다. 또한 독립된 주체가 관련 결과를 재현할 수 있는지 물어야 합니다. 극적인 스크린샷은 이런 질문에 거의 답하지 못합니다.

그렇지 않으면 AI 어시스턴트 피싱이라는 표현은 행동 지침으로 삼기에는 지나치게 광범위해질 수 있습니다. 요약을 조작하는 것, 무단 검색을 유도하는 것, 비밀을 전송하는 것은 관련되어 있지만 서로 다른 결과입니다. 각각에는 고유한 증거가 필요합니다.

동일한 원칙은 피해자의 일반적인 클릭이 필요 없는 공격을 뜻하는 제로클릭 주장에도 적용됩니다. 클릭이 없다고 해서 전제 조건이 없다는 뜻은 아닙니다. 어시스턴트에는 여전히 노출과 관련 기능이 필요합니다.

숨겨진 지시가 있을 수 있다고 해서 모든 이메일이 실행 가능한 것은 아닙니다. 처리, 해석, 권한 부여, 실행은 여전히 별개의 단계입니다. 인터페이스가 워크플로를 연속적으로 느끼게 하더라도 안전한 설계는 이러한 분리를 유지해야 합니다.

균형 잡힌 판단은 공격 방향은 주목할 만하지만, 보고된 결과는 여전히 제한적이라는 것입니다. 조직은 공개된 설명이 입증하지 못하는 광범위한 침해를 주장하지 않고도 자체 노출을 조사할 수 있습니다.

다음 증거는 결과와 강제 가능한 제한을 보여줘야 한다

향후 몇 달은 경고의 양이 아니라 구체적인 증거를 통해 평가되어야 합니다. Barracuda의 이메일 프롬프트 인젝션 설명은 출발점을 제공합니다. 후속 보도와 제품 변경이 그 영향이 어디까지 확장되는지를 결정할 것입니다.

가장 유용한 신호는 적대적 콘텐츠가 요청하는 것과 시스템이 허용하는 것 사이의 문서화된 경계입니다.

첫째, 관찰된 시도에 관한 더 완전한 기술 설명을 주시해야 합니다. 유용한 추가 정보에는 어시스턴트 환경, 활성화된 권한, 수집 경로, 그에 따른 활동이 포함됩니다. 차단된 작업의 증거는 완료된 작업의 증거만큼 유익할 수 있습니다.

실제 전달이나 공개를 보여주는 추적 기록은 운영상 악용 주장을 강화할 것입니다. 반대로 거부를 보여주는 추적 기록은 어떤 보호 장치가 유지되었는지를 명확히 할 것입니다. 결과 증거가 없는 추가 악성 샘플은 표본 집합을 확장하지만 효과의 불확실성은 남깁니다.

공격 의도는 성공보다 관찰하기 쉽기 때문에 이 구분은 중요합니다. 더 많은 페이로드를 공개하면 실험이 이루어지고 있음을 보여줄 수 있습니다. 성공적인 악용을 입증하려면 페이로드를 완료된 무단 결과와 연결해야 합니다.

둘째, 외부 전송, 배포 목록, 민감한 검색에 대한 더 세밀한 통제를 제공하는 제품 출시를 주시해야 합니다. 의미 있는 변화는 제한이 적용되는 위치를 설명하는 문서와 함께 제공되는 강제 가능한 구성일 것입니다.

새로운 경고 배너만으로는 억제의 증거가 덜합니다. 모델의 권고와 무관하게 무단 작업을 차단하는 통제는 안전한 위임을 더 강력하게 뒷받침할 것입니다.

여기서는 사용성도 중요합니다. 통제가 일상 업무를 막거나 불분명한 승인 요청을 생성하면 조직은 이를 유지하기 어려울 것입니다. 가장 강력한 설계는 유용한 지원을 유지하면서 중대한 작업을 이해할 수 있게 해야 합니다.

셋째, 현실적인 받은편지함 조건에서 업데이트된 어시스턴트를 대상으로 한 독립 평가를 주시해야 합니다. 이러한 테스트는 악성 콘텐츠가 모델에 도달하는지, 어떤 도구를 사용할 수 있는지, 유해한 작업이 완료되는지를 고려해야 합니다.

다양한 공격에 대해서도 강력한 결과가 유지된다면 테스트된 구성에 대한 신뢰를 뒷받침할 것입니다. 메시지 구조나 워크플로의 작은 변경 후 실패가 발생한다면 폭넓은 보호 주장에는 힘이 빠질 것입니다.

이러한 관찰에는 비즈니스 분모가 필요합니다. 의심스러운 요청을 차단하지만 정상 업무까지 막는 방어책은 선택적 통제와 다른 비용을 초래합니다. 평가는 공격 결과와 함께 일상 작업 완료율도 보고해야 합니다.

지식 근로자에게 즉각적인 의미는 위임된 업무에 대한 신뢰와 관련됩니다. 세련된 요약도 여전히 원본 자료에 대한 해석입니다. 중대한 결정에는 메시지, 발신자, 해결되지 않은 주장으로 돌아갈 수 있는 경로가 필요합니다.

보안팀에 주는 의미는 증거와 관련됩니다. 어시스턴트의 설명은 접근한 리소스와 시도한 작업에 대한 기록을 대체할 수 없습니다. 이러한 기록이 시작 작업에 직접 연결될 때 조사는 더 쉬워집니다.

개발자에게 주는 의미는 책임과 관련됩니다. 모델은 작업을 권고할 수 있지만, 그 작업이 사용자의 권한에 부합하는지는 애플리케이션이 결정해야 합니다. 외부 콘텐츠가 시스템이 행사하기를 원하는 권한을 제공해서는 안 됩니다.

받은편지함 자동화를 확대하기 전에, 벤더에게 격리된 환경에서 의도적으로 적대적인 테스트 메시지를 상대로 일상 작업을 시연해 달라고 요청하십시오. 무엇이 어시스턴트의 컨텍스트에 들어가는지, 무엇을 시도하는지, 애플리케이션이 무엇을 허용하는지 검토하십시오. 이 훈련이 저항성과 함께 유용성도 측정하도록 일반 메시지도 포함하십시오. 승인 화면에는 실제 수신자와 공유 자료가 표시되도록 요구하십시오. 완료된 작업뿐 아니라 차단된 작업도 기록으로 남기십시오. AI 어시스턴트 피싱이 제기하는 핵심 질문은 입력이 적대적으로 변할 때도 위임이 제한된 상태로 유지되는지입니다. 다음 권한을 부여하기 전에 그 경계에 관한 증거를 요구하십시오.