거주성(Residency), 보존 기간(Retention), 에이전트 권한. 그 외의 모든 것은 서류 작업일 뿐이다.
다음은 안전해 보이는, 그러나 그렇지 않은 설정 예시입니다:
{
"permissions": {
"deny": ["WebFetch"]
...
}
당신은 Claude Code의 HTTP 도구를 차단했습니다. 또한 curl을 완전히 열어두었습니다. 하지만 에이전트는 여전히 인터넷에 접근하여 리포지토리를 유출하거나 페이로드를 다운로드할 수 있습니다. 왜냐하면 Bash는 당신이 제한하려 했던 거의 모든 다른 도구들의 초집합(superset)이기 때문입니다. 거부 규칙(deny rules)은 도구 이름에 대한 필터일 뿐, 기능 자체에 대한 것이 아닙니다. 이 목록만으로는 부족하며, 그 아래에 샌드박스(sandbox)가 필요합니다. 그렇지 않으면 이 목록은 장식품에 불과합니다.
이 간극이야말로 영국 기업 내부에서 Claude를 운영하는 전체 문제에 대한 좋은 모델입니다. 어려운 부분들은 조달 체크리스트가 묻는 것들이 아닙니다. 합리적으로 보이는 설정조차도 이름이 암시하는 것보다 적은 기능을 수행할 수 있는 지점들입니다.
실질적인 무게를 가지는 세 가지 결정 사항이 있습니다. 추론(inference)이 어디서 실행되는지, 데이터가 얼마나 오래 남아 있는지, 그리고 에이전트가 무엇을 만지는 것이 허용되는지 여부입니다.
1. 영국 지역은 없으며, 이를 염두에 두고 계획해야 한다
당신의 아키텍처를 변화시키는 사실부터 시작합시다. Anthropic의 자체 API는 정확히 두 가지 추론 지리적 위치(inference geographies)만 지원합니다: global과 us. EU 지역도, 영국 지역도 없습니다.
response = client.messages.create(
model="claude-opus-5-5",
max_tokens=1024,
...
}
Claude 4.6 이상 버전에서는 US 전용 추론이 입력(input), 출력(output), 캐시 쓰기(cache writes), 캐시 읽기(cache reads) 모두에서 표준 요율 대비 1.1배의 비용이 청구됩니다. 워크스페이스 지리적 위치(Workspace geography)는 별도의 설정이며, 현재 US 전용이고, 워크스페이스 생성 시 고정됩니다. 나중에 마이그레이션할 수 없습니다. 생성 버튼을 누르기 전에 결정해야 합니다. 왜냐하면 수정하려면 새로운 워크스페이스가 필요하기 때문입니다. 자세한 내용은 Anthropic의 데이터 거주성 문서에 나와 있으며, 이 문서는 변경되므로 지난 분기의 블로그 게시물(이 글 포함)을 신뢰하기보다는 실제 배포 시점에 읽는 것이 좋습니다.
만약 귀하의 DPIA(데이터 보호 영향 평가)가 영국 내 처리를 실제로 요구한다면, 첫 번째 파티 API는 적절한 경로가 아닙니다. 클라우드 리셀러를 이용해야 합니다. Amazon Bedrock은 런던을 eu-west-2로 노출하며, Microsoft Foundry는 유럽 지역이 곧 제공될 예정인 미국 데이터 존(US Data Zone)을 제공하고, Google Vertex AI는 자체적인 지역별 특성을 가지고 있습니다.
Bedrock의 함정은 유럽 지리적 프로필 자체가 영국 전용 프로필이 아니며, 인-리전 처리 지원이 리전 단위가 아닌 모델별로 다르다는 점입니다. 런던에서 사용 가능한 모델이라도 지리적 또는 글로벌 프로필을 통해 라우팅될 수 있습니다. 따라서 지역 페이지가 아닌, 실제로 고정하려는 정확한 모델 ID에 대한 라이브 모델 카드를 확인해야 합니다. NeuralTrust의 영국 기업용 Claude 보안에 대한 심층 글은 각 제공업체를 더 자세히 다루고 있으며, 이 부분이 스택에서 가장 빠르게 변화하는 부분이라는 주의사항이 있습니다.
만약 여러 모델이나 여러 제공업체를 운영한다면, 아키텍처적 해결책은 거주지(residency)를 호출당 파라미터로 설정하는 것을 멈추고 라우팅 정책으로 만드는 것입니다. 이는 전체 시스템 앞에 AI 게이트웨이를 배치하는 경우에 해당하며, 이 경우 관할권(jurisdiction), 마스킹(redaction), 로깅이 API 키를 보유하는 모든 서비스가 아닌 한 곳에서 강제됩니다.
2. 보존 기간은 긴 여파를 남긴다 (Retention has a long tail)
API 입력 및 출력 데이터는 30일 주기로 삭제됩니다. 사람들이 놓치는 부분은 예외 사항입니다. 안전 분류기(safety classifiers)에 의해 플래그가 지정된 콘텐츠는 신뢰 및 안전 검토를 위해 수년 동안 훨씬 더 오래 보존될 수 있습니다. 대부분의 워크로드에서는 이 부분이 중요하지 않습니다. 하지만 영국 GDPR(영국 일반 데이터 보호 규정) 하에서 특별 범주 데이터를 처리하는 워크로드라면, 이는 DPO(데이터 보호 책임자)가 질문할 문제이며, 이때 '30일'이라는 답변은 잘못된 것입니다.
제로 데이터 보존(Zero data retention, ZDR)이 가능하지만, 모든 경우에 적용되는 것은 아닙니다. 배치 처리(Batch processing)와 Files API 등이 제외 항목에 속합니다. 만약 귀하의 규정 준수 시나리오가 ZDR에 의존한다면, 실제로 그 범주에 속하는 코드 경로를 명확히 나열해야 합니다.
엔터프라이즈 감사 로그(Enterprise audit logs)는 180일의 기간으로 운영되며 Compliance API를 통해 접근할 수 있습니다. 180일은 대부분의 영국 사고 보존 정책(UK incident retention policies)보다 짧다는 의미이므로, 이 로그들은 시스템 기록원(system of record)이라기보다는 내보내기 출처(export source)입니다. 정해진 스케줄에 따라 SIEM으로 전송하고 그곳에서 경고를 발생시키십시오.
3. 에이전트가 공격 표면이다 (The agent is the attack surface)
위에 언급된 모든 내용은 저장 중 데이터(data at rest)와 전송 중 데이터(in transit)에 관한 것입니다. 흥미로운 위험은 실행 시간(runtime)에 존재합니다.
프롬프트 인젝션(Prompt injection)은 OWASP Top 10 for LLM Applications에서 1위를 차지하고 있으며, 이는 패치로 해결할 수 있는 버그가 아니기 때문에 여전히 그 자리를 지키고 있습니다. 이는 명령어와 데이터를 하나의 채널에서 혼합하는 결과입니다. 이 목록의 에이전트 확장(agentic extension)에는 목표 하이재킹(goal hijacking), 도구 오용(tool misuse), 권한 남용(privilege abuse)이 추가되는데, 이는 폭발 반경(blast radius)이 붙은 동일한 문제입니다.
모델 공급업체들은 출시할 때마다 인젝션 방어에 대한 개선된 수치를 발표하며, 그 개선 사항들은 실제입니다. 하지만 그것들은 사용자가 소유하는 통제 장치가 아니며, 사용자가 감사할 수도 없고, 사고 검토 과정에서 지적할 수 있는 것도 아닙니다. 이를 자체 정책 계층(own policy layer) 하의 방어 심화(defence in depth)로 취급해야 하며, 절대 정책 계층 그 자체로 간주해서는 안 됩니다.
실제로 사용자가 소유하는 것:
- 샌드박싱 (Sandboxing). 코드를 실행할 수 있는 모든 에이전트에 대한 파일 시스템 및 네트워크 격리. 이것이야말로 거부 목록(deny list)에 의미를 부여합니다.
- 도구별 최소 권한 (Least privilege per tool). 범위가 지정된 권한으로 커넥터를 개별적으로 승인해야 합니다. 하나의 레포지토리에 대한 읽기 접근 권한을 가진 에이전트는 워크스페이스 전체 토큰(workspace-wide token)을 가진 에이전트와는 다른 위험도를 가집니다.
- 에이전트별 고유 식별자 (Distinct identity per agent). 공유 서비스 계정은 나중에 출처를 파악하는 것을 불가능하게 만듭니다.
- 킬 스위치 (A kill switch). 장시간 실행되는 에이전트 세션을 즉시 중단시키는 기능으로, 필요하기 전에 테스트해야 합니다.
- 배포 전 레드팀 운영 (Red teaming before rollout). 일반적인 벤치마크가 아닌 실제 도구 구성에 대해 인젝션, 도구 오용 및 권한 상승을 시도합니다.
해당 목록은 임의로 만들어진 것이 아닙니다. 이는 2026년 8월에 발표된 NCSC의 임시적 에이전트형 AI (agentic AI) 가이드라인과 밀접하게 연관되어 있으며, 해당 지침에서는 샌드박싱(sandboxing), 고유한 에이전트 신원(unique agent identities), 로그 캡처(log capture), 비상 종료(emergency shutdown)를 권장합니다. 이 지침은 임시적이고 법적 구속력이 없으므로 (non-statutory), 실제로는 어떤 강제적인 규정도 없는 상황에서 감사관이 참고할 자료가 될 것입니다. 만약 항목별 상세 내용을 원하신다면, NeuralTrust에서 NCSC 가이드라인 및 구현 방법 분석을 확인하실 수 있습니다.
실제 자격 증명(real credentials)과 실제 도구(real tools)를 통해 활동하는 자율 에이전트(autonomous agents)의 광범위한 위협 모델에 대해서는, agentsecurity.com이 이러한 실패 모드(failure modes)가 어떻게 분류되고 있는지에 대한 유용한 참고 자료입니다.
영국 규제 현황 (간략히)
이를 목표로 하는 AI 전용 법규는 없습니다. NCSC 가이드라인은 임시적입니다. DSIT의 AI 사이버 보안 모범 사례(AI Cyber Security Code of Practice)는 자발적인 권고 사항입니다. 2025년 데이터 (사용 및 접근)법(Data (Use and Access) Act 2025)이 단계적으로 시행되면서 자동화된 의사 결정과 국제 전송에 관한 규칙을 변경하고 있으므로, 사용 사례에 실제로 적용되는 조항을 확인해야 합니다. ICO의 AI 및 자동화된 의사 결정 관련 코드는 아직 개발 중입니다. FCA와 PRA는 새로운 AI 규정을 만드는 대신 기존 원칙들을 적용하고 있습니다.
실질적인 해석은 아무도 준수 가능한 구성을 그대로 제공하지 않을 것이라는 것입니다. 사용자는 기존 데이터 보호 및 운영 복원력(operational resilience) 의무에서 자체적으로 구성안을 도출해내고, 그 과정(working)을 입증해야 합니다.
제가 실제로 할 일
- 역순이 아니라 거주지 요건(residency requirement)에서 배포 경로를 선택하세요. 라이브 모델 카드(live model card)와 대조하여 확인하십시오.
- 파일럿(pilot) 이후가 아니라 이전에 DPIA(데이터 보호 영향 평가)와 데이터 전송 위험 평가를 수행하십시오.
- 첫날부터 SSO(싱글 사인온), SCIM, 역할 기반 접근 제어, 사용자 정의 보존 기간 설정, 그리고 IP 허용 목록 지정을 활성화하십시오.
- 관리형 설정(managed settings), 거부 규칙(deny rules), 샌드박스, 그리고 MCP 허용 목록을 사용하여 Claude Code를 잠가두십시오. 샌드박스가 거부 규칙을 실제로 작동하게 만든다는 것을 기억하십시오.
- 커넥터와 도구를 한 번에 하나씩, 범위 지정하여 승인하십시오.
- 감사 로그를 SIEM(보안 정보 및 이벤트 관리)으로 내보내고, 단순한 인증 이벤트가 아닌 도구 사용 이상 징후에 대해 경고하도록 설정하십시오.
- 곧 출시할 설정을 대상으로 레드팀 테스트를 수행하십시오.
모델 보호 장치는 매 릴리스마다 개선됩니다. 하지만 에이전트가 Jira 티켓에서 발견한 텍스트에 지시된 대로 정확히 행동할 때는 여전히 도움이 되지 않습니다. 중요한 통제는 API 호출의 사용자 측(your side)에서 실행되는 것입니다.