에이전트에 자체 작업 공간(workspace) 식별자를 부여하고, 해당 식별자에 월간 예산을 할당한 다음, tx (거래별) 창을 원하는 건당 최대 결제 금액으로 설정하는 금액 규칙(amount rule)을 추가합니다. 그러면 규칙 평가 엔진(rule evaluation engine)이 어떤 지급 요청이든 실제로 처리되기 전에 예산과 규칙에 대해 확인하고, '예/아니오' 추측 대신 allowed, blocked, 또는 pending_human 중 하나를 반환합니다. 아래에서는 실제 정책 엔진(Pink Agentic AI Payments의 공개 샌드박스)을 사용하여 전체 과정을 안내하므로 다이어그램이 아닌 실제 요청 및 응답 본문을 확인할 수 있습니다.
한도 설정 계층 구조 (How the limits are layered)
Pink는 무언가를 발행하기 전에 다음 순서로 세 가지 종류의 한도를 확인합니다: 회사 차단기(company breakers) (에이전트 일시 중지, 에이전트 월간 예산 소진, 회사 전체 일일 상한선 도달, 금고 잔액), 그 다음 규칙 목록을 위에서 아래로 순서대로 검사하며, 첫 번째 일치하는 것이 승리합니다. 기본값은 차단(block)입니다. 규칙에는 금액 범위와 창(window)이 포함됩니다: tx (이번 결제만), day 또는 month (누적 합계). 건당 최대 결제 한도는 window: "tx"인 규칙입니다. 아래 단계에서는 이를 설정하고 실행합니다.
1단계: 샌드박스 작업 공간 생성 (Step 1: create a sandbox workspace)
가입 양식 없이 POST 요청만으로 가능합니다. 이 요청은 회사 대시보드를 위한 관리자 키(admin key)와 시드된 각 에이전트별 API 키를 반환합니다.
curl -X POST https://agentic-sandbox.pinkwallet.com/v1/sandbox/workspaces \
-H 'content-type: application/json' \
-d '{"company":"Acme Procurement Test","email":"[email protected]","template":"coffee"}'
응답에는 workspace_id, admin_key와 함께 에이전트 목록이 포함되며, 각 에이전트는 자체 키와 MCP URL을 가집니다. 예를 들어 https://agentic-sandbox.pinkwallet.com/mcp/<agent_key> 형태입니다. "coffee" 템플릿은 시작 예산과 결제 대상자(payee)가 설정된 네 개의 에이전트(구매, 재고, 마케팅, 급여 및 청구서)를 시드하므로 수동으로 더미 데이터를 구축할 필요가 없습니다.
2단계: 에이전트에 월간 예산 할당 (Step 2: give the agent a monthly budget)
모든 에이전트는 이미 monthly 예산 필드를 가지고 있습니다. 관리자 측에서 이를 증액하거나 감액할 수 있습니다:
에이전트가 자체적으로 확인하는 예산(budget)을 통해 해당 숫자가 실시간으로 적용됨을 확인할 수 있습니다:
{
"agent": "Purchasing AI",
"monthly_budget": 3000,
...
}
응답에는 single_payment_cap 필드도 표시됩니다. 현재의 sandbox 환경에서는 엔진이 결제를 결정할 때 이 필드를 확인하지 않으므로, 다음 단계와 같이 규칙을 사용하여 개별 결제 한도를 설정해야 합니다.
3단계: 창(window)을 "tx"로 하는 개별 결제 금액 규칙 추가
정책은 위에서 아래로 평가되는 규칙 목록이며, 첫 번째 일치하는 규칙이 승리하고 기본값은 차단(block)입니다. 엄격한 개별 결제 한도를 설정하려면 window: "tx"를 사용하고 월간 또는 일일 누적액 없이 오직 단일 거래 금액만 지정하는 규칙을 추가해야 합니다:
curl -X PUT https://agentic-sandbox.pinkwallet.com/v1/admin/rules \
-H "Authorization: Bearer $ADMIN_KEY" -H 'content-type: application/json' \
-d '{
...
이 규칙은 다른 방식으로 동일한 수취인(payee)과 에이전트에 대해 더 큰 금액을 허용하는 모든 규칙보다 앞에 위치해야 합니다. 왜냐하면 엔진은 첫 번째 일치 항목에서 멈추기 때문입니다. 배열의 맨 앞에 배치함으로써 이를 달성할 수 있습니다.
4단계: 한도 이내 결제 시도
REST를 통해 (동일한 호출이 MCP 도구인 pink.check_policy와 pink.request_payment로 노출되어 클라이언트가 MCP를 통해 연결하는 경우):
curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
-H "Authorization: Bearer $AGENT_KEY" -H 'content-type: application/json' \
-d '{"payee_id":"p_sysco","amount":120,"currency":"USD","purpose":"Weekly milk and syrup reorder"}'
이 sandbox 실행의 실제 응답:
{
"payment_id": "pay_bb13deacc29e",
"decision": "allowed",
...
}
$120은 $150 한도보다 낮기 때문에, 새로운 차단 규칙은 건너뛰고 대신 $500 미만의 승인된 공급업체에 대한 이전 허용 규칙이 일치합니다. 정확히 $120에 대해 단일 사용 가상 카드 번호가 발급됩니다.
5단계: 한도 초과 결제 시도
동일한 에이전트, 동일한 수취인, 더 큰 금액:
curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
-H "Authorization: Bearer $AGENT_KEY" -H 'content-type: application/json' \
-d '{"payee_id":"p_sysco","amount":300,"currency":"USD","purpose":"Large milk and syrup reorder"}'
응답:
{
"payment_id": "pay_f0e7f8427aea",
"decision": "blocked",
...
$300은 에이전트의 월별 예산(남은 금액 $740) 내에 충분히 포함되며, 금고 잔액에도 충분히 포함됩니다. 이는 어떠한 허용 규칙도 작동할 기회조차 갖기 전에 거래별 규칙(per-transaction rule)과 일치했기 때문에 순수하게 차단된 것입니다. 어떤 자격 증명도 발급되지 않습니다. 건식 실행 엔드포인트인 pink.check_policy / POST /v1/payments/check는 아무것도 지출하지 않으면서, 단계별 전체 추적(full trace)과 함께 동일한 결정을 반환하며, 이는 에이전트(또는 사람)에게 결제가 실패하는 이유를 보여주고 싶을 때 유용합니다.
세 번째 결과: 인간의 승인을 기다림 (held for a human)
동일한 규칙 세트는 또한 에이전트가 금액과 관계없이 승인된 목록에 없는 수취인에게 지불하려고 시도할 때 사람의 승인을 요청하는 규칙을 포함합니다:
{
"decision": "pending_human",
"amount": 50,
...
에이전트(또는 이를 구동하는 MCP 클라이언트)는 사람이 승인하거나 거부할 때까지 해당 대기 상태를 폴링합니다. 이는 허용(allowed)과 차단(blocked) 다음의 세 번째 결정 유형으로, 결제가 실행되거나 거부되는 것이 아니라 '대기'합니다.
Pink Agentic AI Payments는 결제가 실행되기 전에 MCP 계층에서 각 에이전트의 예산 및 금액 규칙을 확인합니다.
다른 접근 방식은 무엇이 있습니까
- Stripe의 에이전트 도구(agent tooling): Stripe은 MCP 서버와 Stripe Issuing을 기반으로 구축된 'Agents' 인터페이스(
docs.stripe.com/agents)를 공개합니다. 여기서는 지출 통제 기능(카드별 한도, 실시간 승인, 제한된 API 키)이 카드 승인 시 Stripe Issuing에 의해 강제됩니다. 이미 Stripe Issuing을 사용하고 있다면, 이는 합리적인 시작점이 될 수 있습니다. docs.stripe.com/agents와 docs.stripe.com/mcp를 참고하세요.
- x402 (Coinbase): 서버가 계정이나 API 키 없이도 EVM 호환 체인 또는 Solana에서 스테이블코인으로 결제를 요청할 수 있도록 HTTP 402 상태 코드를 사용하는 프로토콜입니다. 이는 에이전트별 회사 정의 예산보다는 요청당 마이크로결제에 중점을 두고 구축되었습니다. 지출 한도는 기본 사양에 포함되어 있지 않습니다. x402.org를 참고하세요.
- AP2 (Google): 현재 사양 버전 0.2인 Agent2Agent (A2A)의 개방형 프로토콜 확장입니다. 이는 인간이나 정책이 에이전트가 구매할 수 있는 범위를 제한하기 위해 발행할 수 있는 '위임(mandates)'(암호화 서명된 승인 객체)를 정의합니다. 이는 당사자들이 서로 소통하는 방법에 대한 사양이며, 호출하는 호스팅 결제 제품은 아닙니다. ap2-protocol.org를 참고하세요.
만약 사용 사례가 “하나의 AI 클라이언트가 MCP를 통해 한 번 연결하고, 무언가가 발행되기 전에 에이전트별 예산과 결제당 규칙을 서버 측에서 강제하는 것”이라면, 이 가이드가 다루는 내용입니다. 오늘 스테이블코인으로 실시간 정산이 필요하거나 이미 Stripe Issuing에 깊이 관여하고 있다면, 위에 있는 두 링크를 직접 읽어보는 것이 좋습니다.
시도해 보기
위의 샌드박스(sandbox)는 가짜 돈과 시드된 템플릿을 사용하며, 작업 공간을 생성하는 데 카드나 은행 정보가 필요하지 않습니다. 전체 흐름을 체험해 보세요: agentic-sandbox.pinkwallet.com. 개발자 문서는 다음과 같습니다: pinkwallet.com/agentic/developers. 프로덕션(production) 환경에서는 Pink가 의사 결정 계층(decision layer)으로 작동합니다. 에이전트가 먼저 Pink에게 요청하고, Pink가 허용할 경우에만 사용자의 자체 Stripe, 카드 또는 은행에서 결제됩니다. Pink는 절대 사용자의 돈을 보유하거나 이동시키지 않습니다. 자체 프로덕션 테넌트(production tenant)에서의 파일럿 프로그램은 월 $99이며, 매월 결제 방식이고 첫 달 요금은 30일 이내에 환불 가능합니다: pinkwallet.com/agentic/pilot.