prompt injection에 대한 Apple의 자체 해법

이제 Apple은 Simon Willison을 직접 이름으로 인용합니다. WWDC 2026 세션 347에서 한 Apple 보안 엔지니어는 agentic 위험을 이 블로그의 보안 스레드가 1년 동안 다뤄온 방식 그대로 정리합니다. “우리는 Simon Willison의 Lethal Trifecta를 참고할 수 있는데, 이는 agentic 시스템이 비공개 데이터에 접근하고, 신뢰할 수 없는 콘텐츠에 노출되며, 외부로 통신할 수 있는 능력을 동시에 갖출 때 사용자가 가장 큰 위험에 처한다는 것을 설명합니다.”¹ 이 세션, Privacy and Security 그룹 랩, 그리고 같은 주에 발표된 security.apple.com 공지는 함께 모여, 가장 큰 기기 규모를 보유한 플랫폼 공급자가 agent 보안을 어떻게 바라보는지에 대한 지금까지 가장 완전한 그림을 보여줍니다. 즉, 기준선으로서의 결정론적 가드레일, 보강 수단으로서의 확률론적 가드레일, 그리고 그 모든 것 아래를 떠받치는 인프라 증명입니다.

lethal trifecta, 세션 347의 5:55 지점에서 인용됨.

TL;DR

• 세션 347은 Apple의 자체 prompt injection 교리입니다. 위협 모델링을 통해 신뢰할 수 없는 컨텍스트를 식별한 다음, “보안 보장을 감사하고 추론하기가 더 쉽기 때문에 결정론적 완화를 기준선으로 삼는 데 집중”하고, 그 위에 spotlighting 같은 확률론적 완화를 겹쳐 쌓습니다.¹
• 가드레일은 조언이 아니라 출시된 API입니다. Foundation Models의 라이프사이클 이벤트 수정자는 결정론적 훅을 제공합니다. .onToolCall은 모든 tool 호출을 실행 전에 가로채고 예외를 던져 차단하며, .historyTransform은 spotlighting 구분자와 PII 마스킹을 위해 매 추론 패스 직전에 transcript를 재작성합니다.¹
• App Intents는 위험을 자동으로 적용합니다. intent는 자신이 채택한 schema로부터 위험 메타데이터를 상속받고, 위험 평가 시스템이 맥락에 맞는 확인을 트리거하며, authenticationPolicy는 더 엄격한 방향으로만 재정의할 수 있습니다.¹
• 같은 주에 Apple은 Private Cloud Compute를 자사 데이터센터 너머 NVIDIA 하드웨어 기반의 Google Cloud로 확장했으며, 동일한 다섯 가지 핵심 요구사항을 유지하고 소프트웨어 증명을 “독립적인 공급업체로부터 나온 최소 두 개의 별도 신뢰 루트”에 뿌리내렸습니다.²
• Privacy and Security 그룹 랩은 그 결을 채워 넣었습니다. Apple은 이 결정론적+확률론적 스택을 Siri AI, Safari, Xcode 전반에 걸쳐 사용한다고 설명하며, Xcode가 MCP 서버로 동작할 때 그 agentic 기능은 tool 허용 목록을 사용합니다.³

교리: 결정론적이 먼저, 확률론적이 나중

세션 347은 예제 앱을 위협 모델 전반에 걸쳐 살펴보는데, 이는 프로덕션에서 agent를 운영하는 사람이라면 누구에게나 익숙해 보일 것입니다. 간접 prompt injection은 “제어 흐름을 다른 곳으로 돌리려는 의도로 모델에 제공된 추가 컨텍스트에 삽입된 지시”로 정의되며, 세션은 그 결과를 따로 구분해 둘 가치가 있는 두 가지 효과로 나눕니다. 하나는 데이터 오염, 즉 “공격자가 실행되는 동작의 매개변수에 영향을 미치는 것”이고, 다른 하나는 동작 오염, 즉 “공격자가 어떤 동작을 실행할지에 영향을 미치는 것”입니다.¹ 이 세션은 공급자 자료에서는 좀처럼 보기 힘든 방식으로 현재 기술 수준에 대해 솔직합니다. “간접 prompt injection을 해결하는 것은 활발한 연구 영역으로, 이는 현재로서 우리의 최선의 접근법이 앱이 얼마나 위험에 처해 있는지 이해하고 그 위험을 완화하는 것을 목표로 삼는 것임을 의미합니다.”¹

