에이전트에게 권한을 주지 말고 계획에 권한을 줘라

프로덕션 장애를 고치는 AI 에이전트에는 권한이 필요하다. 로그만 읽어서는 롤백할 수 없고, 설정을 바꾸거나 캐시를 지우거나 수정 코드를 올릴 수도 없다. 그렇다고 운영자의 권한을 통째로 넘기면 에이전트가 잘못 이해한 한 문장이 서비스 전체를 바꿀 수 있다.

그래서 지금까지의 선택은 답답한 read-only와 위험한 상시 권한 사이에 있었다. 안전한 에이전트는 제안만 하고, 실제로 유용한 에이전트는 사람처럼 넓은 권한을 가진다는 타협이다.

Vercel Agent가 흥미로운 이유는 이 양자택일을 권한 구조로 다시 풀기 때문이다. 에이전트에게 권한을 주는 대신 사용자가 승인한 계획에 권한을 준다. 모델을 완전히 믿지 않으면서도 프로덕션에서 실제 행동하게 만드는 방식이다.

신뢰는 정답률이 아니라 실수의 비용이다

Vercel Agent는 완전히 새로 등장한 제품이 아니다. 경보 분류와 pull request 검토에서 시작해, 대시보드에서 로그·지표·배포를 조사하고 해결 계획을 제안하며 승인 뒤 조치하는 범위로 확장됐다. 기본값은 read-only이고 `vercel-agent`라는 별도 principal로 움직인다.

이 구분은 이름표 이상의 의미가 있다. 일반적인 에이전트는 사용자의 토큰을 받아 사용자의 신원으로 행동한다. 로그에는 사람이 한 일과 에이전트가 한 일이 섞이고, 에이전트 하나만 중지하려면 사용자의 접근까지 끊어야 할 수 있다. 별도 principal을 두면 누가 요청했고, 누가 승인했으며, 어떤 주체가 실행했는지를 나눠 기록할 수 있다.

하지만 별도 신원만으로 안전해지지는 않는다. 이름이 다른 관리자 계정에 넓은 권한을 주면 위험은 그대로다. 신원은 행동을 귀속할 뿐이고, 실제 피해 범위는 권한이 결정한다.

계획이 곧 권한이 된다

Vercel Agent는 롤백, 설정 변경, 캐시 삭제 같은 write가 필요하면 먼저 계획을 제시한다. 사용자가 승인하면 그 계획에 명시된 작업에만 짧게 유효한 capability를 받고, 일을 마치면 다시 read-only로 돌아간다.

실행되는 각 호출은 계획의 capability, 발급된 토큰의 scope, 기존 팀 권한이라는 세 층을 모두 통과해야 한다. 사용자가 원래 할 수 없는 일을 에이전트가 대신 할 수 없고, 승인된 계획 밖의 행동도 모델의 판단만으로 넓힐 수 없다. 통제는 프롬프트가 아니라 플랫폼에 남는다.

이 설계의 핵심은 에이전트가 틀리지 않을 것이라고 가정하지 않는 데 있다. 모델이 잘못된 원인을 찾거나, 모호한 지시를 과도하게 해석하거나, 하위 에이전트가 엉뚱한 행동을 제안해도 실행 가능한 범위는 승인된 계획 안에 갇힌다. 신뢰를 모델의 성격에서 시스템의 경계로 옮긴다.

코드를 쓸 권한과 운영계를 바꿀 권한도 다르다

Vercel Agent가 만든 코드는 실제 운영계에서 바로 실행되지 않는다. 임시 Firecracker microVM인 Vercel Sandbox에서 실제 프로젝트의 build, test, lint를 돌리고 통과한 결과를 pull request로 제시한다. 코드를 자유롭게 생성하는 공간과 사용자에게 영향을 주는 공간을 분리한 것이다.

이 분리는 중요하다. 에이전트가 파일을 쓸 수 있다는 사실이 배포 권한을 가져야 한다는 뜻은 아니다. 테스트를 통과했다는 사실도 프로덕션 설정 변경이나 데이터 write를 허가하는 근거와는 다르다. 생성, 검증, 승인, 실행을 하나의 권한으로 묶을수록 작은 오류가 큰 사건으로 번진다.

