본문으로 건너뛰기
Ultari
발표 모드Slack에서 체험하기 (새 탭에서 열림)

PURCHASING FLEET FOR AI SPEND

LLM은 요청하고,Agent는 정책 안에서지불합니다

Ultari는 조직의 AI 구매를 위한 purchasing fleet입니다. 각 Agent에 예산과 수취인 정책을 부여하고, 요청자 기록과 온체인 payer를 구분해 남깁니다.

  • Agent별 지출 경계
  • 결정론 정책 평가
  • 온체인 지출 한도

01 · 문제

AI가 구매하는 속도에 지출 통제가 따라오지 못합니다

구매 요청은 자동화됐지만 결제 수단은 여전히 공유 키, 개인 선결제, 수동 승인에 머물러 있습니다. Ultari는 지출 신원과 요청자 기록을 처음부터 분리합니다.

SHARED CREDENTIAL

하나의 키로는 책임을 나눌 수 없습니다

여러 LLM과 자동화가 같은 결제 수단을 공유하면, 어떤 Agent가 얼마를 쓸 수 있는지 구분하기 어렵습니다.

Agent별 권한 경계 필요

PERSONAL PREPAY

개인 결제는 조직의 맥락을 잃습니다

개인 지갑이나 카드로 먼저 결제하면 요청 이유, 조직 정책, 실제 payer가 서로 다른 기록에 남습니다.

요청과 결제 근거 분리

MANUAL APPROVAL

모든 요청을 사람이 보면 자동화가 멈춥니다

반복 구매와 예외 구매를 같은 승인 절차로 처리하면, 검토할 일은 늘고 중요한 예외는 묻힙니다.

상시 정책과 JIT 예외 분리

02 · PURCHASING FLEET

LLM이 바뀌어도, Agent의 지출 경계는 남습니다

Agent는 지속적인 wallet spending identity입니다. 모델이나 런타임이 아니라, 자기 vault와 정책을 가진 조직의 지불 단위입니다.

AGENT지속적인 wallet spending identity

자기 vault와 예산, 수취인 정책을 가진 지불 주체입니다. 결제에서는 Agent vault가 온체인 payer로 나타납니다.

LLM구매를 요청하는 model/runtime

LLM과 자동화 세션은 구매를 요청하지만 지불 신원은 아닙니다. 모델을 교체해도 Agent의 예산과 정책은 별도로 유지됩니다.

Agent = persistent wallet spending identity · LLM = model/runtime

research-01vault 1
3.20USDC available
1.80 / 5.00 · 일

수취인 · serpapi.com · tavily.com

ops-01vault 2
27.60USDC available
12.40 / 40.00 · 주

수취인 · 등록 수취인 3곳

growth-01vault 3TTL
42.00USDC available
58.00 / 100.00 · 월

수취인 · apify.com

예시 fleet · 별도 vault의 정책과 지출 상태는 서로 섞이지 않습니다.

03 · 아키텍처

요청부터 결제까지, 누가 무엇을 집행하는지 보입니다

Member 확인, 정책 평가, 온체인 한도, 결제 증거가 한 경로에 있지만 같은 역할은 아닙니다. 각 단계의 집행 주체를 분명히 나눕니다.

REQUEST신원
MemberSlack verificationGoogle OAuth · CLI/console
MERCHANTx402
merchant · challengeresource 요청402 요구값 제시
SIGNER정책
signer · policy최소충분 Agent 선택결정론 정책 평가
PAYER온체인
Agent vault금액 · 기간 · 수취인지원 한도 온체인 집행
EVIDENCE구분
evidence surfacesmerchant 재요청 · 정산온체인 tx · authorization
온체인Solana가 지원 한도 집행정책signer가 authorization 집행인프라Cloud KMS · GCP IAM기록관측값은 enforcer가 아님

04 · SLACK 플로우

팀은 이미 일하는 곳에서 요청합니다

Slack adapter는 서명된 요청과 허용된 Workspace를 확인하고, 사용자를 안정적인 Member ID로 변환한 뒤 같은 fleet contract를 호출합니다.

01
Slack 요청 검증

Slack signature와 허용된 Workspace를 먼저 확인합니다.

02
Member로 연결

채널 사용자를 조직의 안정적인 Member ID로 변환합니다.

03
같은 fleet 조회

paired BYOC signer에서 active Agent를 읽어 일관된 순서로 보여줍니다.

05 · 정책 · JIT

일상 구매는 정책으로, 예외는 결제 한 건만

허용 범위 안의 구매는 standing policy로 처리하고, 범위를 벗어난 요청은 Member · Agent · 금액 · 수취인 · 만료가 고정된 JIT 승인으로 보냅니다.

Standing policyresearch-01 · example
limit.amount일 5.00 USDC온체인
recipient owners7xQ4…8mAe · 9Vz1…2cKo온체인
policy.ttl정책 만료 시각signer

결제 시 signer는 결정론 정책으로 요청을 평가하고, 지원되는 금액·기간·수취인 제약은 Agent vault 경로에서 집행됩니다.

JIT requestexact request
Member · Agentmember_7f… · research-01
amount정확히 12.00 USDC
recipientserpapi.com · 7xQ4…8mAe
expiry · use30분 · remaining use 1