순서 원칙은 디자인 리뷰에서 인용할 만한 부분입니다. 결정론적 완화가 먼저인 이유는 “보안 보장을 감사하고 추론하기가 더 쉽기 때문”입니다. 확률론적 완화는 “서로 다른 모델이 이러한 제한을 더 효과적으로 시행할 수 있기 때문”에 추가할 가치가 있지만, 세션은 곧바로 그 한계를 인정합니다. spotlighting은 “prompt injection이 spotlighting을 무력화하는 방식으로 구성될 수 있기 때문에 확률론적 완화”입니다.¹ 사용자 확인과 기기 잠금 해제 요구사항은 장부의 결정론적 쪽에 자리합니다. 마스킹은 PII가 애초에 모델에 도달하지 못하게 하므로 “따라서 유출될 수 없습니다.”¹ Apple은 Siri AI를 설계하는 데 이러한 완화 수단을 사용했다고 밝힙니다.¹

위협 모델에서 나온 한 가지 미묘한 점은 대부분의 허용 목록이 놓치는 사례를 포착하므로 주목할 가치가 있습니다. 타이머 생성 동작은 그 선택적 라벨 매개변수를 알아차리기 전까지는 무해해 보입니다. prompt injection이 라벨을 공격자가 제어하는 텍스트로 설정할 수 있고, “이후 타이머 목록을 조회하는 쿼리가 이 공격자 제어 데이터를 그 컨텍스트로 끌어들여, 새로운 컨텍스트까지 오염시킬 수 있습니다.”¹ 쓰기 가능한 문자열 필드를 가진 부작용 없는 tool은 injection의 지속 메커니즘이 됩니다.

Foundation Models 가드레일 API

세션의 구현 절반은 이 교리를 두 개의 출시된 표면에 매핑합니다. Foundation Models 프레임워크에서 라이프사이클 이벤트 수정자는 “세션 실행의 특정 라이프사이클 지점에서 결정론적으로 트리거되는 콜백”입니다.¹

.onToolCall은 동작 검문소입니다. 이는 “LLM이 tool 호출을 출력할 때, executor가 tool을 실행하기 전에 트리거되도록 보장”되며, 유용한 부분은 그 계약입니다. “이 콜백이 오류를 던지면, 해당 tool은 결코 실행되지 않습니다.”¹ 세션의 예제는 한 곳에서 재무적 영향을 미치는 tool을 사용자 확인 뒤에 게이팅하면서 세션 내 모든 tool 호출에 대한 커버리지를 얻습니다. 그 형태는 이 블로그가 승인 프롬프트는 인가가 아니다에서 주장한 바로 그것입니다. 검사는 모델의 지시가 아니라 실행 경로 안에 자리합니다.

.historyTransform은 입력 검문소입니다. 이는 새로운 사용자 요청이 있을 때와 모든 루프 반복마다, “transcript가 추론을 위해 모델에 렌더링되기 전에 발동”하며, 세션은 이를 두 가지 프롬프트 완화에 사용합니다. 신뢰할 수 없는 출처의 tool 출력을 spotlighting 구분자로 감싸는 것과, 민감한 데이터를 마스킹 자리표시자로 교체하는 것입니다.¹ 구현자에게 중요한 세부 사항이 있습니다. 변환된 항목은 현재 추론 패스에만 한정되므로 변환은 매 반복마다 다시 적용되며, 비용이 큰 상태 보존 변환을 위한 탈출구로 @SessionProperty 애너테이션이 있습니다.¹

App Intents: 작성하는 것이 아니라 상속받는 위험 메타데이터

Siri를 향하는 쪽은 schema 시스템에서 가드레일을 얻습니다. intent가 intent schema를 채택하면, 위험 메타데이터가 그 schema의 부작용에 따라 “자동으로 할당”됩니다. 파괴적이거나, 유출하거나, 공유 콘텐츠를 갱신하는 동작은 더 위험하며, “시스템은 고위험 tool에 대해 확인을 트리거할 가능성이 더 높습니다.”¹ 위험 평가 시스템은 그 정적 메타데이터를 동적 시스템 상태와 결합해, intent가 실행되기 전에 확인을 끼워 넣을지를 맥락에 맞게 결정합니다. 거절하면 intent는 완전히 차단됩니다.¹

잠금 화면 노출도 같은 처리를 받습니다. Siri는 잠긴 기기에서도 작동하므로, 물리적으로 기기를 소지한 공격자가 여러분의 intent에 접근할 수 있습니다. 따라서 커스텀 intent는 authenticationPolicy를 설정하고, schema는 민감도 기반 기본값을 가지며, 그 제약은 정확히 옳습니다. “schema 정책을 재정의할 수는 있지만, 더 엄격하게 만드는 방향으로만 가능”하며, 이를 약화하려 하면 허용되는 최소 정책을 명시한 빌드 오류가 발생합니다.¹ 컴파일러가 동작을 과소 보호하지 못하게 거부하는 것이야말로 상상할 수 있는 가장 Apple다운 모습의 prompt injection 완화입니다.

