에이전트 키에는 위험 예산이 필요합니다

Shuriken의 shuriken-skills 저장소는 Claude Code, Codex CLI, GitHub Copilot CLI, Gemini CLI, Cursor, OpenCode, AGENTS.md 호환 에이전트를 위한 지침을 패키지로 제공합니다.¹ 이 저장소는 또 사용자가 해당 기능을 허용하면 에이전트 키로 시장 데이터를 읽고, 지갑을 살펴보고, 견적을 요청하고, 거래를 실행할 수 있는 플랫폼으로 에이전트를 안내합니다.²

중요한 점은 거래 자체가 아니에요. 중요한 것은 패턴입니다. 이제 에이전트에는 실제 외부 효과를 만들 수 있는 도구의 자격 증명이 필요합니다. 에이전트 키는 일반 API 키처럼 동작해서는 안 됩니다. 위험 예산처럼 동작해야 합니다.

에이전트 키는 경계가 정해진 권한 객체입니다. 에이전트가 무엇을 할 수 있는지, 무엇을 할 수 없는지, 어느 정도의 위험을 만들 수 있는지, 운영자가 그 행동을 어떻게 확인할 수 있는지, 누군가가 얼마나 빠르게 일시 중지, 교체, 철회할 수 있는지를 말해 주어야 합니다. 프롬프트 지침도 도움이 되지만, 경계는 서버 측 제한이 책임져야 합니다.

요약

MCP와 이식 가능한 스킬은 에이전트가 외부 시스템에 더 쉽게 연결되도록 해 줍니다.³⁴ 이런 이식성은 자격 증명의 중요도를 높입니다. Shuriken 문서는 위험한 도구에 맞는 올바른 제어 형태를 설명합니다. 에이전트 키를 만들고, 필요한 권한만 부여하고, 서버 측에서 제한을 강제하고, 활동을 기록하고, 통합에 더 이상 필요하지 않으면 키를 철회하는 방식입니다.²⁵⁶ 최근 최소 권한 연구도 같은 방향을 가리킵니다. 스킬은 특정 작업에 필요한 최소 범위를 넘어서는 행동을 수행할 수 있으므로, 권한은 패키지 전체가 아니라 작업을 인식하는 방식으로 바뀌어야 합니다.⁹

이 교훈은 금융 밖에서도 적용됩니다. 돈을 보내거나, 콘텐츠를 게시하거나, 인프라를 바꾸거나, 고객에게 메시지를 보내거나, 비공개 데이터를 다루는 모든 에이전트 도구에는 위험 예산이 있는 범위 제한 키가 필요합니다. 그 예산은 모델보다 아래에, 스킬 파일보다 아래에 있어야 합니다. 에이전트가 확신에 차서 요청하더라도 서버는 허가되지 않은 행동을 거부해야 합니다.

핵심 내용

• 에이전트 도구 제작자에게: 자격 증명을 범용 bearer token이 아니라 기능 예산으로 설계하세요.
• 보안 팀에게: 읽기 범위와 쓰기 또는 실행 범위를 분리한 뒤, 실행 쪽에 지출, 속도, 객체 제한을 두세요.
• 제품 팀에게: 활동 로그와 철회 제어를 깊숙한 설정 페이지가 아니라 기본 UI에 보여 주세요.
• MCP 제작자에게: 도구 배포와 자격 증명 권한을 서로 다른 층으로 다루세요. 스킬은 가르칠 수 있습니다. 키는 제한해야 합니다.
• 운영자에게: 읽기 전용으로 시작하고, 통합 경로를 입증한 뒤, 대응 계획이 있을 때만 쓰기 접근 권한을 추가하세요.

스킬은 지침을 배포하고, 키는 권한을 배포합니다

shuriken-skills 저장소는 새로운 배포 패턴을 보여줍니다. 하나의 소스 트리 안에 스킬 Markdown, Claude와 Codex용 플러그인 매니페스트, Cursor 플러그인 매니페스트, Gemini 확장 파일, OpenCode 플러그인, Rust crate, AGENTS.md 대체 경로가 함께 들어 있습니다.¹⁷