물론 Vercel이 제시한 장애 대응 사례는 회사가 설명한 자사 환경의 전형적 시나리오다. 모든 장애를 3분 안에 해결한다는 독립된 보장이 아니며, 현재 기능도 Pro·Enterprise 팀에 점진적으로 배포 중이다. 그럼에도 별도 신원, 계획 단위 임시 권한, sandbox, 되돌릴 수 있는 배포를 한 흐름으로 묶은 설계는 더 넓은 질문을 남긴다.

프로덕션 에이전트에게 실제 권한을 주면서도, 잘못된 한 번의 판단이 계정 전체의 권한으로 번지지 않게 하려면 무엇을 분리해야 하는가?

먼저 분리할 것은 신원, 의도, 권한, 실행, 증거다. 이 다섯 층이 한 토큰과 한 대화 안에 합쳐져 있으면 사람의 승인 버튼이 있어도 안전하지 않다. 반대로 각 층이 독립된 객체와 판정을 가지면 모델이 바뀌어도 통제 구조는 남는다.

에이전트 신원은 사람의 대리 계정이 아니어야 한다

에이전트가 사용자의 API key를 그대로 쓰면 시스템은 행동의 실제 주체를 알 수 없다. “Owner가 실행했다”는 로그만 남고, 그 안에서 모델이 제안했는지 사람이 직접 명령했는지 복원하기 어렵다. 권한을 회수할 때도 사람과 에이전트를 함께 끊어야 한다.

독립된 agent principal은 최소 세 가지를 가능하게 한다. 에이전트별 권한 회수, 행동별 귀속, 여러 하위 에이전트 사이의 격리다. 같은 사용자를 위해 일해도 조사 에이전트, 배포 에이전트, 결제 에이전트가 하나의 자격증명을 공유할 이유는 없다. 하나가 오염되거나 잘못된 지시를 받아도 나머지의 권한으로 이동하지 못해야 한다.

Vercel이 Better Auth를 인수하며 Agent Auth를 함께 강조한 것도 이 층과 연결된다. Better Auth 팀은 각 에이전트가 독립된 신원과 scope가 제한되고 취소 가능한 권한을 갖는 방향을 개발해 왔다. 다만 인수 발표와 Vercel Agent의 기능 확장은 서로 다른 사건이다. 공개 라이브러리를 인수했다는 사실이 곧 범용 agent identity 표준의 완성을 뜻하지도 않는다.

신원을 분리해도 에이전트가 무엇을 하겠다는지 모호하면 권한은 다시 넓어진다. 다음 병목은 자연어 요청을 사람이 검토할 수 있는 계획으로 만들고, 그 계획을 기계가 강제할 수 있는 capability로 번역하는 과정이다.

승인할 대상은 자연어가 아니라 실행 가능한 계획이다

“문제를 고쳐줘”라는 문장에 승인 버튼을 붙이는 것은 계획 승인이라기보다 포괄 위임에 가깝다. 사람이 보아야 할 것은 목표뿐 아니라 어떤 리소스에 어떤 동사를 적용하고, 예상 결과가 무엇이며, 실패하면 어디로 돌아가는지다.

예를 들어 “checkout 장애를 해결한다”는 목표는 권한이 될 수 없다. “배포 A를 배포 B로 롤백하고, 캐시 key C만 삭제하며, 오류율이 기준 아래로 내려오지 않으면 추가 write 없이 중지한다”는 계획이어야 한다. 그래야 자연어 의도를 `deployment.rollback`, `cache.purge` 같은 제한된 capability로 번역할 수 있다.

계획은 실행 중에도 마음대로 늘어나면 안 된다. 조사하다 새 설정 변경이 필요해졌다면 기존 승인을 확대 해석하는 대신 새로운 diff를 제시하고 다시 권한을 받아야 한다. 좋은 계획 승인은 모델에게 재량을 없애는 것이 아니라, 재량이 필요한 순간과 권한이 필요한 순간을 분리한다.

짧은 수명만으로는 부족하다

short-lived token은 탈취됐을 때의 시간을 줄이지만, 살아 있는 동안 무엇이든 할 수 있다면 피해는 여전히 크다. 임시 권한은 시간뿐 아니라 대상 리소스, 허용 동작, 호출 횟수나 금액, 환경, 승인자 권한의 교집합으로 좁아져야 한다.