인프라 계층: PCC가 Apple의 데이터센터를 떠나다

세션이 방영되기 사흘 전, Apple은 자사 보안 블로그에 “Private Cloud Compute 확장”을 게시했습니다. 새로운 Apple Intelligence 워크로드가 이제 NVIDIA GPU 기반의 Google Cloud에서 실행되며, “업계 선도적인 PCC 프라이버시 약속을 처음으로 제3자 데이터센터로 확장”한다는 것입니다.² 다섯 가지 핵심 요구사항은 그대로 이어집니다. “무상태 연산, 시행 가능한 보장, 특권 런타임 접근 없음, 표적화 불가능성, 그리고 검증 가능한 투명성.”² 바뀌는 것은 구현입니다. NVIDIA Confidential Computing, TDX를 갖춘 Intel CPU, 그리고 Google의 Titan 칩입니다.²

기밀 컴퓨팅의 현 상태와 견주어 두 가지 설계 선택이 두드러집니다. 손상될 경우 사용자 데이터를 유출할 수 있는 구성 요소에 대해 “소프트웨어 증명은 독립적인 공급업체로부터 나온 최소 두 개의 별도 신뢰 루트에 뿌리내려” 있으며, Apple은 공급망 공격에 대비해 “PCC 플릿의 일부인 모든 Google Cloud 하드웨어에 대한 암호학적으로 검증 가능한 추가 전용 원장”을 유지합니다.² Apple 실리콘 기반 PCC의 아키텍처 패턴도 그대로 이어집니다. 전용 네임스페이스 프로세스에서의 요청별 네트워크 파싱, 짧은 time-to-live로 재활용되는 공유 추론 소프트웨어, 외부 입력으로부터 격리된 별도의 기밀 VM에 보관되는 증명된 키가 그것입니다.² 통제는 중앙집중 상태로 유지됩니다. “Apple은 PCC 소프트웨어에 대한 완전한 통제권을 유지하며, Apple 기기는 Apple이 암호학적으로 승인한 PCC 소프트웨어만 신뢰”하고, 모든 바이너리는 공개 검사를 위해 게시되며 라이브 연구 모드 노드는 Apple Security Bounty 프로그램을 통해 접근할 수 있습니다.² 배포는 단계적이며, “여름 프리뷰 기간 동안 완전한 보호 집합을 향해 점진적으로 확대”됩니다.²

랩이 더한 것

Privacy and Security 그룹 랩은 같은 주에 진행되었고, Apple은 랩에 대해 캡션을 게시하지 않으므로 이어지는 내용은 인용이 아니라 로컬에서 전사한 녹음을 바탕으로 한 의역입니다.³ 패널은 세션의 교리를 출시된 표면과 연결했습니다. 결정론적+확률론적 스택은 Siri AI, Safari, 그리고 Xcode의 agentic 기능 전반에 걸쳐 실행되며, Xcode가 MCP 서버로 동작할 때는 허용된 tool의 허용 목록으로 agent를 제약합니다.³ 별도의 Apple Intelligence 랩은 개발자들이 혼동하는 두 가지 실패 모드 사이에 유용한 선을 그었습니다. 한 패널은 거부 오류(모델 자체의 정렬 학습이 요청을 거절하며, 가이드 생성이나 구조화 생성 하에서 그 실패가 드러나는 경우)와 가드레일 오류(별도의 조정 모델이 메인 모델과 독립적으로 입력과 출력을 검사하는 경우)를 구분했습니다.⁵ 같은 패널은 가드레일을 작동시키는 대신, 감정이 격앙되었지만 정당한 입력을 통과시키는 옵트인 설정을 언급했는데, 그 설정의 정확한 이름은 녹음에서 식별할 수 없어 미확인으로 남겨둡니다.⁵ Siri AI 아키텍처에 관해 한 패널은, 데이터가 Private Cloud Compute로 떠나기 전에 사용자 데이터를 수집하고 형식화하는 유일한 경로로서 자격(entitlement) 게이팅을 갖춘 전용 강화·샌드박스 데몬을 설명했으며, 다중 턴 요청은 대화 도중 새로 접근한 데이터에 대해 권한을 다시 요청한다고 했습니다.³

