누가 귀하의 API를 호출하는지 이해하세요.
모든 API 요청에 행위자 컨텍스트를 추가하세요. 어떤 클라이언트가 호출하는지, 증거가 얼마나 강한지, 그리고 API가 라우트별로 어떻게 대응해야 하는지까지 포함합니다.
POST /api/v1/orders
증거
브라우저 컨텍스트가 없고 자동화된 요청 패턴을 가진 API 키 트래픽
귀하의 policy: 주문을 생성하기 전에 더 강한 credential을 요청
API 키는 신원이 아니며, 신원도 권한이 아닙니다.
대부분의 API 트래픽은 어느 계정이 비용을 지불하는지 말해 주는 자격 증명과 함께 도착하며, 어떤 클라이언트가 호출하는지나 누가 지시했는지는 알려 주지 않습니다. 일부 클라이언트는 요청에 서명하지만, 많은 클라이언트는 이름만 선언하고, 많은 경우 아무것도 말하지 않습니다.
Proof of Actor는 모든 API가 답해야 하는 세 가지 질문을 분리하여, 각 질문에 맞는 evidence와 control이 적용되도록 합니다.
- 누가 호출하고 있나요?행위자 신원: 서명, 선언 또는 추론
- 어떤 자격 증명인가요?귀하의 API key, OAuth token 또는 session
- 무엇을 할 수 있나요?귀하의 authorization and policy
Proof of Actor는 첫 번째 질문에 답합니다. 나머지 두 가지는 고객의 stack이 유지합니다.
API 팀이 actor 문맥으로 하는 일
서명된 클라이언트 식별
게시된 키와 요청 서명을 대조하고, 해당 요청이 어느 운영자에 속하는지 확인하세요.
선언은 선언으로 취급
자가 선언한 클라이언트 이름을 기록하고, 검증된 신원과 분리해서 보관하세요.
route별 policy
영향이 낮은 읽기는 자유롭게 허용하고, 쓰기 작업과 영향이 큰 엔드포인트에서는 추가 확인을 요청하세요.
모든 호출자 보기
어떤 클라이언트가 어떤 endpoint를 사용하는지, Unknown인 것까지 포함해 이해하세요.
자격 증명을 분리 유지
API 키와 OAuth가 여전히 접근을 결정합니다. 행위자 맥락은 누가 호출하는지 추가합니다.
Unknown에 대한 계획
호출자가 사용할 수 있는 증거를 제공하지 않을 때 경로별로 어떻게 처리할지 정의합니다.
01 · 감지
모든 요청의 증거입니다.
서버, 엣지 및 HTTP API 통합은 요청 서명, 선언된 클라이언트 세부 정보, 요청 컨텍스트를 읽고 각 항목에 근거를 표시합니다.
- 공개된 키와 대조해 검증된 HTTP 메시지 서명.
- 선언으로 기록된 클라이언트 이름입니다.
- 서버, 게이트웨이 또는 edge에서 요청 컨텍스트를 수집합니다.
- 요청 서명valid · sample-crawler.exampleverified
- 클라이언트 선언"research-assistant/2.1"declared
- 브라우저 상호작용pointer + keyboard eventsinferred
- 지원되는 신호 없음route not instrumentedunknown
02 · 이해
누가 어떤 endpoint를 사용하는지 파악하세요.
각 라우트의 액터 구성을 확인하고, 어떤 운영자가 가장 많이 호출하는지와 알 수 없는 호출자가 어디에 집중되는지 보세요.
- 경로와 운영자별 호출자.
- 모든 분류의 근거.
- endpoint별 Unknown 비율입니다.
- /dashboard알 수 없음 7%
- /api/v1/catalog알 수 없음 15%
- /support/tickets알 수 없음 8%
- /signup알 수 없음 21%
03 · 라우팅
영향에 맞는 제어
경로 수준 정책을 작성하세요. Verified agent에는 구조화된 응답, Declared 클라이언트에는 표준 한도, 고영향 작업에는 더 강한 자격 증명을 적용합니다.
- route, class 및 basis별 policy.
- 중요할 때 더 강한 자격 증명으로 전환하세요.
- 관찰하고, 미리 보고, 그 다음 강제 적용하세요.
- /api/v1/catalogenforce에이전트허용 · 구조화된 API
- /support/ticketsenforce사람 + AI허용 · AI-assisted로 표시
- /account/*preview알 수 없음기존 검사를 유지
- /api/v1/orderspreview에이전트더 강한 자격 증명 요구
예시 결정
request에서 result를 거쳐 귀하의 decision까지.
검증된 agent가 카탈로그를 읽음
요청
GET /api/v1/catalog
결과
에이전트basis: verified귀하의 결정
agent rate limit과 구조화된 응답으로 허용하세요.
자동화된 클라이언트가 주문을 제출합니다
요청
POST /api/v1/orders
결과
에이전트basis: inferred귀하의 결정
주문을 생성하기 전에 앱의 더 강한 credential을 요청하세요.
근거가 없는 클라이언트
요청
GET /api/v1/catalog
결과
알 수 없음basis: unknown귀하의 결정
read-only route: 기본 rate limit으로 allow.
위험 없이 출시
팀은 관찰 모드로 시작해 경로별로 진행합니다.
- 01
모든 route를 관찰
API 앞에 미들웨어 또는 HTTP API를 추가하세요. 서명, 선언 및 Unknown 호출자는 route별로 기록됩니다.
- 02
route 정책 미리보기
agent rate limit 또는 step-up credential이 실제 traffic에 대해 무엇을 했을지, 적용되기 전에 확인하세요.
- 03
영향도에 따라 적용
읽기 작업은 열어 두고, 쓰기 작업은 더 엄격하게 관리하며, 접근 제어는 API keys와 OAuth가 맡도록 하세요.
현재 스택과 함께 작동
- 초기 팀
웹 서버 미들웨어 (Node.js)
서버 측
서버 렌더링 앱과 APIs를 위한 요청 수준 신호.
- 초기 팀
Next.js
서버 측 및 엣지
페이지와 API 라우트를 위한 미들웨어.
- 초기 팀
브라우저 스크립트
브라우저 신호만
서버 측 통합과 함께 브라우저 세션에서 수집되는 상호작용 신호입니다.
- 초기 팀
Cloudflare 및 edge runtime
Edge
요청이 원본 서버에 도달하기 전 엣지에서 신호를 수집합니다.
- 초기 팀
범용 HTTP API
모든 스택
요청 컨텍스트를 API에 보내고 근거가 포함된 결과를 받으세요.
- 초기 팀
MCP 서버
MCP
MCP 도구 호출을 위한 행위자 컨텍스트.
- 로드맵
WordPress
플러그인
WordPress 사이트용 plugin.
- 로드맵
기본 모바일
iOS 및 Android
기본 iOS 및 Android SDK.
온보딩 동안 각 창립 팀과 함께 실습 방식으로 통합을 제공합니다. 다른 스택을 사용하시나요? 지원할 때 알려주세요.
자주 묻는 질문
클라이언트가 요청에 서명해야 하나요?
아니요. 서명된 요청이 가장 강한 증거를 제공하지만, Proof of Actor는 선언과 추론도 기록하며 각각 근거를 라벨링하고, 충분하지 않을 때는 Unknown으로 보고합니다.
유효한 서명이 클라이언트의 행동 허용을 의미하나요?
아니요. 요청이 공개된 식별자에 연결된 키로 서명되었음을 보여 줍니다. 그 운영자가 무엇을 할 수 있는지는 귀하의 권한 부여와 정책이 결정합니다.
API 키나 OAuth를 대체하나요?
아니요. 자격 증명이 여전히 접근을 제어합니다. Proof of Actor는 누가 또는 무엇이 호출하는지를 추가해 주어, 그 위에 더 나은 정책을 적용할 수 있습니다.
endpoint별로 다른 규칙을 설정할 수 있나요?
네. 정책은 경로별로 작성되므로, 읽기 전용 endpoint와 고영향 쓰기는 다르게 처리할 수 있습니다.
비용은 얼마인가요?
선정된 창립 개발자 팀은 합의된 사용 한도 내에서 최대 12개월 무료로 이용할 수 있습니다.