이 패키징이 중요한 이유는 에이전트 지침이 이제 여러 클라이언트를 가로질러 이동하기 때문입니다. 한 벤더는 Codex, Claude Code, Cursor, Gemini, 그 밖의 도구에 동일한 API와 통합하는 방법을 가르칠 수 있습니다. MCP 문서는 에이전트 스킬을 코딩 보조 도구에 도메인 지식을 제공하는 이식 가능한 지침 집합으로 설명하며, 여기에는 배포 모델, 인증 흐름, 도구 패턴에 관한 설계 결정도 포함됩니다.⁴ 저는 배포 측면을 에이전트 스킬에는 패키지 관리자가 필요합니다에서 다루었습니다. 보안 측면은 그 패키지가 실제 권한을 요구하는 순간 시작됩니다.

이식 가능한 지침은 하나의 문제를 해결하는 동시에 다른 문제를 만듭니다. 에이전트가 올바른 통합 경로를 배우는 데는 도움이 됩니다. 하지만 그 결과로 발생하는 행동을 안전하게 만들지는 않습니다. 스킬은 모델에 최소 권한을 사용하라고 말할 수 있습니다. 프롬프트는 “조심하라”고 말할 수 있습니다. README는 권장 범위를 설명할 수 있습니다. 그러나 모델이 요청을 보내기로 결정한 뒤에는 그 어떤 제어도 인증된 요청을 멈추지 못합니다.

이 긴장은 MCP 서버가 새로운 공격 표면입니다에서 다룬 더 넓은 MCP 문제와도 맞닿아 있습니다. 도구 접근은 기존 승인 습관이 따라잡는 속도보다 더 빠르게 행동 표면을 넓힙니다. 에이전트 스킬은 지침 경로를 이식 가능하게 만듭니다. 키 시스템은 권한 경로를 좁게 유지해야 합니다.

그래서 자격 증명에는 별도의 설계가 필요합니다. 스킬 파일은 지침 층에 있습니다. 에이전트 키는 권한 층에 있습니다. 이 두 층을 섞으면 취약한 시스템이 됩니다. 에이전트에게 무엇을 해야 하는지 가르치는 같은 텍스트가 에이전트가 너무 많은 일을 하지 못하게 막으려 하기 때문입니다.

경계는 서버에 있어야 합니다.

Shuriken 패턴은 위험 예산입니다

Shuriken의 Agent Kit 문서는 에이전트 키를 AI 도구가 무엇을 할 수 있는지 제어하는 객체로 설명합니다. 토큰 가격을 읽는 일부터 거래를 실행하는 일까지 해당되며, 에이전트가 행동을 시작하기 전에 서버 측 제한이 강제됩니다.⁵ 권한 페이지는 6가지 권한 범주를 제시하고, 부여된 범위를 벗어난 호출은 authorization error로 실패한다고 설명합니다.⁶

이 관점은 공개 에이전트 데모에서 흔한 실수도 피하게 해 줍니다. 공개된 코드, 보이는 지침, 읽을 수 있는 플러그인 매니페스트를 경계로 착각하는 실수입니다. 공개성은 검토에 도움이 될 수 있지만, 오픈 소스는 보안 경계가 아닙니다. 경계는 허가되지 않은 행동이 실패하는 지점에 있습니다.

이 패턴에는 5가지 요소가 있습니다.

이것이 고위험 에이전트 도구에 맞는 형태입니다. 이 설계는 모델이 현명해지기를 기대하지 않습니다. 모델이 틀릴 수도 있고, 과신할 수도 있고, 입력에 의해 손상될 수도 있고, 단순히 나쁜 지침을 받았을 수도 있다고 가정합니다. 그래도 서버는 키를 강제합니다.

저라면 분야가 아니라 제어 패턴을 복사하겠습니다. 배포 키, 게시 키, 고객 메시징 키, Stripe 환불 키, 거래 키는 모두 같은 질문이 필요합니다. 사람이 알아차리기 전에 이 키가 만들 수 있는 최대 피해는 무엇인가요?

서버 측 제한은 프롬프트 약속보다 강합니다

OpenAI의 Agents SDK 문서는 가드레일을 에이전트 주변에서 실행될 수 있는 검사로 설명하며, 여기에는 tripwire가 있는 입력 가드레일과 출력 가드레일이 포함됩니다.⁸ 가드레일은 모델 실행 전후의 위험을 잡아낼 수 있기 때문에 도움이 됩니다. 하지만 가드레일은 여전히 자격 증명 권한과는 다른 층에 있습니다.

출력 가드레일은 나쁜 제안 행동에 표시를 달 수 있습니다. 서버 측 키 제한은 가드레일이 놓치더라도 그 행동을 거부할 수 있습니다. 행동이 텍스트를 넘어설 때 이 차이는 중요합니다.