두 가지 랩 스레드는 후속 확인을 위해 표시해 둘 가치가 더 있습니다. 패널은 Foundation Models의 프라이버시 보장이 프레임워크의 언어 모델 프로토콜을 통해 도달하는 제3자 모델에는 적용되지 않는다고 했습니다. 그 공급자들의 약관을 읽고 그에 맞게 고지하는 책임은 개발자에게 있습니다.³ 그리고 WebAuthn 도입을 줄곧 괴롭혀 온 passkey 라이프사이클 문제에 관해, 한 패널은 해결된 답으로 Signal API를 지목했습니다. 웹 표준은 이제 의존 당사자와 인증자 사이에서 자격 증명을 동기화 상태로 유지하기 위한 signalUnknownCredential, signalAllAcceptedCredentials, signalCurrentUserDetails를 정의하며, 이 API는 실재하고 W3C WebAuthn Level 3에서 출시되어 있습니다.⁴

여기서 취할 것

유용한 점은 Apple이 prompt injection을 해결했다는 것이 아닙니다. 세션은 아무도 해결하지 못했다고 분명히 말합니다. 유용한 점은 한 플랫폼 공급자가 어떤 순서에 헌신하는 모습을 지켜보는 것입니다. 실행 경로 안의 결정론적 통제가 먼저, 모델 수준의 힌트가 둘째, 그 아래의 인프라 증명입니다. Apple 플랫폼 밖에서 agent를 만드는 사람들에게는 모든 조각에 대응물이 있습니다. .onToolCall은 여러분의 tool 호출 인터셉터이고, .historyTransform은 여러분의 컨텍스트 살균기이며, schema에서 상속된 위험 메타데이터는 여러분의 tool 분류 표이고, 더 엄격한 방향으로만 가능한 authenticationPolicy 재정의는 여러분의 정책 하한선입니다. 프레임워크 이름은 Apple의 것이지만, 아키텍처는 이식 가능하며, 이는 이 블로그가 신뢰할 수 없는 두 입력을 가진 agent와 tool 보강 agent를 위한 런타임 방어에서 제시한 심층 방어와 일치합니다.

FAQ

prompt injection에 대한 Apple의 권장 방어책은 무엇인가요?

먼저 위협 모델링을 하고(신뢰할 수 없는 컨텍스트 출처와 동작의 부작용을 식별), 그다음 “보안 보장을 감사하고 추론하기가 더 쉽기 때문에 결정론적 완화를 기준선으로” 적용하며, 그 위에 spotlighting 같은 확률론적 완화를 더합니다.¹ 구체적으로는, 위험한 동작에 대한 사용자 확인과 기기 잠금 해제 요구사항, 그리고 신뢰할 수 없는 컨텍스트에 대한 PII 마스킹과 spotlighting 구분자입니다.

이러한 가드레일을 구현하는 API는 무엇인가요?

Foundation Models에서는 라이프사이클 이벤트 수정자가 있습니다. .onToolCall(모든 tool 호출을 실행 전에 결정론적으로 가로채며, 예외를 던지면 tool이 차단됨)과 .historyTransform(매 추론 패스 직전에 transcript 꼬리 부분을 재작성)이며, 영속 변환을 위한 @SessionProperty가 있습니다.¹ App Intents에서는 schema에서 상속된 위험 메타데이터가 맥락에 맞는 확인을 유도하고, authenticationPolicy가 더 엄격한 방향으로만 가능한 재정의로 잠금 화면 접근을 제어합니다.¹

Apple이 정말로 Private Cloud Compute를 Google 클라우드로 옮겼나요?

네, 새로운 Apple Intelligence 워크로드에 한해서입니다. PCC는 이제 Intel TDX와 Google의 Titan 칩을 갖춘 NVIDIA GPU 기반의 Google Cloud로 확장되며, 동일한 다섯 가지 PCC 요구사항, 이중 공급업체 증명 루트, 추가 전용 하드웨어 원장, 그리고 Apple 전용 소프트웨어 승인을 유지한 채 여름 프리뷰 기간에 걸쳐 확대됩니다.² PCC의 보장은 여전히 언어 모델 프로토콜을 통해 도달하는 Gemini나 Claude 같은 제3자 모델에는 적용되지 않습니다.³

이 중 어느 것이라도 Apple 플랫폼 밖에 적용되나요?

아키텍처는 적용됩니다. 실행 경로 인터셉터, 컨텍스트 살균기, tool 위험 분류, 그리고 정책 하한선은 이식 가능한 패턴입니다. Apple의 버전이 주목할 만한 이유는, 이것들이 지침이 아니라 결정론적 계약을 갖춘 프레임워크 API로 출시되기 때문입니다.

Apple의 완화 스택은 이 블로그가 1년 동안 그려온 영역에 안착합니다. 신뢰할 수 없는 두 입력을 가진 agent에서의 trifecta 프레이밍, 승인 프롬프트는 인가가 아니다에서의 실행 경로 논증, 그리고 Foundation Models와 Private Cloud Compute에서의 인프라 이야기가 그것입니다. 전체 시리즈 허브는 Apple Ecosystem 시리즈입니다.

References