아침에 메일 트리아지(Triage)와 캘린더 정리를 Claude Code에 맡기고, 자신은 코드로 돌아간다——그런 「AI 비서」 기사가 2026년에 들어서 Zenn, note, Qiita에서 급증했다. 하지만 대부분은 「작동하는 것」을 만드는 것으로 끝난다. 조직 전개를 맡은 입장에서 다시 읽어보면, Routines의 보안 모델이 기존의 permission_mode를 배신하는 점이나, 간접 프롬프트 인젝션(Indirect Prompt Injection)이 Calendar 초대 제목을 통해 실질적인 피해를 입힌 최신 사례가 거의 빠져 있다. 본 기사는 시니어/테크 리드(Tech Lead)를 대상으로, 5개 계층으로 나눈 책임 분리와 7가지 「하지 않을 판단」으로 경계를 긋는 설계 판단을 정리한다.

「AI 비서」 기사에서 지금 무엇이 빠져 있는가

Zenn 상의 「Claude Code × AI 비서」 기사는 2026년 3월부터 5월 사이에 두 자릿수로 늘어났다. 핸즈온(Hands-on) 기사로서 읽기에는 유용하다. 하지만 조직에서 동일한 메커니즘을 10명 이상에게 배포하게 되는 순간, 대부분의 기사는 판단 재료를 제공하지 않는다. 무엇이 부족한지 3가지로 압축한다.

1.1 Routines가 바꾼 전제 — permission_mode가 작동하지 않는 자율 실행

2026-04-14에 Research Preview로서 공개된 Claude Code Routines는 cron / API / GitHub 이벤트를 기점으로 클라우드 측에서 완전 자율 실행되는 기능이다[1:1]. 최소 실행 간격은 1시간(매분 지정은 reject), 일일 캡(Daily Cap)은 Pro=5 / Max=15 / Team・Enterprise=25로 제한된다. 여기까지는 Anthropic 공식 블로그에서도 언급되고 있다.

문제는 Routines의 공식 문서가 명시하고 있는 한 문장이다.

Routines run autonomously as full Claude Code cloud sessions: there is no permission-mode picker and no approval prompts during a run.

[1:2]

즉, 로컬의 Claude Code 세션에서 permission_mode = "default"로 설정하고 canUseTool로 매번 확인하던 제어가, Routines에 배치하는 순간 작동하지 않게 된다. 무엇을 할 수 있는지를 결정하는 것은 런타임(Runtime)의 mode가 아니라, routine 생성 시 접속한 Connector의 리스트와 cloud environment의 network ACL 두 가지뿐이다.

이 차이를 고려하지 않고 「로컬에서 작동한 비서를 Routines로 교체한다」를 실행하면, mailto: 계열 도구가 승인 없이 실행되는 경로가 그대로 남게 된다. Routines는 편리하지만, 기존의 permission_mode 설계를 배신하는 전제 변경으로 다룰 필요가 있다.

1.2 기존 기사 6건의 공통 결락 — draft 설계가 Routines화되면서 붕괴됨

내가 읽은 Zenn / Qiita / GitHub의 주요 기사 6건(nogataka/ai-secretary[2], hanowa의 ai-company, takatophy의 Zenn Book, MindStudio[3], c0dezli, kjenney)은 거의 전건이 「draft 설계」, 「인간 승인 게이트(Human Approval Gate)」를 구두로 언급하고 있다. 여기까지는 옳다.

붕괴되는 것은 그다음이다. Routines에 배치했을 때 이 설계가 계속 성립할 수 있는지를 논한 기사가 단 한 건도 없다. MindStudio의 경우 MCP조차 사용하지 않고 Python helper로 Google Workspace API를 직접 호출하는 구성으로 되어 있으며[3:1], 「draft 설계를 OAuth scope와 MCP로 강제한다」는 가장 견고한 경로를 취하고 있지 않다.

본 기사의 관점은 이 부분을 정면으로 다루는 데 있다. 「draft로만 쓸 수 있다 / 전송은 인간이 한다」를 구두가 아니라 아키텍처 계층(OAuth scope의 gmail.compose 한정, Routines의 Connector 리스트에서 gmail.send를 제외, PreToolUse Hook으로 mailto: 경로를 deny)으로 고정하는 설계를 5개 계층으로 정리한다.

