자율형 이메일 에이전트를 위한 가드레일: 정책 심층 분석

새벽 3시에 당신의 자율형 이메일 에이전트가 멍청한 짓을 하는 것을 실제로 막아주는 것은 무엇일까요?

만약 그 답이 "시스템 프롬프트 (system prompt)"라면, 당신은 가드레일 (guardrail)을 가진 것이 아니라 제안 (suggestion)을 가진 것입니다. 프롬프트는 권고 사항일 뿐입니다. 모델은 탈옥 (jailbroken)될 수 있고, 재시도 루프 (retry loop)는 통제 불능 상태가 될 수 있으며, 분류기 (classifier)는 오작동할 수 있습니다. 진정한 가드레일은 애플리케이션 레이어 (application layer) 아래에 존재하며, 에이전트의 코드가 이를 말로써 우회할 수 없는 곳에 있어야 합니다.

그것이 바로 Nylas Agent Accounts (둘 다 베타 버전)의 Policies, Rules, and Lists가 수행하는 역할입니다. 이것들은 관리자 범위의 리소스 (admin-scoped resources)로, 경로에 Grant ID가 포함되지 않으며 플랫폼에 의해 강제됩니다. LLM이 무엇을 결정하든 상관없이 에이전트의 메일함이 무엇을 보내고, 받고, 저장할 수 있는지를 제어합니다.

시스템의 구조

세 가지 리소스가 체인을 형성하고, 네 번째 리소스가 이를 적용합니다:

• Lists (리스트): 값들을 보유합니다 — 도메인, TLD, 또는 이메일 주소의 타입화된 컬렉션 (typed collections)입니다.
• Rules (규칙): in_list 연산자를 통한 리스트 멤버십을 포함하여 조건에 따라 메일(수신 또는 발신)을 매칭하고, block (차단), mark_as_spam (스팸으로 표시), assign_to_folder (폴더로 할당), archive (보관), trash (휴지통) 등의 액션 (actions)을 실행합니다.
• Policies (정책): 제한 사항과 스팸 설정을 묶습니다.
• Workspaces (워크스페이스): 하나의 policy_id와 rule_ids 배열을 포함하며, 워크스페이스 내의 모든 Agent Account는 두 가지를 모두 상속받습니다.

사람들이 놓치는 마지막 지점은 이것입니다: 개별 Grant에 정책을 직접 연결하지 않습니다. 워크스페이스가 정책과 규칙을 보유합니다. 모든 애플리케이션에는 다른 곳에 배치하지 않은 모든 계정을 보유하는 기본 워크스페이스가 있으므로, 거기에 정책을 연결하면 할당되지 않은 모든 에이전트를 한 번에 커버할 수 있습니다. 영업 에이전트와 지원 에이전트에게 서로 다른 규칙을 적용하고 싶으신가요? 별도의 워크스페이스와 별도의 정책을 사용하면 됩니다.

모든 것은 선택 사항입니다. 워크스페이스 정책이 없으면, 계정은 결제 플랜의 최대치로 작동하며 모든 수신 메시지를 받은 편지함으로 전달합니다. 더 엄격한 동작을 원할 때 이러한 리소스들을 사용하게 됩니다.

정책이 실제로 제어하는 것

두 가지 카테고리가 있습니다: 제한 사항 (limits) (첨부 파일 크기 및 개수, 허용된 MIME 타입, 총 메시지 크기, 계정당 저장 용량, 일일 발송 할당량, 편지함/스팸 보관 기간) 및 스팸 탐지 (spam detection) (DNSBL 확인, 헤더 이상 탐지, 그리고 0.1에서 5.0 사이로 조절 가능한 spam_sensitivity 다이얼 — 값이 높을수록 더 공격적으로 작동함).

curl --request POST \
  --url "https://api.us.nylas.com/v3/policies" \
  --header "Authorization: Bearer <NYLAS_API_KEY>" \
...