게시물을 발행하거나, 이메일을 보내거나, DNS record를 바꾸거나, pull request를 merge하거나, 거래를 실행할 수 있는 도구를 생각해 보세요. 프롬프트 규칙은 “먼저 물어보라”고 말할 수 있습니다. 가드레일은 고위험 텍스트를 찾을 수 있습니다. 서버 측 키는 실제 제한을 강제할 수 있습니다.

프롬프트 규칙은 조용히 실패할 수 있습니다. 키 수준 경계는 관찰 가능한 거부를 만듭니다. 그 거부는 증거가 됩니다. 에이전트가 범위를 넘으려 했습니다. 서버가 거부했습니다. 운영자는 실패한 요청을 살펴보고 통합에 새 키가 필요한지, 더 좁은 작업 흐름이 필요한지, 사람의 승인 단계가 필요한지 결정할 수 있습니다.

이는 증거 관문의 논리와 같습니다. 신뢰는 확신이 아니라 관찰 가능한 증거에서 나와야 합니다. “저는 제한 안에서 행동했습니다”라는 최종 답변보다 어떤 제한이 작동했는지 보여 주는 서버 로그가 더 의미 있습니다.

이 구조는 최종 답변도 검토 패킷에 더 가깝게 만듭니다. 검토 패킷이 새로운 최종 답변입니다는 중요한 에이전트 작업에는 증거 산출물이 필요하다고 주장합니다. 자격 증명 거부, 활동 로그, 범위 제한 키 변경은 그 산출물의 보안 버전입니다.

에이전트 자격 증명의 최소 형태

외부 세계에 영향을 줄 수 있는 모든 에이전트 자격 증명은 6가지 속성을 가져야 합니다.

Shuriken 스킬도 통합 언어로 같은 핵심을 말합니다. 통합마다 키를 하나 만들고, 최소 범위만 부여하고, 키를 비밀로 유지하고, 침해가 의심되면 교체하고, 사용이 끝난 통합은 철회하라는 내용입니다.⁷ 범위 설정 스킬도 읽기 범위와 거래 범위를 분리하고, “혹시 모르니” 넓게 잡는 키를 경계하라고 말합니다.⁷

연구 용어도 이 제품 패턴을 따라잡고 있습니다. SkillScope 논문은 과도한 권한을 작업 조건부 문제로 설명합니다. 같은 스킬 행동도 어떤 사용자 요청에서는 타당하지만 다른 요청에서는 과할 수 있습니다.⁹ 저자들은 검증된 과도 권한 행동이 있는 스킬 7,039개를 보고했으며, 자신들의 프레임워크로 권한을 제한한 뒤 평가에서 트리거된 과도 권한 행동 인스턴스가 88.56% 줄었다고 밝혔습니다.⁹ 그 정확한 메커니즘을 그대로 복사할 필요는 없습니다. 받아들여야 할 제품 교훈은 분명합니다. 에이전트 자격 증명은 도구가 상상할 수 있는 가장 큰 작업이 아니라 현재 작업을 반영해야 합니다.

이 지침은 일반적인 에이전트 제품 설계가 되어야 합니다. 넓은 API 키는 백엔드 서비스가 좁은 코드 경로를 소유하던 시절에는 타당했습니다. 에이전트는 하나의 좁은 코드 경로처럼 행동하지 않습니다. 에이전트는 계획하고, 재시도하고, 도구를 조합하고, 실패를 요약하고, helper script를 호출하고, 외부 입력에 반응합니다. 자격 증명은 일반 서비스 토큰보다 더 큰 행동 변동성을 가정해야 합니다.

그 변동성 때문에 에이전트 코드 검색에는 토큰 예산 문제가 있습니다가 자격 증명 글에서도 중요합니다. 에이전트는 종종 부분적인 맥락으로 결정합니다. 좁은 키는 context window가 위험한 세부 사항을 놓쳤을 때 시스템에 두 번째 기회를 줍니다.

복사하지 말아야 할 것

마케팅식 낙관은 복사하지 마세요.

Shuriken의 공개 문서는 사용자가 자리를 비운 동안 에이전트가 행동하고 기회를 잡는다는 강한 표현을 사용합니다.² 그 표현은 해당 제품에는 맞을 수 있습니다. 하지만 외부 효과를 만드는 에이전트 도구의 기본 안전 자세가 되어서는 안 됩니다.