1.3 IPI는 「학술적 소재」가 아니다 — Calendar 초대에서 실질적 피해를 입힌 3가지 사례

간접 프롬프트 인젝션 (Indirect Prompt Injection, 이하 IPI)에 대해, "논문 소재로는 알고 있지만 현장에서 맞닥뜨린 적은 없다"라는 인식 그대로 비서를 구축하면 사고가 발생한다. 최근 1년 사이 실질적인 피해로 이어진 사례가 3가지 있다.

arXiv 2508.12175 「Invitation Is All You Need!」 (Nassi, B. / Cohen, S. / Yair, O. 저, 2025-08-16) [4] — Google Gemini를 대상으로 14가지 공격 시나리오 × 5가지 위협 클래스 (Short-term Context Poisoning / Permanent Memory Poisoning / Tool Misuse / Automatic Agent Invocation / Automatic App Invocation)를 실증. TARA 평가에서 73%가 High-Critical 리스크로 판정되었으며, Calendar 초대 제목을 경유하여 스마트 홈 제어 권한까지 도달했다.

EchoLeak (CVE-2025-32711, CVSS 9.3〔Microsoft 평가〕／7.5〔NIST 평가〕) [5] — Microsoft 365 Copilot에서 발견된 제로 클릭 RAG 프롬프트 인젝션. 일반 메일처럼 보이는 악의적인 프롬프트가 XPIA classifier를 우회하여 Outlook / SharePoint / OneDrive / Teams의 데이터를 유출시켰다.

postmark-mcp BCC 유출 사고 (2025-10) [2:1] — 커뮤니티 제작 MCP 서버가 BCC에 공격자 도메인을 숨기는 동작을 수행했으며, 사용자는 전송 로그를 확인하기 전까지 이를 인지하지 못했다.

세 번째 사례인 postmark-mcp는 비서형 MCP의 예로서 특히 심각하다. 사용자가 신뢰한 MCP 서버 자체가 탈취 경로가 되기 때문에, OAuth scope만으로는 방어할 수 없다. Anthropic 스스로도 2026-02 시스템 카드(System Card)에서 "직접 프롬프트 인젝션 메트릭스를 폐지하고, indirect(간접)야말로 enterprise(엔터프라이즈) 위협이라고 재정의한다"라고 공식적으로 방침을 전환했다 [6].

IPI를 '발생할지도 모르는 리스크'가 아니라 '특정 공격면에서 반드시 상정해야 하는 것'으로 설계에 포함시켜야 한다.

스코프 선언 — 이 글에서 다루지 않는 것

설계 판단에 관한 논의는 대상 범위를 좁히지 않으면 누구나 동의할 법한 일반론으로 끝나버린다. 본 기사는 다음 사항을 대상 외로 규정한다.

2.1 예상 독자

시니어 엔지니어, 테크 리드(Tech Lead), EM, SRE. 개인적으로 구동하는 입장이 아니라, 조직 전개를 판단하는 입장에 있는 사람을 상정하고 있다. 구체적으로는 다음 3가지 지점에서 고민하는 독자를 주 대상으로 한다.

• "로컬에서 작동하던 비서를 Routines로 옮기고 싶은데, 보안 팀에 무엇을 설명해야 통과될지 모르겠다"
• "타사 사례로 'AI 비서를 도입했다'는 소식은 듣지만, 자사의 인증 경계 및 데이터 반출 정책 내에서 성립 가능한 형태가 보이지 않는다"
• "도입 후 6개월 뒤에 철수 판단이 필요해질 경우, 무엇이 고통스럽고 무엇이 고통스럽지 않을지를 미리 알고 싶다"

2.2 검증 버전

본 기사의 판단은 다음 구성으로 검증되었다. 사양 변경이 발생할 가능성이 높은 영역이므로, 독자의 환경 버전과 대조하며 읽어주길 바란다.

