AI 에이전트 배포 전 레코드 접근 권한 감사하기

AI 에이전트가 조직의 모든 급여 레코드를 읽을 수 있다는 사실을 발견하기에 가장 안전한 순간은, 사용자가 에이전트에게 그것을 물어볼 때가 아니라 배포하기 전이다. Agentforce 에이전트는 자신이 실행되는 사용자의 접근 권한을 상속하기 때문에, 에이전트를 켜는 것은 사실상 그 사용자가 볼 수 있는 모든 것을 대화 형태로, 기계의 속도로 노출하기로 결정하는 일이다. 이 플레이북은 그 접근 권한을 먼저 감사한다.

이 감사가 사람보다 에이전트에게 더 중요한 이유

사람은 자기 접근 권한의 전체 범위와 맞닥뜨리는 일이 드물다. 자신이 일하는 레코드만 열고 나머지는 무시한다. 하지만 에이전트는 다르다. 질문 하나를 던지면 도달 가능한 모든 것을 가져와 결합하고 요약한다. 에이전트는 새로운 접근 권한을 만들지 않는다. 이미 존재하는 접근 권한을, 모두가 잊고 있던 접근 권한까지 포함해 드러낼 뿐이다.

그러므로 이 감사는 AI에 관한 것이 아니다. 오래된 질문 하나에 새로운 절박함을 담아 답하는 일이다. 이 사용자는 실제로 무엇을 볼 수 있는가?

1단계 — 에이전트의 실행 ID를 확정한다

에이전트가 정확히 어떤 사용자(또는 사용자 구성)로 실행되는지 파악하라. 에이전트가 읽을 수 있는 모든 것은 그 ID의 권한과 공유로 정의된다. 광범위한 사람용 프로필을 재사용하고 있다면, 그것 자체가 이미 첫 번째 발견 사항이다. 5단계를 참고하라.

2단계 — 객체 수준 접근 권한을 감사한다

해당 ID에 대해 프로필과 권한 집합에서 비롯된 객체 권한을 검토하라.

• CRUD — 어떤 객체를 읽기 / 생성 / 편집 / 삭제할 수 있는가?
• 필드 수준 보안 — 어떤 민감한 필드가 보이는가?
• View All / Modify All — 객체에 부여된 이러한 권한(또는 “View All Data”)은 공유 모델을 통째로 우회하므로, 가장 우선적으로 찾아내야 할 대상이다.

객체 접근 권한은 관문이다. 에이전트가 어떤 객체를 읽을 업무적 이유가 없다면, 레코드를 걱정하기 전에 여기서 먼저 바로잡아라.

3단계 — 레코드 수준 접근 권한을 감사한다

읽을 수 있는 객체에 대해, 모든 공유 메커니즘에 걸쳐 어떤 레코드를 보는지 파악하라.

• 조직 전체 기본값 — 기준값이 Private인가 Public인가? Public OWD라면 에이전트는 해당 객체의 모든 레코드를 본다.
• 역할 계층 — 해당 ID가 계층 상단에 위치해 그 아래 모든 사람의 권한을 상속하는가?
• 공유 규칙 — 소유권 기반 및 기준 기반 규칙 중 어떤 것이 이 ID를 포함하는가?
• 수동 공유 — 일회성으로 부여된 권한이 있는가?
• 암시적 공유 — 계정에 대한 접근이 하위 레코드까지 끌어오는, 감사에서 잊히기 쉬운 계층이다.

원하는 결과물은 이것이다. 이 에이전트가 실제로 읽을 수 있는 레코드 집합과, 각각의 배후에 있는 메커니즘.

4단계 — 지나치게 광범위하거나 오래된 접근 권한을 색출한다

전체 그림을 손에 쥐었다면, 있어서는 안 될 권한 부여를 찾아라.

• Private이어야 하는데 Public Read로 된 OWD.
• 의도한 것보다 훨씬 많은 레코드에 매칭되는 기준 기반 공유 규칙.
• 지난 프로젝트에서 “View All”이 켜진 채 남아 있는 권한 집합.
• 임시로 부여했어야 할 수동 공유.

이 하나하나가 에이전트가 그대로 노출했을 대상이다. 정리하라.

5단계 — 에이전트에게 최소 권한을 부여한다

광범위한 사람용 프로필을 재사용하지 마라. 에이전트의 작업 범위에 맞춘 전용 최소 권한 ID를 프로비저닝하고, 세분화된 규칙을 위해 그 위에 속성 기반 정책을 더하라. 에이전트는 필요한 최소한의 접근 권한만 가져야 하며, 실수로 상속된 것이 있어서는 안 된다.

6단계 — 변경이 있을 때마다 다시 감사한다

유효 접근 권한은 변동한다. 새 공유 규칙, 역할 이동, 권한 집합 조정 하나로 에이전트의 도달 범위가 조용히 넓어진다. 공유 설정이 바뀐 뒤에는 감사를 다시 실행하고, 그와 무관하게 정기적으로도 실행하라. “출시 시점에 올바르게 범위가 정해졌다”는 것이 “오늘도 올바르게 범위가 정해져 있다”는 뜻은 아니다.

며칠짜리 감사를 하나의 질문으로 바꾸기

2~6단계가 어려운 부분이다. CRUD, 필드 수준 보안, 그리고 여섯 가지 공유 메커니즘에 걸쳐 사용자의 진짜 유효 접근 권한을 재구성하고, 그것을 최신 상태로 유지하는 일. 손으로 하면 며칠이 걸리고 틀리기도 쉽다.

AgentForceAccess는 바로 이를 위해 만들어졌다. 에이전트의 실행 사용자가 실제로 무엇을 볼 수 있는지 평이한 한국어(또는 영어)로 묻기만 하면, 객체 권한, 공유 규칙, 수동 또는 암시적 공유까지 모든 권한 부여를 추적하고 그 메커니즘을 함께 제시한다. 배포 전에도, 모든 변경 후에도 “에이전트의 범위가 맞을 것이다”를 “맞다는 것을 안다”로 바꿔준다.

자주 묻는 질문

애초에 에이전트를 배포하기 전에 접근 권한을 감사해야 하는 이유는?

에이전트는 실행 사용자가 도달할 수 있는 모든 것을 요청 즉시 드러내기 때문이다. 대부분의 조직은 아무도 기억하지 못할 만큼 공유가 열려 있어, 감사를 통해 에이전트가 노출했을 잠재적 접근 권한을 미리 찾아낼 수 있다.

감사는 실제로 무엇을 다뤄야 하나?

두 계층이다. 객체 수준에서는 실행 사용자의 프로필과 권한 집합에서 비롯된 CRUD 권한과 필드 수준 보안을 본다. 레코드 수준에서는 조직 전체 기본값, 역할 계층, 공유 규칙, 수동 공유, 암시적 공유를 통해 어떤 특정 레코드를 볼 수 있는지를 본다.

에이전트가 실제 직원 계정을 사용해도 되나?

아니다. 광범위한 사람용 프로필을 재사용하지 말고, 에이전트의 작업 범위에 맞춘 전용 최소 권한 ID를 프로비저닝하라. 에이전트는 필요한 최소한의 접근 권한만 가져야 하며, 실수로 상속된 것이 있어서는 안 된다.

얼마나 자주 다시 감사해야 하나?

조직 전체 기본값, 공유 규칙, 역할 계층, 프로필, 권한 집합 중 어느 하나라도 변경된 뒤에는 반드시, 그리고 그와 무관하게 정기적으로 감사하라. 유효 접근 권한은 시간이 지나며 변동하고, 에이전트의 도달 범위도 함께 변동한다.