프롬프트 인젝션에 대한 Apple의 자체 해법

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

세션 347의 5분 55초 지점에서 인용된 lethal trifecta.

핵심 요약

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

독트린: 결정론적인 것 먼저, 확률론적인 것 다음

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

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

위협 모델의 한 가지 미묘한 지점은 주목할 가치가 있는데, 대부분의 허용 목록이 놓치는 경우를 잡아내기 때문입니다. 타이머 생성 작업은 그 선택적 label 매개변수를 알아차리기 전까지는 무해해 보입니다. 프롬프트 인젝션이 label을 공격자가 제어하는 텍스트로 설정할 수 있고, “그러면 이후 타이머를 나열하는 쿼리가 이 공격자 제어 데이터를 그 컨텍스트로 끌어와, 새로운 컨텍스트까지 오염시킬 수 있습니다.”¹ 쓰기 가능한 문자열 필드를 가진 부작용 없는 도구는 인젝션을 위한 지속화 메커니즘입니다.

Foundation Models 가드레일 API

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

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

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

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

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

잠금 화면 노출도 같은 처리를 받습니다. Siri는 잠긴 디바이스에서도 동작하므로, 물리적으로 디바이스를 손에 넣은 공격자가 여러분의 intent에 도달할 수 있습니다. 따라서 커스텀 intent는 authenticationPolicy를 설정하고, 스키마는 민감도 기반 기본값을 지니며, 제약은 정확히 옳습니다. “스키마 정책을 재정의할 수 있지만, 더 엄격하게 만드는 방향으로만 가능합니다.” 정책을 약화하려고 하면 허용되는 최소 정책을 명시하는 빌드 오류가 발생합니다.¹ 컴파일러가 작업을 과소 보호하도록 내버려 두지 않는 것은, 상상할 수 있는 가장 Apple다운 프롬프트 인젝션 완화책입니다.

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

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

confidential computing의 현 상황과 비교했을 때 두드러지는 두 가지 설계 선택이 있습니다. 손상되면 사용자 데이터를 유출시킬 수 있는 구성 요소에 대해, “소프트웨어 어테스테이션은 독립적인 공급사로부터 나온 최소 두 개의 별도 신뢰 루트에 뿌리내려져 있고”, Apple은 공급망 공격에 대비해 “PCC 플릿의 일부인 모든 Google Cloud 하드웨어에 대한 암호학적으로 검증 가능한 추가 전용 원장”을 유지합니다.² Apple silicon 위의 PCC에서 가져온 아키텍처 패턴도 그대로 이어집니다. 전용 네임스페이스 프로세스에서의 요청별 네트워크 파싱, 짧은 time-to-live로 재활용되는 공유 추론 소프트웨어, 외부 입력으로부터 격리된 별도의 confidential VM에 보관되는 어테스트된 키입니다.² 제어는 중앙에 머뭅니다. “Apple은 PCC 소프트웨어에 대한 완전한 통제를 유지합니다. Apple 디바이스는 Apple이 암호학적으로 승인한 PCC 소프트웨어만 신뢰합니다.” 모든 바이너리는 공개 검사를 위해 게시되며, 라이브 연구 모드 노드는 Apple Security Bounty 프로그램을 통해 접근할 수 있습니다.² 출시는 단계적으로 이루어지며, “여름 프리뷰 기간 내내 완전한 보호 집합을 향해 점진적으로 늘려갑니다.”²

랩이 더한 것

Privacy and Security 그룹 랩은 같은 주에 진행됐고, Apple은 랩에 대해 자막을 게시하지 않으므로, 이하 내용은 인용이 아니라 로컬에서 기록한 녹음을 옮겨 적은 것을 의역한 것입니다.³ 패널은 세션의 독트린을 출시 표면과 연결했습니다. 결정론적 더하기 확률론적 스택은 Siri AI, Safari, 그리고 Xcode의 에이전트 기능 전반에 걸쳐 동작하며, Xcode가 MCP 서버로 동작할 때는 허용된 도구의 허용 목록으로 에이전트를 제약합니다.³ Siri AI 아키텍처에 대해, 한 패널은 사용자 데이터가 Private Cloud Compute로 떠나기 전에 그것을 수집하고 포맷하는 유일한 경로로서, 권한 게이팅을 갖춘 전용 강화 샌드박스 데몬을 설명했으며, 멀티턴 요청은 대화 중 새로 접근하는 데이터에 대해 권한을 다시 요청한다고 했습니다.³

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

여기서 얻을 것

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

FAQ

프롬프트 인젝션에 대한 Apple의 권장 방어책은 무엇인가요?

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

어떤 API가 이 가드레일을 구현하나요?

Foundation Models에서는 라이프사이클 이벤트 수정자입니다. .onToolCall(실행 전에 모든 도구 호출을 결정론적으로 가로채고, 오류를 던지면 도구를 차단)과 .historyTransform(매 추론 패스 전에 transcript 꼬리를 다시 작성)이며, 지속적 변환을 위해 @SessionProperty가 있습니다.¹ App Intents에서는 스키마 상속 위험 메타데이터가 맥락에 맞는 확인을 이끌고, authenticationPolicy가 더 엄격하게만 가능한 재정의로 잠금 화면 접근을 통제합니다.¹

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

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

이 중 무엇이라도 Apple 플랫폼 밖에 적용되나요?

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

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

References