• Claude Code v2.1.114 계열
• Routines: 베타 헤더 experimental-cc-routine-2026-04-01 (Research Preview) [1:3]
• Managed Agents: 베타 헤더 managed-agents-2026-04-01 (beta) [7]
• Claude Agent SDK: Python 0.1.x / TypeScript 0.2.111 이후 (Opus 4.7 이용에 필요 [8])

5층 아키텍처 — 책임 분리를 통해 「무엇이 어디서 일어나는가」를 고정한다

'AI 비서'를 블랙박스로 다루면, 문제가 발생했을 때 어디를 수정해야 할지 알 수 없게 된다. 입력·판단·행동·기억·알림의 5개 계층으로 책임을 나누면, 각 계층에 대해 '무엇을 넣을 것인가 / 무엇을 넣지 않을 것인가'를 독립적으로 결정할 수 있다.

3.1 입력층 — 누구의 무엇을 들을 것인가

핵심은 "scope를 제한한 도구 상자"를 OAuth 계층에서 먼저 만드는 것이다. Hooks나 canUseTool을 통해 후단에서 차단하는 것은 보험일 뿐, 제1 방어선이 아니다. Slack MCP의 운영 가이드라인 또한 "전용 bot user에게 필요한 최소한의 scope만 부여한다"를 강력히 권장하고 있다.

3.2 판단층 (Decision Layer) — Agent SDK + Routines + Hooks의 처리 순서

판단층은 Claude Agent SDK의 권한 제어를 중심으로 구성한다. 처리 순서는 정해져 있으며, 이를 오해하면 Hooks 설계가 성립되지 않는다[8:1].

PreToolUse Hook → Deny Rules → Permission Mode → Allow Rules → canUseTool Callback → PostToolUse Hook

조직 배포의 표준 형태는 permission_mode = "dontAsk" + 엄격한 allowedTools의 조합이다. bypassPermissions는 allowed_tools로 제한할 수 없기 때문에(unlisted 항목도 승인됨) 비서 계열에서는 사용하지 않는다.

dontAsk를 통해 미승인 항목을 명시적으로 denial(거부)로 만들고, 허가 리스트를 Allow Rules로 고정하는 방식이 "제한된 도구 상자에 가두는" 표현이 된다. 단, Routines에 올리는 순간 이 permission_mode 자체가 무효화된다(H2 1.1에서 언급한 바와 같다). Routines는 이 5계층 모델에서 "판단층과 행동층을 클라우드 측에서 동시에 구동하는" 프로세스로 취급하는 것이 올바른 이해다.

