에이전트 신원(Agent Identity)

에이전트 신원(agent identity)을 통해 Snowflake는 세션에서 AI 에이전트가 활성화되어 있음을 인식하여, 일반적인 인간 또는 서비스 접근과 구분해 에이전트 주도의 접근을 거버넌스할 수 있어요.

출처: Snowflake 문서

본문

엔터프라이즈 AI 에이전트는 Snowflake 네이티브(예: Cortex Agents)일 수도 있고 서드파티(예: OAuth 또는 자체 서비스 자격 증명으로 연결하는 에이전트)일 수도 있어요. 많은 워크플로에서 세션은 에이전트가 열지만, 권한과 책임은 여전히 사람에게 있어요. 에이전트 신원은 그 간극을 메워, 누가 접근을 승인했는지, 어떤 에이전트가 수행했는지, 그 접근이 작업에 적절했는지 답할 수 있게 해요.

개요

Snowflake의 에이전트 신원 기능은 네 가지 거버넌스 기능을 지원해요.

기능	할 수 있는 일
식별(Identify)	에이전트 세션을 감지하고 일반적인 인간 세션과 구분
감사(Audit)	쿼리와 객체 접근을 에이전트 유형에, 그리고 에이전트가 사용자 대신 행동할 때는 사용자에게 귀속
거버넌스(Govern)	사용자의 역할이 더 허용하더라도 에이전트가 볼 수 있는 민감 데이터 제한
통제(Control)	에이전트가 세션에서 할 수 있는 일을 사용자 역할이 이미 허용하는 권한의 부분집합으로 제한

신원(identity)을 어떻게 구성하는지에 영향을 주는 두 가지 에이전시(agency) 모드가 있어요.

**위임 에이전트(Delegated agents)**는 사용자를 대신해 행동해요. 세션은 사용자에게 속하며, Snowflake는 이를 에이전트 활성(agent-active)으로 표시해 정책과 감사 뷰가 트래픽을 에이전트성(agentic)으로 처리할 수 있게 해요.
**자율 에이전트(Autonomous agents)**는 자신의 신원과 인가로 행동해요. SERVICE_AGENT 사용자를 만들고 워크로드 신원 연합 또는 다른 지원되는 비대화형 방식으로 인증해요. 그 사용자의 모든 세션은 에이전트 활성 상태예요.

에이전트 식별

Snowflake는 진입점과 인증 방법에 따라 세션을 에이전트성으로 표시해요. 세션이 에이전트 활성이면 IS_AGENT_ACTIVATED 컨텍스트 함수가 TRUE를 반환해요.

다음 표는 지원되는 진입점을 나열해요.

진입점	조건
Snowflake 네이티브 에이전트	사용자가 Cortex Agent나 Cortex lite 에이전트 같은 Snowflake 에이전트를 통해 행동(CoCo 클라이언트, Snowflake CoWork 포함)
Snowflake 관리 MCP 서버	Snowflake 관리 MCP 서버를 통한 세션은 자동으로 에이전트성으로 표시
Snowflake OAuth	커스텀 OAuth 보안 통합이 IS_AGENTIC = TRUE로 구성됨
외부 OAuth	External OAuth 보안 통합이 IS_AGENTIC = TRUE로 구성됨
SERVICE_AGENT 사용자 유형	SERVICE_AGENT 유형으로 생성된 사용자가 연 세션

식별 경로 선택

다음 표를 사용해 에이전트를 식별하는 방법을 선택해요.

에이전트가…	구성할 것…
Snowflake AI 제품 내부에서 실행됨(Cortex Agents, CoCo, CoWork, 관리 MCP)	추가로 할 것이 없음. Snowflake가 세션을 자동으로 에이전트 활성으로 표시해요.
자체 Snowflake 신원과 권한이 필요함(자율)	SERVICE_AGENT 사용자. 일반적으로 워크로드 신원 연합(SPIFFE, SPIRE 포함), 키 쌍 인증, 또는 프로그래매틱 액세스 토큰과 함께 사용
커스텀 Snowflake OAuth 클라이언트를 통해 최종 사용자를 대신해 행동(위임)	커스텀 OAuth 통합에서 IS_AGENTIC = TRUE. Snowflake는 프로그래매틱 액세스 토큰 단독 같은 다른 위임 방식을 사용하는 세션을, 지원되는 에이전트 신원 경로도 사용하지 않으면 에이전트성으로 취급하지 않아요.
External OAuth 클라이언트를 통해 최종 사용자를 대신해 행동(위임)	External OAuth 통합에서 IS_AGENTIC = TRUE. Snowflake는 프로그래매틱 액세스 토큰 단독 같은 다른 위임 방식을 사용하는 세션을, 지원되는 에이전트 신원 경로도 사용하지 않으면 에이전트성으로 취급하지 않아요.

에이전트 활동 감사

Snowflake가 에이전트 세션을 식별하면 그 컨텍스트를 기존 감사 뷰에 담아 에이전트 활동을 검토할 수 있게 해요.

쿼리 이력: `agent_type`

QUERY_HISTORY의 agent_type 열은 쿼리를 직접 호출한 에이전트를 식별해요.