제한 사항을 생략하면 해당 요금제의 최대치로 기본 설정됩니다. 요금제 최대치보다 높은 값을 요청하면 API는 에러를 반환합니다. 즉, 하향 제약만 가능하며, 이는 가드레일 (guardrail)로서 정확히 의도된 형태입니다.

규칙은 격리된 상태로 양방향에서 실행됩니다

각 규칙에는 trigger (트리거)가 있습니다: inbound (수신) 규칙은 수신된 메일에 대해 실행되며, outbound (발신) 규칙은 메시지가 이메일 제공업체에 도달하기 전 발송 단계에서 실행됩니다. 이 두 가지는 절대 교차하지 않습니다. 즉, 수신 규칙은 발송 중에 평가되지 않으며, 저장된 발송 사본은 수신 규칙에 의해 다시 검사되지 않습니다. 조건 매칭의 경우, 수신 규칙은 from.address, from.domain, from.tld를 기준으로 하며, 발신 규칙은 여기에 recipient.* 필드(BCC 및 SMTP envelope 수신자를 포함한 모든 수신자와 매칭되어 데이터 유출 방지 (DLP)에 유용함)와 reply (답장)와 새로운 compose (작성)를 구분하는 outbound.type을 추가로 사용합니다.

규칙은 0~1000 척도(기본값 10)에서 낮은 숫자부터 높은 순서인 priority (우선순위) 순으로 실행됩니다. block (차단) 액션은 최종 단계입니다. 수신 시에는 SMTP 레벨에서 메시지를 거부하여 편지함에 저장되지 않도록 하며, 발신 시에는 전송 전 HTTP 403 에러와 함께 발송을 거부하여 발송 사본이 생성되지 않도록 합니다.

용량 제한은 넉넉하지만 고정되어 있습니다: 규칙당 조건 50개, 규칙당 액션 20개, in_list 조건당 참조 리스트 10개, 조건 값당 500자입니다.

내재화할 가치가 있는 하나의 비대칭성(asymmetry)이 있습니다: 비차단형 아웃바운드 액션(archive, mark_as_read, assign_to_folder 및 유사 기능들)은 전송이 성공한 후 저장된 발신 사본(sent copy)만 수정합니다. 이들은 수신자가 받는 내용을 절대 변경하지 않습니다. 만약 아웃바운드 측에서 전달(delivery)에 영향을 주고 싶다면, block이 이를 수행하는 유일한 액션입니다.

체인을 엔드투엔드(end-to-end)로 연결하기

작동하는 차단 목록(blocklist)을 위한 전체 시퀀스는 다음과 같습니다. 리소스 체인은 산문보다 호출(calls)에서 더 쉽게 파악할 수 있기 때문입니다. 타입이 지정된 리스트를 생성하고 이를 로드합니다 (요청당 최대 1,000개 항목 — 값은 소문자로 변환되고, 공백이 제거되며, 리스트의 타입에 따라 검증되며, 중복 항목은 조용히 무시됩니다):

curl --request POST \
  --url "https://api.us.nylas.com/v3/lists/<LIST_ID>/items" \
  --header "Authorization: Bearer <NYLAS_API_KEY>" \
...

그런 다음 from.domain / in_list가 해당 리스트 ID를 가리키고 block 액션을 포함하는 인바운드 규칙(inbound rule)을 생성한 뒤, 해당 규칙의 ID를 워크스페이스의 rule_ids에 추가합니다. 그 순간부터 워크스페이스 내의 모든 에이전트 계정(Agent Account)은 SMTP 단계에서 해당 도메인으로부터 오는 메일을 거부합니다. 다음 주에 차단 목록이 늘어나면 리스트만 업데이트하면 됩니다. 규칙과 워크스페이스는 변경되지 않으므로, 리스트 접근 권한이 있는 비엔지니어도 배포(deploy) 없이 차단 프로그램을 운영할 수 있습니다.