import { query, type HookCallback } from "@anthropic-ai/claude-agent-sdk";
const denySendingTools: HookCallback = async () => ({ 
  hookSpecificOutput: {
    ...

TypeScript SDK는 query() 함수를 반환값이 AsyncIterable인 스트리밍 형식으로 제공한다(ClaudeAgent 클래스나 HookMatcher 심볼은 존재하지 않음, 2026-05 시점 기준)[8:2]. 중요한 점은 전송·확정 계열의 tool 이름을 allowedTools에서 제외하면서, Hook으로 이중 차단함으로써 설정 실수나 MCP 버전 업데이트로 인해 tool 이름이 변경되더라도 누락을 방지할 수 있는 구조를 만들어 두는 것이다. Python SDK에서는 동일한 제어를 ClaudeSDKClient + hooks={\"PreToolUse\": [...]} 키워드 인수로 수행한다.

3.3 행동층 (Action Layer) — 실제 액션 경계

행동층에는 "초안 생성", "제안 출력", "회의록 작성"을 넣고, "메일 전송", "캘린더 확정", "금전 조작", "외부 채널 post"는 넣지 않는다. 경계를 긋는 방법은 H2 4에서 7가지 "하지 않을 판단"으로서 개별적으로 상세히 다룬다.

3.4 기억층 (Memory Layer) — PARA × MEMORY.md × CLAUDE.md

Claude Code의 메모리는 2개 계층으로 나뉜다[9].

• MEMORY.md: 자동 메모리. 세션 시작 시 상위 200행 / 25KB가 자동으로 로드되며, 초과분은 온디맨드(on-demand)로 처리됨.
• CLAUDE.md: 프로젝트 지시 사항. 수동 편집하며 항상 로드됨.

「AI 비서」는 중장기 기억을 축적하는 성질상, MEMORY.md의 200행 제한에 반드시 걸리게 된다. 여기서 사용할 수 있는 것이 Tiago Forte의 PARA 메서드(Projects / Areas / Resources / Archives) [10]이다.

주의할 점이 하나 있다. PARA는 Anthropic 공식이 채택한 메서드가 아니다. Forte가 2017년 Forte Labs 블로그에서 처음 공개하고, 2022년 저서 『Building a Second Brain』에서 체계화한 개인 방법론이다. 기존의 AI 비서 기사 중 일부는 이러한 출처를 언급하지 않고 PARA를 당연한 것처럼 다루고 있는데, 이는 독자적인 브랜드 용어를 날조하는 것에 가깝다. 본 기사에서는 「PARA를 Claude Code의 MEMORY.md 200행 제한을 회피하기 위한 파일 분할 원칙으로 원용한다」는 관계를 명시해 둔다.

구현 방식으로는 projects/, areas/, resources/, archive/의 4개 최상위 폴더로 나누고, MEMORY.md 본체는 200행으로 압축하며, 각 PARA 폴더 하위 항목은 온디맨드(on-demand) 로딩으로 처리한다. 이렇게 하면 컨텍스트 윈도우(Context Window)가 팽창하지 않는다.

단, 쓰기 경로는 PARA 폴더 쪽으로만 집중시켜야 한다. MEMORY.md 본체와 PARA 폴더 양쪽에 동일한 정보를 쓰는 이중 쓰기(double-write) 구조로 만들면, 별도의 세션에서 PARA 쪽만 업데이트되었을 때 MEMORY.md의 포인터가 따라가지 못해 '참조 끊김' 상태가 된다. 실운용에서는 MEMORY.md를 PARA를 향한 목차(read-only 포인터)로 취급하고, 본문은 PARA 쪽에서만 완결되도록 한다. MEMORY.md 자체의 업데이트는 주 1회 배치(batch)로 PARA로부터 재생성하는 정도로 제한하는 것이 정합성을 유지하기 쉽다.

3.5 알림층 — 인간에게 무엇을 돌려줄 것인가

알림층은 「비서가 출력하는 성과물의 목적지」를 다룬다. Slack DM, Discord, 이메일 초안 반환의 3가지 경로가 현실적이다. 중요한 것은 알림층의 출력 포맷을 「인간이 초 단위로 거절할 수 있는 형태」로 만드는 것이다. 긴 요약문으로 채우는 것이 아니라, 「3건의 중요 메일에 답장 초안을 작성함 / 11건은 아카이브 제안 / 1건은 판단 보류」와 같이 건수 + 액션 선택지를 반환한다.

이는 심리적 계약의 단위이기도 하다. 비서가 성과물을 「던지는(throw)」 것인지 「제안하는(propose)」 것인지에 따라 인간 측의 리뷰 강도가 달라진다. 던지는 방식으로 장기 운용하면 인간은 점차 리뷰를 하지 않게 되며, IPI(Indirect Prompt Injection)에 의한 오작동이 알림층을 그대로 통과하게 된다. 알림층은 「거절당하는 것을 전제로 반환한다」는 설계가 필요하다.

7가지 「하지 않을 판단」 — 경계선의 설계

제목의 「7가지 경계」를 가시화한다. 각 판단은 「하지 않음 / 하지 않는 이유 / 실행했을 때의 실해 사례 또는 근거」의 3가지 세트로 제시한다.

4.1 이메일 「전송」의 자동화 (초안 단계에서 멈춤)

하지 않음: 자동 전송. gmail.send 스코프(scope)를 비서 계열 OAuth에 포함하지 않는다.

이유: postmark-mcp BCC 유출 사고(2025-10) [2:2]에서는 비서를 통해 전송된 메일에 제3자 도메인의 BCC가 혼입되는 동작이 있었다. **사용자가 신뢰한 MCP 서버 자체가 공격 표면(attack surface)**이 되기 때문에, OAuth에서 gmail.send 권한을 부여하지 않는 설계로만 근본적인 대처가 가능하다.

분기 조건: 자동 전송을 도입하는 것은 수신처가 고정되어 있고 + 본문이 템플릿이며 + 감사 로그(audit log)가 별도 계통으로 기록되는 경우에만 한정한다 (예: 자동 보고서의 사내 고정 수신처). 「비서」 스코프에서는 분리하여 별도의 OAuth 클라이언트에서 동작시킨다.

4.2 캘린더 「확정」의 자동화 (제안 단계에서 멈춤)

하지 않음: events.create를 sendUpdates=all로 호출하는 것. sendUpdates=none이 고정된 래퍼(wrapper)를 통해서만 허용한다.

이유: arXiv 2508.12175는 Calendar 초대 제목을 통한 IPI를 실증하고 있다 [4:1]. 제목 문자열에 공격 프롬프트가 심어진 초대를 비서가 처리하면, 확정 계열의 도구가 그대로 발화한다. Gemini에서 실해 사례가 있었으며, Claude Code에서도 MCP를 통해 동일한 공격 표면이 성립된다.

분기 조건: 확정해도 좋은 것은 「자신의 프라이빗 시간 블록」뿐이다. 타인을 포함하는 초대는 제안 초안(Draft) 단계에서 멈추고, 인간의 최종 확인을 요구한다.

4.3 금전·계약 관련 판단

하지 말 것: 금액 판단, 계약 승인, 결재, 지불 기안.

이유: 실패 시의 불가역성(Irreversibility)이 다른 도구 조작과 비교했을 때 차원이 다르게 높다. 비서 LLM이 잘못 판단할 경우, 롤백(Rollback)할 수 없는 경제적 영향이 발생한다 (잘못 주문한 주식·송금된 금액은 취소할 수 없다). LLM 자체가 수치 계산에서 결정론적(Deterministic)으로 동작하지 않기 때문에, 자릿수 오류·통화 단위 혼동·소수점 어긋남은 확률적으로 발생한다. 「확률적 판단」과 「금전의 불가역성」은 본질적으로 상성이 나쁘며, Anthropic 스스로도 Computer Use 문서에서 "금융 거래, 주문, 송금, 이체는 AI에게 실행시키지 않는다"라고 명시하고 있다.

분기 조건: 예외 없음. 비서 스코프(Scope)에는 금전 계열 MCP / API를 일절 포함하지 않는다.

4.4 기밀 정보의 외부 LLM 연동

하지 말 것: 기밀 정보가 포함된 메일 본문·캘린더 상세 내용·Slack DM을 그대로 외부 LLM (OpenAI / Gemini / Bedrock을 경유한 Claude 이외)에 전송하는 것.

이유: 인증 실태 조사에 따르면, 93%의 서비스 연동이 unscoped (과도한 스코프), 74%가 over-privileged (과도한 권한) 라는 수치가 나오고 있다 [11]. 비서 계층에서 기밀 정보 필터가 작동하지 않으면, 하류의 모든 LLM 연동으로 정보가 그대로 흘러 들어간다.

분기 조건: 외부 LLM 연동은 confidential 라벨이 붙은 것이나 특정 채널을 제외하는 filter pattern을 Hooks의 PreToolUse에서 구현하여, 필터를 통과한 경우에만 허용한다.

4.5 장기 기억의 무제한 축적

하지 말 것: 사용자의 발화를 전부 MEMORY.md에 기록하는 것 / 수신 메일 전건을 archive 폴더에 영구화하는 것.

이유: Permanent Memory Poisoning (arXiv 2508.12175의 5가지 위협 클래스 중 하나 [4:2]). 공격자는 수신 메일을 통해 기억 오염을 시도하며, 오염된 기억은 다음 이후의 세션에서 비서의 판단을 왜곡한다. 기억 계층은 용량보다 "무엇을 남기지 않을 것인가"에 대한 설계가 우선이다.

분기 조건: 수신 메일은 30일 후에 archive, archive는 6개월 후에 삭제한다. MEMORY.md에는 「사용자가 명시적으로 기록을 요청한 사항」만을 기록한다. 좋은 아침이야와 같은 인사로 멋대로 학습시키지 않는다.

4.6 IPI 대책의 생략

하지 말 것: 수신 메일 본문 / 캘린더 제목(title) / 첨부 파일명을 untrusted 마킹 없이 Claude에게 전달하는 것.

이유: Anthropic의 최신 IPI 측정치 [6:1]를 본 기사에서는 정면으로 다룬다.

구체적인 방어책은 다음 4가지다.

• 수신 메일 본문·캘린더 제목·첨부 파일명을 <untrusted>...</untrusted>로 래핑(Wrapping)하여 프롬프트에 전달한다.
• PreToolUse Hook에서 send 계열·create 계열·post 계열을 반드시 가로채기(Interception)한다.
• SessionStart hook은 hookSpecificOutput.additionalContext의 JSON 형식으로 주입한다 (비구조화된 stdout은 untrusted로 취급).
• Auto Memory에 user instructions를 쓰지 않는다 (Permanent Memory Poisoning 방어).

분기 조건: 수신처가 완전히 폐쇄된 신뢰 도메인(사내 전용, 외부 수신 없음)인 경우에만 untrusted 마킹을 생략할 수 있다. 그 외에는 예외 없다.

4.7 「비서」 호칭의 심리적 편향

하지 말 것: 팀에 대한 설명에서 「비서」라는 호칭을 남용하는 것. 설정 파일 내의 역할명은 secretary여도 상관없지만, 사용자용 설명 자료에서는 「초안 작성 에이전트」, 「회의 요약 에이전트」 등 기능명으로 부른다.

이유: 의인화 편향 (Reeves & Nass 저서 『The Media Equation』)과, Anthropic Computer Use 문서가 경고하는 자동화 편향(Automation Bias)이 겹친다. 「비서」라고 부르면 인간은 무의식적으로 "비서라면 판단할 수 있겠지"라며 위임의 임계치를 낮추게 되고, 리뷰 강도가 떨어진다.

분기 조건: 개인 이용 시 호칭은 자유롭다. 단, 팀 전개 시, 특히 경영진에게 설명할 때는 「LLM이 확률적으로 판단하는 자동 도구」임을 명시하는 용어를 선택한다. 또한, 본 논점의 심리학적 근거는 두텁지 않다. Reeves & Nass의 연구는 1996년의 것이며, LLM 문맥에서의 재현 실험(reproduction)은 아직 적다는 점에 유의가 필요하다.

단계 확장 — 로컬 프로토타입에서 조직 배포까지의 3단계

「5개 계층 × 7개 경계」를 추상론으로 끝내지 않기 위해, 최소 구성으로부터의 확장 경로를 제시한다. 각 Step에는 「다음 Step으로 넘어가기 전의 Done 조건」을 하나씩 둔다.

학습 비용의 기준(경험칙)도 미리 공유한다. **시니어/테크 리드(Tech Lead)의 경우 Step 1은 반나절1일, Step 2는 12일, Step 3는 24주(설명 자료 작성 + 스테이크홀더(Stakeholder) 조정 포함)**가 소요된다. Claude Code 미경험 멤버가 Step 2까지 자력으로 도달하려면 permission_mode, Hooks, MCP에 대한 사전 지식이 필요하며, 별도로 12주간의 온보딩(Onboarding)을 거쳐야 한다. 주니어 멤버가 Step 3를 단독으로 주도하는 것은 현시점에서는 권장하지 않는다 (OAuth scope와 조직 거버넌스의 판단 요소가 너무 많기 때문이다).

5.1 Step 1: 로컬 CLI + 아침 브리핑

최소 구성은 Sonnet 4.6 + Gmail MCP (read-only 스코프만 허용) + Calendar MCP (read-only)를 사용하여 로컬 CLI에서 おはよう (좋은 아침)

등의 명령어로 기동하는 형태다.

Done 조건: Gmail / Calendar의 read-only 스코프만으로 1주일간 구동해도 부족함을 느끼지 않는다. 쓰기(write) 계열 기능을 추가하고 싶어지는 순간 Step 2로 넘어간다.

5.2 Step 2: Routines화 + draft-only 모드

Step 1을 Routines에 올린다. 여기서 H2 1.1과 H2 4가 효과를 발휘한다. permission_mode는 Routines에서는 적용되지 않으므로, 설계 시 결정해야 할 사항은 다음 2점이다.

const briefing = query({
prompt: "아침 브리핑: 중요한 메일과 오늘 일정을 정리해 주세요.",
options: {
...

Routines에 올릴 때는 UI의 Connector 선택 화면에서 gmail.send 권한을 가진 커넥터가 포함되어 있지 않음을 명시적으로 확인한다. 기본 설정은 「모두 포함」이므로, 불필요한 것은 반드시 제외한다 [1:4].

Done 조건: Routines daily cap (Pro 기준 1일 5회) 범위 내에서 안정적으로 운용할 수 있으며, 1개월간 send / create / post 계열의 의도치 않은 발화가 0건이다.

5.3 Step 3: 조직 배포

조직 전개 시에는 Managed Agents (베타 헤더 managed-agents-2026-04-01 [7:1])의 이용과 보안 팀을 위한 설명 자료가 필요하다. 설명 자료에 최소한으로 포함해야 할 사항은 다음 4점이다.

• 5개 계층 아키텍처 도표 (본문 H2 3 내용)
• 7가지 「하지 말아야 할 판단」 목록 (본문 H2 4 내용)
• Anthropic IPI 측정값의 출처 명기 ([6:2], 제3자 재현 실험 미존재 주석 포함)
• 철수 노트 (본문 H2 7.3에서 상세 기술)

승인을 「형식적인 게이트(Gate)」로 만들지 않기 위해, 3자(보안, 법무, 감사)가 각각 던질 것으로 예상되는 질문을 미리 준비해 두면 승인이 수월하다.

• 보안 팀: 「IPI 방어율 ([6:3]의 값)을 자사 환경에서 재현 테스트했는가", 「OAuth scope는 최소인가 (gmail.send를 가지지 않음을 확인했는가)", 「routine의 Connector 목록 차분 리뷰(diff review) 프로세스는 무엇인가"
• 법무: "비서를 통해 기밀 정보가 Anthropic 안전 위반 로그(입출력 2년·스코어 7년)로 넘어갈 가능성을 어떻게 통제할 것인가", "PII(개인 식별 정보)를 포함하는 메일은 비서 스코프에서 제외한다는 규칙이 문서화되어 있는가"
• 감사: "routine의 실행 로그 및 실패 로그가 보존(retention)되는가", "누가 언제 어떤 routine을 변경했는지 추적(traceable) 가능한가"

더불어, Step 1 → 2 → 3 과정에서 누가 오너십(Ownership)을 갖는지를 최소한으로 정의해 두어야 한다.

현장에서 빠지는 함정과 대책

이후부터는 "작동시키고 나서야 비로소 깨닫는" 종류의 함정이다. 사전에 제거해 둔다.

6.1 서브 에이전트(Sub-agent) 권한 상속 트랩

bypassPermissions / acceptEdits / auto (TS 한정)는 자식 서브 에이전트에게 상속되며 override(재정의) 불가능[8:3]하다. "비서(parent)는 dontAsk, 메일 전송 subagent는 acceptEdits"와 같은 설계는 할 수 없다. 부모에서 bypassPermissions를 사용하면 자식도 전부 그대로 통과된다.

대책은 단순하다. 부모에서 dontAsk를 사용하고, 자식의 역할(Role)별로 allowedTools를 제한한다. 자식 단계에서 "어떻게든 자동 승인하고 싶은 조작"이 발생한다면, 그것은 자식의 책임 분할(Responsibility splitting)을 의심해야 한다.

6.2 Routines의 Connectors 기본값 전체 활성화

Routines를 생성하면, 연결된 MCP 커넥터(Connector)는 기본적으로 전부 활성화된다[1:5]. "현재 세션에서는 Gmail만 사용하고 싶다"고 생각하더라도, Slack이나 Notion의 쓰기 권한이 포함된 상태로 동작한다.