여기서 중요한 원칙은 권한 상승 금지다. 에이전트가 받은 capability로 다른 capability를 발급하거나, 새 principal을 만들거나, 자신의 정책을 고칠 수 있으면 계획의 경계가 무너진다. 권한을 집행하는 판정기는 모델이 수정할 수 없는 플랫폼 층에 있어야 한다.

Sandbox는 실행을 격리하지만 결과를 보증하지 않는다

격리된 환경에서 build와 test를 통과한 코드는 그렇지 않은 코드보다 안전하다. 그러나 sandbox는 테스트가 놓친 사업 규칙, 실제 트래픽의 경쟁 상태, 외부 결제와 데이터 변경까지 증명하지 않는다. 생성 코드가 host를 해치지 못하게 하는 경계와 그 코드를 운영계에 반영해도 되는지를 판단하는 경계는 별개다.

따라서 sandbox 결과는 배포 권한의 자동 승격이 아니라 승인에 붙는 증거가 되어야 한다. 어떤 테스트를 돌렸고, 무엇은 검증하지 못했으며, 변경 diff와 예상 영향이 무엇인지 남겨야 한다. 검증 증거가 없는 “성공”은 모델의 보고일 뿐 시스템의 판정이 아니다.

승인 피로는 사람을 더 많이 넣어서 해결되지 않는다

모든 캐시 삭제와 설정 변경을 사람이 매번 읽으면 결국 승인 버튼은 형식이 된다. 안전을 위해 넣은 사람이 처리량의 병목이 되고, 반복되는 요청에 무심코 동의하게 된다.

해법은 사람을 빼거나 권한을 넓히는 양자택일이 아니다. 낮은 위험의 반복 계획은 정책이 자동 승인할 수 있다. 대상이 staging이고, 비용 한도 안이며, 되돌릴 수 있고, 이미 검증된 행동 조합이라면 결정적 규칙이 승인한다. production 데이터 삭제, 결제, 권한 변경, 되돌리기 어려운 migration처럼 영향이 큰 계획만 사람에게 올린다.

이때 사람은 에이전트의 모든 사고 과정을 읽을 필요가 없다. 변경되는 권한의 diff, blast radius, 검증 결과, rollback 경로, 남은 불확실성을 보면 된다. 승인 인터페이스가 긴 추론문을 보여줄수록 중요한 권한 변화가 묻힐 수 있다.

Rollback은 실패 뒤의 기능이 아니라 권한의 전제다

Vercel은 immutable deployment가 각 배포를 보존하기 때문에 잘못된 변경을 이전 버전으로 되돌릴 수 있다고 강조한다. 이 구조는 에이전트를 위해 처음 만든 것이 아니지만, 자율 실행의 위험을 낮추는 기반이 된다.

같은 원리는 다른 시스템에도 적용된다. 설정은 이전 값을 보존하고, 데이터 변경은 보상 동작이나 복구 지점을 가지며, 외부 메시지는 초안과 발송을 나누고, 금전 행동은 한도와 취소 가능성을 먼저 확인해야 한다. 되돌릴 수 없는 행동일수록 capability는 더 좁고 승인 증거는 더 강해야 한다.

에이전트의 성능이 좋아질수록 더 넓은 권한을 미리 주고 싶어진다. 그러나 모델의 정답률은 권한 설계를 대체하지 않는다. 아주 드문 오류도 충분히 큰 권한과 만나면 사업을 멈출 수 있다. 반대로 제한된 권한과 빠른 복구가 있으면 완벽하지 않은 모델도 실제 일을 맡을 수 있다.

강력한 에이전트는 모든 일을 할 수 있는 에이전트가 아니다. 승인된 계획만 실행하고, 계획이 끝나면 다시 아무것도 바꿀 수 없는 에이전트다.

주요 출처: Vercel, Vercel Agent 및 Vercel acquires Better Auth; Better Auth, Better Auth is joining Vercel. 별도 principal, read-only 기본, plan-to-permission, short-lived capability, 세 층 권한 검사, Firecracker 기반 Sandbox와 immutable deployment는 Vercel의 공식 설명에 근거합니다. 장애 완화 사례와 제품 효과는 회사가 제시한 자사 시나리오이며 독립적인 보편 성능 측정이 아닙니다. 실행 가능한 계획의 구성, 자동 승인 위험 등급, 권한 상승 금지와 복구 설계는 이를 확장한 이 글의 분석입니다.