배치(Placement) 또한 기계적으로 이루어집니다. POST /v3/connect/custom에서 권한(grant)을 생성할 때 workspace_id를 설정하거나, PATCH /v3/grants/{grant_id}를 통해 기존 계정을 이동시킬 수 있습니다. auto_group: true가 설정된 워크스페이스는 자신의 domain과 일치하는 이메일 도메인을 가진 새로운 에이전트 계정을 자동으로 수용합니다. 이는 각 고객의 도메인이 해당 고객의 할당량(quota)과 스팸 허용치(spam tolerance)를 보유한 워크스페이스로 매핑되는 '고객당 하나의 워크스페이스' 패턴에 유용합니다. 기본 워크스페이스의 한 가지 주의사항은 policy_id와 rule_ids가 해당 위치에서 업데이트할 수 있는 유일한 필드라는 점입니다. 나머지는 Nylas가 관리합니다.

신뢰를 얻는 페일 클로즈드(fail-closed) 디테일

규칙 엔진(rule engine) 자체가 문제를 일으킬 때, 예를 들어 block 규칙을 평가하는 도중 리스트 조회(list lookup)가 실패하면 어떻게 될까요? 엔진은 페일 클로즈드(fail-closed) 방식으로 작동합니다. 즉, 메시지를 통과시키는 대신 차단합니다. 이러한 인프라 차단은 재시도 가능한 오류(retryable errors)로 나타납니다(API 전송 시 403 대신 503을 받거나, 인바운드 SMTP가 451 tempfail로 응답하여 송신 서버가 반송(bounce)하는 대신 재시도하게 함). 또한 감사 기록(audit record)에 blocked_by_evaluation_error: true가 포함되어, 실제 규칙 매칭인지 시스템 장애인지를 구분할 수 있습니다.

페일 오픈(fail-open) 방식으로 작동하는 보안 제어는 장식에 불과합니다. 이 시스템은 그렇지 않습니다.

모든 평가는 흔적을 남깁니다

엔진이 메시지(인바운드, SMTP envelope, 또는 아웃바운드 전송)를 평가할 때마다 감사 항목(audit entry)이 기록됩니다. GET /v3/grants/{grant_id}/rule-evaluations를 통해 이를 최신순으로 나열할 수 있으며, 평가 단계, 고려된 정규화된 송신자/수신자 데이터, 매칭된 규칙, 그리고 적용된 작업(action)을 확인할 수 있습니다. 에이전트가 "왜 그 이메일을 받지 못했지?"라고 묻거나 고객이 "왜 내 메일 전송이 거부되었지?"라고 물을 때, 이 엔드포인트가 해답이 됩니다.

문서에서 반복할 가치가 있는 튜닝 조언

spam_sensitivity를 1.0으로 시작하여 관찰된 동작에 따라 조정하십시오. 첫 번째 block 규칙이 우선 적용되므로, 구체적인 매칭(is, 작은 리스트에 대한 in_list)이 광범위한 contains 매칭보다 먼저 실행되도록 규칙 순서를 정하십시오. 집합이 커질 가능성이 있다면 인라인 규칙 값(inline rule values)보다는 리스트를 사용하는 것이 좋습니다. 하나의 리스트가 여러 규칙에 공급될 수 있으며, 규칙 정의를 수정하지 않고도 업데이트할 수 있기 때문입니다. 그리고 두 가지 보관(retention) 값을 함께 설정하십시오. 스팸 보관 기간은 받은 편지함(inbox) 보관 기간보다 짧아야 합니다.

기본 워크스페이스(default workspace)에 연결된 하나의 정책을 설정하는 데는 약 2분이 소요되며, 이후 프로비저닝(provision)하는 모든 에이전트에 적용됩니다. 전체 가이드에서 전체 스키마(schemas)를 확인할 수 있습니다. 에이전트를 작성하기 전에 정책을 먼저 생성하십시오. 어떤 제한 사항이 지난 자동화 사고를 막아줄 수 있었을까요?