프로덕션 시스템에서 작동하는 에이전트는 행동할 권한이 필요합니다. "배포 수정"과 같은 요청은 어떤 작업을 수행할지, 또는 어떤 접근 권한이 필요한지를 미리 알려주지 않습니다. 에이전트에게 광범위한 접근 권한을 부여하면 실수로 인해 관련 없는 리소스에 영향을 줄 수 있습니다. 모든 단계에서 승인을 요청하고 사용자가 에이전트가 문제를 해결하려는 의도를 알기 전에 개별 작업을 승인하도록 해야 합니다. 반복적인 프롬프트는 이러한 검토 과정을 '승인' 버튼을 누르는 습관으로 바꿀 수 있습니다.
먼저 문제를 조사하고, 어떤 작업을 수행할지, 그리고 어떤 접근 권한이 필요한지를 보여주는 계획을 제안합니다. 이 계획을 승인하면 해당 작업을 수행하기 위한 추가 권한이 부여되므로, 사용자는 어떠한 변경 사항을 승인하기 전에 제안된 수정 사항을 검토할 수 있습니다.Vercel Agent
손상된 프로덕션 배포의 경우, Vercel Agent는 최근 배포를 검사하고 , 실패한 배포와 마지막으로 정상이었던(known-good) 배포를 비교할 수 있습니다. 읽기 전용 접근 권한은 이러한 조사가 자동으로 실행되도록 합니다. 만약 이것이 재배포가 필요하다는 결론으로 이어진다면, Vercel Agent는 사용자가 하나의 결정에서 검토하고 승인할 수 있는 계획에 추가 접근 권한을 요청합니다.build logs
접근 권한은 Vercel 인증 시스템이 인식하는 명명된 기능인 스코프(scopes)로 정의됩니다. 읽기 전용 기본 수준을 넘어선 접근 권한을 요청하는 모든 계획은 포함된 읽기 전용 작업과 함께 전체 승인을 기다립니다. 이 예시에서, Vercel Agent가 재배포를 제안하기 전에 조사는 별도의 읽기 전용 계획 하에 실행됩니다:
짧은 읽기 전용 조회는 계획 없이 실행될 수 있습니다. 더 긴 조사의 경우, Vercel Agent는 사용자가 자동으로 실행되는 동안 그 작업과 진행 상황을 추적할 수 있도록 읽기 전용 계획을 생성합니다.
이 계획은 사용자가 원하는 것과 Vercel Agent가 할 수 있는 것을 연결합니다:
저장된 각 계획은 작업과 진행 상황을 기록하며, 요청된 스코프가 각 작업에 첨부됩니다. 작업 설명은 왜 접근 권한이 필요한지 설명하고, 스코프는 전체 계획에 걸쳐 결합됩니다.
현재 읽기 전용 기본값(read-only baseline)에는 .으로 시작하는 모든 등록된 범위가 포함됩니다. 계획이 이 기본값을 초과하는 액세스를 요청하거나 GitHub 풀 리퀘스트 열기와 같은 지원되는 외부 작업을 포함하는 경우 승인이 필요합니다. 읽기 전용 작업이라도 민감한 정보를 노출할 수 있으므로, 자동 승인이 그 작업이 무해하다는 것을 의미하지는 않습니다.
Vercel Agent는 Vercel App으로 실행되며, 사용자가 팀 내에서 자신을 대신하여 행동하도록 권한을 부여합니다. 이 승인은 사용자의 기존 권한(user's existing permissions)에 의해 제한되므로, 계획을 승인한다고 해서 사용자가 가지고 있지 않은 액세스 권한이 주어지는 것은 아닙니다.
Vercel OAuth 서비스는 해당 승인을 특정 범위(scope)를 가진 수명이 짧은 토큰으로 교환합니다. 이 범위들은 배포판 읽기 또는 프로젝트 설정 변경과 같이 토큰이 허용하는 기능을 정의합니다. Vercel API는 이러한 제한을 강제하기 위해 요청마다 토큰을 확인합니다.
사용자는 수십 개의 프로젝트를 가진 팀에 대해 Vercel Agent에 권한을 부여할 수 있습니다. 재배포(redeploy) 계획은 배포 쓰기 액세스(deployment write access)를 요청합니다. 환경 변수 편집, 도메인 변경, 팀 멤버 관리 등 각각 고유의 권한이 필요합니다.
배포 쓰기 액세스는 단일 재배포보다 광범위합니다. 계획에서 배포 X라는 이름을 지정하는 것만으로는 토큰을 해당 배포로 제한하지 않습니다. Vercel Agent의 실행을 조정하는 소프트웨어인 런타임(runtime)은 승인된 자격 증명(credential)을 선택하기 전에 계획이 활성 상태인지 확인합니다. Vercel API는 각 요청을 해당 자격 증명의 권한과 비교하여 확인합니다.
사용자가 추가적인 Vercel 액세스가 필요한 계획을 승인할 때, 요청된 범위가 다시 확인되고 읽기 전용 기본값에 승인된 권한이 포함된 토큰이 준비됩니다. Vercel Agent의 실행을 조정하는 소프트웨어인 런타임은 승인된 자격 증명을 선택하기 전에 계획이 활성 상태인지 확인합니다. 이 자격 증명은 범위, 팀, 사용자의 권한 및 만료 기한의 적용을 받습니다.
사용되는 자격 증명은 작업에 따라 다릅니다:
모델의 지침은 언제 계획을 제안하고 승인을 요청해야 하는지 알려줍니다. 만약 토큰의 권한 범위를 벗어난 작업을 시도하면, 모델이 해당 동작이 작업 완료에 필수적이라고 판단하더라도 Vercel API가 요청을 거부합니다.
단일 계획에는 Vercel 변경 사항과 GitHub 풀 리퀘스트(pull request)가 포함될 수 있습니다. 사용자는 하나의 계획에서 이 두 가지를 모두 검토하지만, 각 제공업체는 별도의 권한 및 자격 증명을 사용합니다. GitHub 풀 리퀘스트 접근은 소유자(owner)와 저장소(repository)에 연결되므로, 사용자에게 다른 곳에도 접근 권한이 있더라도 특정 저장소에서 풀 리퀘스트를 열기 위한 승인은 해당 저장소에 적용됩니다. 그곳에서 풀 리퀘스트를 여는 것은 별도의 승인을 필요로 합니다. acme/storefront``acme/payments
제안된 계획은 이름이 변경되었거나 제거된 권한을 요청할 수 있습니다. 저희는 처음에 Vercel Agent를 위해 별도의 권한 목록을 유지했는데, 이는 토큰을 발급하는 OAuth 서비스와 동기화되지 않을 위험이 있었습니다. 따라서 이러한 불일치를 계획 단계에서 포착할 수 있도록 동일한 스코프 정의(scope definitions)로 전환했습니다.
세션 설정 시, Vercel Agent는 해당 정의들을 Vercel 스코프 레지스트리(scope registry)에서 인메모리 카탈로그(in-memory catalog)로 로드합니다. 레지스트리를 가져오려면 팀에 대한 승인이 필요하지만, 스코프 정의 자체는 팀 간 공유됩니다. 이 카탈로그는 세 단계에서 사용되는 정의를 제공합니다:
예를 들어, 업데이트 작업이 오래된 스코프를 요청할 수 있습니다. 시스템은 제안된 계획을 거부하고 유효한 스코프를 반환하여 Vercel Agent가 승인을 요청하기 전에 이를 수정할 수 있게 합니다. 이는 계획 단계에서 불일치를 포착하며, 더 광범위한 접근 방식으로 폴백(fallback)하는 대신 명시적인 수정이 필요하게 만듭니다.firewall rules
레지스트리를 가져오는 과정은 지연 시간(latency)과 서비스 의존성을 추가하므로, Vercel Agent는 카탈로그를 캐시하고 로드될 때 저장된 계획을 확인하는 데 이 복사본을 사용합니다. 이러한 확인 작업은 카탈로그가 레지스트리로부터 변경 사항으로 새로 고쳐질 때까지 캐시된 정의를 반영합니다.
Vercel Agent는 원래의 채팅 요청이 끝난 후에 승인을 받거나, 승인된 재배포(redeploy)를 수행하기 전에 연결을 잃을 수 있습니다. 저장된 계획(plan)에는 그 상태, 누가 승인했는지, 언제 승인했는지와 함께 작업 및 요청된 권한이 포함됩니다. 이 기록은 제안된 작업과 사용자가 승인한 접근 권한을 연결하며, 작업이 재개될 때 승인을 확인할 수 있게 합니다.
재개하기 전에 런타임(runtime)은 계획을 다시 로드하고, 승인된 권한을 가진 자격 증명(credential)을 선택하기 전에 해당 계획이 활성 상태인지 확인합니다. 중지된 계획은 토큰 만료까지 시간이 남아 있더라도 이 검사를 통과하지 못합니다.
승인 요청과 중지 요청이 동시에 도착하는 경우, 계획은 중지가 이미 상태를 변경하지 않은 경우에만 '승인을 기다리는(waiting for approval)' 상태에서 '활성(active)' 상태로 이동할 수 있습니다. 런타임은 그 후 승인된 자격 증명을 사용하기 전에 다시 한번 계획이 활성 상태인지 확인합니다.
조사 결과 현재 계획을 교체해야 한다는 것이 밝혀지면, Vercel Agent는 다른 계획을 제안할 수 있습니다. 높은 수준의 접근 권한(elevated access)을 요청하는 대체 계획은 자체적인 승인이 필요하며, 이를 통해 사용자는 수정된 작업과 권한을 함께 검토할 기회를 갖게 됩니다.
Vercel Agent가 플랫폼의 더 많은 영역에 도달함에 따라, 여러 리소스(resources)를 포함하거나 서로 다른 결과를 초래하는 작업에 대한 접근 규칙을 수정해야 했습니다. 도메인 연결에는 도메인 권한과 프로젝트 권한이 모두 필요할 수 있는 반면, 방화벽 규칙(firewall rule) 스테이징 및 게시에는 다른 수준의 접근 권한이 필요합니다. 스코프(Scopes)는 각 계획의 접근 요청을 관리 가능하게 유지하면서 이러한 차이점을 포착해야 합니다.
이러한 스코프를 제안된 수정 사항과 일치시키는 것은 계획 수립 전반에 걸쳐 주의를 요합니다:
적절한 권한을 가지고 있더라도, 재배포(redeploy)는 선택된 커밋(commit)이 배포하기에 안전한지에 대한 판단을 필요로 합니다. 이는 애플리케이션, 실패 내용, 그리고 제안된 수정 사항에 따라 달라집니다. 사용자는 선택을 평가할 충분한 정보가 필요하며, Vercel Agent 역시 이를 올바르게 실행해야 합니다.
읽기 전용(read-only) 조사 역시 민감한 프로젝트 구성 및 운영 세부 정보를 포함하여 검색하는 정보에 대한 통제가 필요합니다. 저희는 Vercel Agent가 승인을 요청하기 전에 조사할 수 있도록 읽기 전용 기본값(baseline)을 선택했으며, 범위(scope)와 노출되는 정보가 변경됨에 따라 이 선택은 지속적인 검토가 필요합니다. 다른 시스템은 더 좁은 기본값이 필요할 수 있습니다. 검색된 정보가 어떻게 처리되고 어디로 이동할지 여부는 별도의 통제가 관리해야 합니다.
Vercel Agent는 빌드 로그와 같은 읽은 콘텐츠에서 잘못된 결정을 내리거나 악의적인 지침을 접할 수 있습니다. 범위가 지정된 자격 증명(scoped credentials)은 어떤 작업을 수행할 수 있는지 제한하지만, 허용된 작업이라도 피해를 줄 수 있습니다. 따라서 플랜(Plans)은 샌드박스 격리(sandbox isolation), 네트워크 정책(network policy), 비밀 처리(secret handling), 속도 제한(rate limits), 감사 로그(audit logs), 서비스 승인(service authorization)과 함께 작동합니다. 저희의 작업은 에이전트, 자격 증명, 실행 코드를 분리하는 방법을 설명합니다.security boundaries in agentic architectures
권한(Authority)은 그것을 필요로 했던 작업에 붙어 있습니다. 런타임(runtime)은 활성 플랜에 대한 승인된 자격 증명을 선택하며, 그 범위는 Vercel Agent가 수행할 수 있는 작업을 정의합니다. 조사가 이미 완료되었으므로, 사용자는 제안된 수정 사항과 요청된 접근 권한을 함께 평가할 수 있습니다.
프로젝트의 문제를 조사하기 위해 필요한 경우에 이를 활용하세요. 에이전트가 발견한 내용을 검토하고, 변경 사항을 제안하는 경우 플랜과 요청된 접근 권한을 승인하기 전에 평가하십시오.Vercel Agent 사용해 보기
더 읽어보기
플랜이 권한을 결정합니다
Vercel Agent는 사용자가 이미 가진 권한만 사용할 수 있습니다
승인이 Vercel Agent가 사용할 수 있는 권한을 결정합니다
플랜과 토큰은 동일한 권한 정의를 사용합니다
작업을 재개하려면 활성 상태이고 승인된 플랜이 필요합니다
권한이 더 정밀하게 필요한 경우
조사에서 승인된 조치로
| 플랜 |
작업
요청된 범위(Requested scope)
| 작업 | 권한/범위 |
|---|
| 실패 조사하기 (Investigate the failure) | 최근 배포 및 빌드 로그를 검사하고, 실패한 배포와 마지막 성공적인 배포를 비교합니다. |
read:deployment | |
알려진 최적의 빌드를 재배포하기 (Redeploy the last known-good build) | 배포 생성하기 | read-write:deployment |
| 작업 (Work) | 자격 증명 (Credential) |
|---|
| 읽기 전용 조사(Read-only investigation) | 읽기 전용 범위의 기본 토큰(A baseline token with read-only scopes) |
| 승인된 Vercel 변경 사항(Approved Vercel changes) | 기본 범위에 승인된 추가 범위를 더한 토큰(A token with baseline scopes plus the approved additional scopes) |
| 외부 작업(External actions) | 해당 제공업체(provider)에 특화된 자격 증명 및 권한(Credentials and permissions specific to that provider) |
-
: 사용자 요청 결과: 의도(Intent)
-
: Vercel Agent가 이를 달성하기 위해 제안하는 작업: 작업(Work)
-
: 해당 작업에 필요한 범위/권한: 접근(Access)
-
: 접근 제한을 강제하는 자격 증명 및 API 검사: 강제(Enforcement)
-
: 요청된 범위는 정규화되며, 계획이 저장되거나 승인을 위해 제시되기 전에 알 수 없거나 잘못된 이름은 거부됩니다: 계획 검증(Plan validation)
-
: 요청된 범위는 계획이 읽기 전용 기본 범위 내에 속하는지 또는 추가 접근이 필요한지를 결정합니다: 승인(Approval)
-
: 유효한 범위는 승인된 작업을 위한 자격 증명을 정의합니다: 토큰 준비(Token preparation)
-
: Vercel Agent는 불완전한 정보로 스코프를 선택할 수 있어, 너무 적은 접근 권한을 요청하여 작업을 막히게 하거나, 혹은 필요 이상의 권한을 부여하는 등 과도하게 많은 권한을 부여할 수 있습니다. 작업 수준의 안내(Task-level guidance)가 선택을 돕고, 유효성 검사(validation)는 잘못된 스코프 이름을 잡아냅니다. 심지어 유효한 스코프라도 필요한 것보다 더 광범위한 접근 권한을 부여할 수 있습니다.스코프 선택 (Choosing scopes)
-
: “마지막 성공 빌드 재배포(Redeploy the last successful build)”는 사용자에게 평가할 수 있는 구체적인 조치를 제공하는 반면, 스코프 이름만으로는 사용자가 그 결과를 스스로 파악해야 합니다. 계획은 의도된 변경 사항을 설명하고 토큰이 실제로 제한하는 것이 무엇인지 명확히 해야 합니다.작업 설명 (Describing the work)
-
: 거부된 작업(denied operation)은 누락된 스코프, 잘못된 리소스(resource), 또는 계속 차단되어야 하는 작업을 나타낼 수 있습니다. Vercel Agent는 추가 권한을 요청하기 전에 이러한 경우들을 구분할 필요가 있습니다.거부 이해 (Understanding denials)