Agentforce 데이터 보안을 마스킹 기능으로 끝내려는 팀이 많습니다. Salesforce는 Agentforce가 Einstein Trust Layer(아인슈타인 트러스트 레이어) 위에 있다고 설명합니다. 동시에 공식 Privacy FAQ와 Trailhead Trust Layer 모듈은 에이전트에 대한 LLM 데이터 마스킹이 현재 꺼져 있다고 밝힙니다. 켜진 계층과 꺼진 통제를 나누지 않으면, 보안 심사는 통과한 것처럼 보이고 실제 노출 경로는 남습니다.
사람의 권한은 화면과 보고서 단위로 정해집니다. 에이전트는 화면이 아니라 데이터에 질의하고, 그 결과를 자연어로 다시 구성합니다. 마스킹이 꺼진 상태에서는 실행 맥락에 붙은 필드가 프롬프트와 모델 호출에 그대로 실릴 수 있습니다. 이 글은 그 전제에서 권한 모델과 개인정보 보호법(PIPA) 처리 경로를 다시 그리는 방법을 정리합니다. 법률 자문이 아닙니다.
에이전트는 실행 맥락의 권한으로 동작합니다
조직의 권한 모델은 대부분 사람을 기준으로 만들어졌습니다. 프로파일, 역할 계층, 공유 규칙, 필드 수준 보안. 이 통제는 화면을 보는 사용자를 전제합니다. 에이전트가 등장하면 전제가 흔들립니다. 어떤 사용자 또는 게스트 맥락에서 실행되는지, 그 맥락이 어떤 데이터까지 읽고 쓸 수 있는지가 새로 정의돼야 합니다.
Salesforce의 Privacy FAQ는 에이전트 유형을 나눕니다. 어떤 유형은 Salesforce 사용자를 업무 흐름 안에서 돕고, 다른 유형은 관리자가 정한 사용 사례와 가드레일 범위에서 사용자 또는 고객을 대신해 행동합니다. 어느 쪽이든 에이전트가 자기만의 초월 권한을 갖는 구조로 설명하지 않습니다. 실행 맥락에 넓은 권한이 붙어 있으면, 에이전트도 그만큼 넓게 봅니다.
흔한 실수는 구축 편의를 위해 시스템 관리자에 가까운 강한 권한으로 에이전트를 띄우고, 그 설정을 프로덕션까지 끌고 가는 것입니다. 그 순간 에이전트는 조직의 거의 모든 데이터에 닿는 단일 창구가 됩니다. 마스킹이 꺼져 있으면 그 창구가 모델 쪽으로도 열립니다.
권한 경계는 사람 기준이 아니라 에이전트 실행 맥락 기준으로 다시 그어야 합니다. 먼저 에이전트가 답해야 하는 질문 목록을 만들고, 각 질문에 필요한 최소 데이터를 정의합니다. 그 최소 집합만 허용하는 전용 권한 세트를 만들고, 실행 맥락에 그 권한만 부여합니다. FAQ가 강조하는 Topics(범위), Actions(도구), Instructions(지침)는 그 최소 집합을 에이전트 행동으로 고정하는 장치입니다. 질문 유형마다 허용 객체와 필드를 다르게 두면, 보안팀이 검토할 지점이 설정 한곳에 모입니다.
이 점검은 Agentforce 파일럿이 프로덕션에서 멈추는 이유에서 다룬 보안 모델 진단과 같은 시점에 시작하는 것이 자연스럽습니다.
Trust Layer가 켜져 있어도 에이전트 마스킹은 꺼져 있습니다
Salesforce는 Einstein Trust Layer를 계약, 보안 기술, 데이터·프라이버시 통제의 묶음으로 설명합니다. 그 묶음 안에 동적 grounding(그라운딩), 제로 데이터 보존, 프롬프트 점검, 감사 추적이 들어 있습니다. 한국 엔터프라이즈 보안팀이 가장 먼저 묻는 지점도 보통 이 계층입니다.
다만 같은 공식 자료가 다른 사실도 적습니다. Agentforce의 LLM 데이터 마스킹은 현재 꺼져 있습니다. Salesforce 제품 블로그는 이유를 짧게 말합니다. 마스킹이 지연을 늘리고, 계획·액션 흐름을 방해하며, 응답 정확도를 떨어뜨린다는 고객 보고가 있었다는 것입니다. Trailhead는 이 비활성이 에이전트에 해당하고, Einstein Service Replies나 Work Summaries 같은 내장 생성형 기능에는 마스킹을 설정할 수 있다고 구분합니다. Prompt Builder나 Flow에서 돌리는 프롬프트 템플릿과 Agentforce를 같은 통제로 취급하면 안 됩니다.
그래서 Einstein Trust Layer는 도구이지 설계가 아닙니다. 무엇이 민감 데이터인지, 어떤 필드를 실행 맥락에서 뺄지, 어디까지 답에 실을지를 선언하는 일은 설계자의 몫입니다. 주민등록번호나 카드 번호 같은 식별 정보가 기본 패턴으로 잡히던 시절의 가정은, 에이전트 경로에서는 더 이상 기본값이 아닙니다. 신용 등급, 의료 이력, 계약 단가처럼 조직마다 다른 민감 필드는 권한 세트와 grounding 범위에서 직접 제외해야 합니다.
Grounding은 정확도와 노출이 같은 손잡이에 달려 있습니다. 범위를 넓히면 답의 근거는 늘어나고, 민감 데이터가 답에 섞일 여지도 커집니다. 질문 유형별로 객체와 필드를 따로 묶고, 답에 꼭 필요한 데이터만 근거로 삼으십시오.
제로 보존도 오해하기 쉽습니다. FAQ는 서드파티 LLM이 고객 데이터를 보존하거나 학습에 쓰지 않도록 하는 정책을 설명합니다. 그 문장은 데이터가 모델 제공자나 호스팅 제공자를 거치지 않는다는 뜻이 아닙니다. OpenAI로 고객 데이터가 직접 전달되는 구성에서는 OpenAI가 하위 처리자가 됩니다. Anthropic이나 OpenAI 모델이 AWS 또는 Azure에서 호스팅되는 구성에서는 호스팅 제공자가 하위 처리자가 됩니다. 어느 경로인지는 계정과 구현마다 다릅니다. 보안팀이 확인해야 하는 것은 “학습에 안 쓴다”는 문구가 아니라, 어떤 데이터가 어느 처리자를 거치는가입니다.
마지막은 프롬프트 가드레일입니다. 권한 밖 정보를 요청받았을 때 어떻게 거절할지, 어떤 조건에서 사람에게 넘길지를 지침에 명시합니다. 가드레일이 비어 있으면 질문을 바꿔 경계를 우회하려는 시도에 에이전트가 그대로 응합니다. 다만 프롬프트만으로 통제를 세우면 우회 여지가 남습니다. 데이터 접근 자체를 권한 세트로 막은 위에 지침을 더하는 이중 구조가 안전합니다.
PIPA 통제는 처리 경로에서 닫습니다
기술적 통제가 자리를 잡아도, 한국 엔터프라이즈에는 개인정보 보호법이라는 별도 관문이 있습니다. 에이전트가 고객의 개인정보를 다루는 순간 그 처리는 PIPA의 적용 대상이 됩니다. 마스킹이 꺼진 뒤에는 이 관문을 기능 설정이 아니라 처리 경로로 봐야 합니다.
수집 근거와 목적부터 확인합니다. 에이전트가 참조하는 개인정보가 어떤 동의나 법적 근거로 수집됐는지, AI 에이전트가 그 데이터를 처리하는 일이 원래 수집 목적 안에 있는지를 봐야 합니다. 상담 응대용으로 받은 데이터를 에이전트가 마케팅 판단에 쓴다면, 목적 외 이용에 해당해 별도 근거가 필요할 수 있습니다.
위탁 처리는 계약 문장으로 끝나지 않습니다. Salesforce와 그 아래의 모델 제공자, 호스팅 제공자가 데이터를 처리하는 한, 이들은 수탁자 또는 하위 처리자로 검토 대상이 됩니다. FAQ는 Agentforce가 Salesforce DPA의 적용을 받는다고 적습니다. 위탁 계약, 하위 처리자 목록, 데이터가 거치는 경로가 문서로 남아 있어야 품의가 닫힙니다.
국외 이전은 저장 위치만의 문제가 아닙니다. 개인정보보호위원회의 국외이전 제도 안내는 국외 이전을 국외 제3자에 대한 제공, 처리위탁, 보관으로 보고, 조회하는 경우도 포함합니다. 같은 안내는 개인정보 보호법 제28조의8의 요건을 별도 동의, 법률·조약, 계약 이행에 필요한 처리위탁·보관, 인증, 동등성 인정으로 나눕니다. Einstein Trust Layer의 제로 보존은 이 판단의 대체재가 아닙니다. 처리 과정에서 데이터가 국외 인프라를 거친다면 국외 이전에 해당할 수 있습니다. 적용 근거는 법무팀과 개인정보보호책임자가 사실관계를 보고 판단합니다. 기술팀이 제공할 것은 이전되는 항목, 수신자, 시점, 목적입니다. 계약 전 확인 항목은 Salesforce PIPA 데이터 국외 이전에 따로 정리해 두었습니다.
보관기간은 에이전트 화면이 아니라 원 서비스에서 닫습니다. FAQ는 고객 데이터가 Agentforce에 저장되지 않고 아래 서비스에 남는다고 말합니다. 파기 규칙은 Case, Data 360(공식 FAQ는 Data Cloud로 표기), 대화 로그, 감사 기록이 있는 원 서비스를 기준으로 설계해야 합니다. 감사를 위해 로그를 남기는 일과 보관기간을 지키는 일은 함께 설계해야 합니다.
이 네 가지를 프로덕션 직전에 점검하면, 동의를 다시 받거나 위탁 계약을 다시 맺어야 하는 상황이 생깁니다. 그 작업은 몇 주가 아니라 몇 달이 걸립니다. PIPA 검토를 파일럿 설계 단계로 끌어와, 데이터 처리 경로를 보안팀과 먼저 합의하는 편이 결국 빠릅니다.
거버넌스의 무게 중심은 운영 주체에 있습니다. 파일럿을 외부 SI가 구축하더라도, 에이전트의 권한 변경과 가드레일 조정, 로그 검토를 내부 보안팀이 이어받을 수 있어야 합니다. 구축은 외부가 맡더라도 통제 권한은 내부가 쥐고 있어야 책임 소재가 분명해집니다. 이 운영 모델을 누가 붙잡을지는 서비스 개요에서 프로그램 통제 범위와 맞춰 보면 됩니다.
핵심 정리
Agentforce 데이터 보안은 모델 위에 덧붙이는 기능이 아닙니다. 에이전트를 새로운 행위자로 보고, 마스킹이 꺼진 전제에서 처음부터 그리는 설계입니다.
- 답에 필요한 최소 데이터만 허용하는 전용 권한 세트를 만들고, 강한 권한으로 에이전트를 띄우지 않습니다.
- Einstein Trust Layer의 제로 보존과 감사는 남아 있습니다. 에이전트 LLM 마스킹은 현재 꺼져 있으므로, 민감 필드는 권한과 grounding에서 직접 빼야 합니다.
- 제로 보존만으로 국외 이전이나 위탁 검토를 닫았다고 보지 마십시오. 어떤 데이터가 어느 처리자를 거치는지를 계정별로 확인합니다.
- PIPA 점검은 수집 목적, 위탁 처리, 국외 이전, 보관기간입니다. 프로덕션 직전이 아니라 파일럿 설계 단계에서 보안팀과 합의합니다.
- 로그와 파기 규칙은 Agentforce가 아니라 원 서비스에 남습니다. 통제 권한을 내부가 쥐고 있어야 18개월 뒤에도 같은 심사 질문에 답할 수 있습니다.
지금의 권한 설계가 다음 사용 사례의 사고 범위를 결정합니다. 에이전트를 행위자로 보고 최소 권한과 처리 경로를 초기에 정리한 조직은, 새 주제를 더할 때마다 같은 보안 기반을 재사용합니다. 반대로 통제를 나중에 붙이려는 조직은 사용 사례가 늘 때마다 같은 검토를 다시 받습니다. 데모를 통과하는 에이전트가 아니라 보안 심사와 PIPA 검토를 통과하는 에이전트를 목표로 한다면, Agentforce 데이터 보안은 권한 모델과 처리 경로부터 그려야 합니다.