Owner 권한은 승인할 때 서버에서 다시 평가됩니다. caller가 보낸 role이나 Agent hint는 authority가 아닙니다.

06 · 증거 모델

한 결제에서 payer와 요청자를 각각 확인합니다

온체인에는 Agent vault가 payer로 남고, signer 기록에는 인증된 Member와 요청 채널, 적용된 정책이 남습니다. 사람을 온체인 payer로 포장하지 않습니다.

온체인에서 확인하는 것온체인
payerAgent vault
payment금액 · 수취인 · transaction
policy state지원되는 allowance 상태

체인은 사람의 Workspace 또는 Slack identity를 나타내지 않습니다.

signer가 검증하는 것authorization
requesterstable Member ID · identity snapshot
sourceCLI · localhost web · Slack adapter
selectionselected Agent · policy verdict

요청자 attribution은 Agent payer와 별도입니다. 관측 기록 자체는 지출 한도를 집행하지 않습니다.

SAS attestation은 닫힌 expense-record commitment를 증명할 수 있지만 KYC, merchant invoice, tax invoice 또는 법정 영수증을 대신하지 않습니다.

07 · 신뢰 모델

보안 주장이 아니라 집행 주체를 보여드립니다

Solana, signer policy, Cloud KMS, GCP IAM이 맡는 경계와 남는 신뢰 전제를 구분합니다. 관측 로그는 집행 수단으로 표현하지 않습니다.

온체인

Squads vault 규칙

지원되는 금액 · 기간 · 수취인 allowance를 Solana 프로그램이 집행합니다.

전제 · Solana 합의와 배포된 프로그램

정책

signer policy

Member authorization, 최소충분 Agent 선택, standing policy와 JIT request 권한을 signer가 평가합니다.

전제 · Ultari signer와 서버 상태

인프라

Cloud KMS

Agent의 software EC_SIGN_ED25519 key로 서명을 실행하며 private key material을 애플리케이션에 반환하지 않습니다.

전제 · Google Cloud KMS

인프라

GCP IAM · Deny

production preflight는 key-level signer role과 effective IAM Deny가 useToSign 주체를 signer runtime으로 제한하는지 검증합니다.

전제 · 조직 IAM/Deny 관리자

관측 로그는 enforcer가 아닙니다. GCP 조직 관리자와 IAM/Deny 관리자는 cloud trust boundary에 남습니다.

08 · 데모 merchant

가상 데이터, 실제 결제 경로

DEMO MERCHANT

Ultari는 데이터 공급자가 아닙니다

공개 merchant는 여러 구매 상황을 보여주기 위해 결정론적인 synthetic 데이터를 판매합니다. 실제 가격, 위험평가 또는 예약 가능성을 주장하지 않습니다.

응답 표기 · synthetic: true · 고정 asOf

LIVE PAYMENT

결제와 devnet 정산은 실제 경로입니다

402 challenge, signer가 발급한 PAYMENT-SIGNATURE, wallet-agnostic Path 2 verify와 settle, PAYMENT-RESPONSE 반환은 공개 devnet 경로에서 실행됩니다.

측정 범위 · Solana devnet

REAL-WORLD ADOPTION

실제 merchant에는 Path 2 호환이 필요합니다

Production merchant와 facilitator는 x402 v2 exact-SVM smart-wallet payment를 verify하고 settle할 수 있어야 합니다. merchant가 payer의 vault 구조를 알 필요는 없습니다.

third-party 호환성 · controlled payment로 검증

구매 가능한 synthetic scenariocatalog ↗ (새 탭에서 열림)
RPC · indexer 조달/demo/solana-infrastructure
수취인 · domain screening/demo/merchant-risk
SaaS quote 비교/demo/saas-procurement
휴지 · 생수 · 키보드 · 마우스 · MacBook/demo/office-supplies
출장 옵션 비교/demo/business-travel

현재 공개 데모는 Ultari의 x402 processor를 사용합니다. 설치된 pay-kit과 Kit 7 graph의 통합 제약은 Path 2 결제 자체의 실패를 뜻하지 않으며, 외부 merchant 호환성은 개별 facilitator를 통한 결제로 확인해야 합니다.

09 · 인터페이스

Slack, CLI, Console이 같은 fleet를 사용합니다

접점마다 인증 방식은 달라도 Agent 선택, 정책 평가, 결제 증거의 계약은 공유합니다. 요청 채널이 지출 권한을 새로 만들지는 않습니다.

Slack

/ultari agentsResearch (research-01)
5.00 USDC / day

Slack signature와 workspace Member 검증 뒤 paired BYOC signer의 active fleet을 읽습니다.

CLI

$ ultari purchase \  --url https://merchant.ultari.xyz/research/... \  --agent research-01

Google OAuth session으로 x402 resource를 요청합니다. Agent 인자는 authority가 아닌 hint입니다.

Console

Console presentation은 fleet, policy, Owner transaction, JIT approval 상태를 구분해 보여줍니다.

10 · 시작하기

Slack에서 Ultari의 구매 흐름을 확인하세요

공개 Slack에서 purchasing fleet를 살펴보거나 GitHub에서 구현과 경계를 확인할 수 있습니다.

Agent = wallet spending identity · LLM = model/runtime