고위험 행동에서 “자리를 비운 동안”은 더 좁은 운영상 의미를 가져야 합니다.

• 에이전트는 사용자가 자리를 비운 동안 정보를 수집할 수 있습니다.
• 에이전트는 사용자가 자리를 비운 동안 행동 초안을 준비할 수 있습니다.
• 에이전트는 작고 명시적이며 서버가 강제하는 예산 안에서만 실행할 수 있습니다.
• 운영자는 나중에 모든 행동을 확인할 수 있습니다.
• 운영자는 키를 즉시 일시 중지하거나 철회할 수 있습니다.

이것이 자율성과 책임 방기의 차이입니다. 사용자는 행동을 위임할 수 있습니다. 시스템은 책임을 위임할 수 없습니다.

스킬과 플러그인 매니페스트에도 같은 주의가 필요합니다. 저장소가 모든 에이전트 클라이언트를 지원하더라도 보수적인 기본값을 가져야 합니다. 제가 살펴본 .codex-plugin/plugin.json은 인터페이스 메타데이터에 읽기 기능을 나열했고, 문서는 거래에 명시적으로 활성화된 권한과 제한이 필요하다고 설명합니다.⁷ 이 방향이 맞습니다. 배포는 넓을 수 있지만 권한은 좁게 시작해야 합니다.

결정 규칙

새 에이전트 통합이 자격 증명을 요청하면, 키를 발급하기 전에 분류하세요.

이 표는 모델 자체가 경계를 쥐고 있다고 가장하지 않으면서도 에이전트에 사용할 수 있는 경로를 제공합니다. 작업 흐름은 계속 개선될 수 있습니다. 키는 개선이 무제한 권한으로 변하는 것을 막습니다. 에이전트 실행 추적은 런타임 계약입니다는 감사 측면에서 같은 점을 말합니다. 시스템이 무슨 일이 일어났는지 보여 줄 수 없다면, 에이전트가 의도한 계약 안에서 행동했다는 사실을 입증할 수 없습니다.

저는 에이전트 샌드박스 보안은 제안일 뿐입니다에서도 같은 분리를 다루었습니다. 모델은 부여된 권한 안에서만 동작하면서도 안전하지 않은 결과를 만들 수 있습니다. 권한과 안전은 같은 것이 아니기 때문에 에이전트 키에는 위험 예산이 필요합니다.

FAQ

에이전트 키는 이름만 바꾼 API 키인가요?

아닙니다. 일반 API 키는 서비스에 대한 넓은 접근 권한을 부여하는 경우가 많습니다. 에이전트 키는 하나의 통합을 위한 경계가 정해진 기능 집합을 부여해야 하며, 서버 측 제한, 활동 로그, 그리고 사용자의 기본 세션에 영향을 주지 않는 철회를 포함해야 합니다.

서버 측 강제가 중요한 이유는 무엇인가요?

서버는 최종 요청을 봅니다. 모델 지침, 스킬 파일, 가드레일은 나쁜 행동을 놓칠 수 있습니다. 서버 측 권한 검사는 키에 필요한 범위가 없거나 설정된 제한을 넘을 때 요청을 거부할 수 있습니다.⁶

모든 에이전트는 읽기 전용으로 시작해야 하나요?

도구가 의미 있는 외부 효과를 가진다면 그렇습니다. 읽기 전용 접근으로 시작하고, 통합 경로를 검증한 뒤, 팀이 어떤 로그, 제한, 승인, rollback 단계가 있는지 알고 있을 때만 쓰기 또는 실행 권한을 추가하세요.

MCP는 에이전트 자격 증명을 더 위험하게 만드나요?

MCP는 외부 도구를 여러 클라이언트에 더 쉽게 연결할 수 있게 합니다.³ 그 편의성은 자격 증명 설계의 중요성을 높입니다. 이식 가능한 도구 접근에는 더 넓은 신뢰가 아니라 좁은 키가 따라와야 합니다.

팀은 Shuriken에서 무엇을 복사해야 하나요?

지침 배포와 서버 측 권한을 분리하는 방식을 복사하세요. 이식 가능한 스킬은 통합을 가르칠 수 있고, 범위 제한 키, 제한, 로그, 철회는 행동을 제약합니다. 제품, 법무, 운영 제어가 정당화하지 않는 한 분야 특화 거래 동작은 복사하지 마세요.

참고 문헌