값	의미
CORTEX_AGENT	영속적이고 이름이 있는 Cortex Agent
CORTEX_LITE_AGENT	Cortex lite 에이전트(REST API 또는 CoCo 클라이언트)
EXTERNAL_AGENT	SERVICE_AGENT 또는 IS_AGENTIC = TRUE인 OAuth 통합을 사용하는 외부 에이전트

어떤 에이전트도 쿼리를 호출하지 않았으면 이 열은 NULL이에요. 자세한 내용은 QUERY_HISTORY 뷰(Account Usage)와 QUERY_HISTORY 뷰(Organization Usage)를 참고해요.

접근 이력: `agents_info`

ACCESS_HISTORY의 agents_info 열은 객체 접근에 대한 에이전트 세부정보를 가장 가까운 에이전트부터 최상위 에이전트까지 순서대로 제공해요. 예를 들어 Cortex Agent가 쿼리를 실행하는 도구를 호출하면 배열이 그 에이전트를 먼저 나열하고, 그다음 호출 체인의 상위 에이전트를 나열할 수 있어요. 각 요소는 에이전트에 따라 agentType, agentId, agentName을 포함할 수 있어요. 에이전트가 관여하지 않았으면 이 열은 NULL이에요.

자세한 내용은 ACCESS_HISTORY 뷰(Account Usage)를 참고해요.

함께, 이 열들은 규정 준수 팀이 자주 필요로 하는 인과 체인을 재구성하는 데 도움을 줘요. 사용자가 에이전트를 호출했고, 특정 쿼리가 이어졌으며, 특정 객체에 접근됐어요.

민감 데이터 접근 거버넌스

에이전트 세션을 식별하면 에이전트가 활성일 때 다르게 동작하는 데이터 보호 정책을 적용할 수 있어요. 사용자의 역할이 달리 허용하더라도 규제 또는 고위험 데이터가 에이전트에 반환되지 않도록 정책 본문에서 IS_AGENT_ACTIVATED를 호출해요.

일반적인 패턴은 에이전트가 활성일 때마다 민감 열을 숨기는 마스킹 정책이에요.

CREATE OR REPLACE MASKING POLICY email_agent_mask AS (val STRING) RETURNS STRING ->
  CASE
    WHEN SYS_CONTEXT('SNOWFLAKE$CURRENT', 'IS_AGENT_ACTIVATED')::BOOLEAN = TRUE THEN '********'
    WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
    ELSE '********'
  END;

행 접근, 프로젝션, 집계, 조인 정책에서도 같은 확인을 사용할 수 있어요. 지침과 예시는 다음을 참고해요.

사용자 세션에서 에이전트 접근 통제

에이전트 세션을 식별하면 사용자의 역할이 이미 허용하는 권한의 부분집합으로 에이전트가 할 수 있는 것을 제한할 수도 있어요. Restricted Session Scope(RSS)은 권한 상한(privilege ceiling)이에요. 사용자 권한과 교차하며, 사용자가 이미 보유하지 않은 권한은 절대 부여하지 않아요.

세션 정책에 AGENT_RESTRICTED_SESSION_SCOPE을 설정하고, 그 정책을 계정 또는 사용자에게 연결해요. 상한은 에이전트가 활성일 때만 적용돼요(IS_AGENT_ACTIVATED가 TRUE를 반환).

RSS의 일반적인 사용 방식은 다음과 같아요.

AI 관련 객체(예: SNOWFLAKE$DATA_READ_WITH_AI)는 여전히 사용할 수 있는 에이전트에 읽기 전용 상한 적용. 계정 차원 에이전트 읽기 전용을 참고해요.
프로덕션은 읽기 전용으로 유지하면서 샌드박스와 각 사용자의 개인 데이터베이스에서만 쓰기 허용. 프로덕션 읽기 전용, 샌드박스와 사용자 개인 DB에서 쓰기 허용을 참고해요.
에이전트가 활성일 때 ACCOUNTADMIN, SYSADMIN, SECURITYADMIN 같은 승격된 역할 차단. 에이전트 활성 시 권한 있는 역할 차단을 참고해요.
그랜트·객체 관리 거부는 유지하면서 데이터 작업(읽기, 샌드박스 쓰기, 프로그램 사용) 허용. 데이터 작업 허용, 그랜트·객체 관리 차단을 참고해요.
AI 사용 승인된 데이터베이스로 에이전트 제한. 승인된 데이터베이스로 접근 제한을 참고해요.

RSS와 에이전트 인지 데이터 보호 정책은 상호 보완적이에요. RSS는 에이전트가 도달할 수 있는 데이터베이스와 작업을 통제하고, 마스킹 및 관련 정책은 그 범위 내에서 보이는 열 값을 통제해요.

YAML 구조, 사전 정의된 범위, 전체 예시는 에이전트용 Restricted Session Scope를 참고해요.

더 알아보기 (Learn more)

Restricted Session Scope — 에이전트용 권한 상한
에이전트성 상호작용을 위한 데이터 보호 정책 — 에이전트 활성 정책
사용자 관리 — 사용자 유형

에이전트 신원(Agent Identity)