Shuka

io.github.cdonoyan由 GitHub 账号 cdonoyan 发布v2.2.0更新于 Oct 29, 2026

Universal trust attestation for AI agents: create, verify, and negotiate Shuka trust proofs.

概览

AI 生成的概览

Shuka 让助手创建、验证和协商加密信任凭证,并可浏览和购买以 shake 为锚的许可。

可以做什么
  • 创建、查询和验证幂等 shake 与凭证,并校验 proof token
  • 进行代理间信任协商,获得是否继续的建议
  • 浏览、签发、购买和撤销许可报价与授权,并对照账本验证授权
  • 管理 shake 上的条款:创建、修订、撤销、记录访问,并以签名裁决检查访问
  • 查询注册表账本历史、发现注册表,并检查签发与接受的互操作性
  • 浏览企业按席位许可报价(购买功能尚未实现)
适用场景
当助手需要为数据或实体提供可验证的证明、在依据其他代理提供的数据行动前核验其凭证,或参与以已证明权利为锚的许可市场时使用。适合处理合规、同意或数据交换流程的合作方组织。
运行要求
通过 npm 包的 npx 以 stdio 在本地运行。需要已验证的合作方账户,并在 SHUKA_API_KEY 中提供 SDK 密钥;验证类工具无需密钥。SHUKA_API_URL 可选,用于设置 API 基础地址。需要能访问 Shuka API 的网络。
安装前请注意
SDK 密钥是带有 license:write、transaction:write 等范围权限的合作方凭证,请勿写入日志或提示词。注册 shake、信任协商和读取投资组合均按次计费且无免费额度,购买许可会产生实际支出。工具会写入只追加账本、签发和撤销授权,并修订或撤销条款。凭证文本与元数据会发送到 Shuka 的服务器。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Shuka,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

@shukashake/agent

Universal Trust Guardian for AI Agents

The Shuka Shake is the trust layer for moving protected data in the AI economy. It doesn't own what's inside - it guards the exchange, respects confidentiality, and enforces terms without ever touching the metadata within.

This package is your agent's membership to the yacht club - where trust is negotiated, proof tokens are exchanged, and data flows with respect for rights.

v2.1.0 — Everything is a Shuka Shake. This is the canonical One Ring package: one SDK and one MCP server uniting attestation, the rules layer, the shake-anchored license marketplace, enterprise licensing, and the registry ledger. The full flow:

shake → terms (rules layer) → license offering → grant → registry proof
  1. Shake — create an idempotent Shuka Shake for any entity (same input, same shake, forever)
  2. Terms — attach modifiable rules to the immutable handshake
  3. Offering — issue a license offering anchored to the shake
  4. Grant — purchase the offering; receive a grant with its own proof token
  5. Registry proof — verify the grant and its full ledger chain, publicly

⚠️ Partner Access Required

This SDK requires a verified partner account and an SDK key.

Authentication is SDK-key-only: every authenticated operation uses your SDK key (sent as X-SDK-API-Key). Most operations route through Shuka's /api/sdk/v1/* surface; verification and trust-negotiation use the public /api/shake/* and /api/handshake/* endpoints (verification is free and needs no key). Agents and developers never handle JWTs or raw platform API keys. Scoped permissions (e.g. license:read, license:write, transaction:write) are attached to the key at issuance.

You can install this package, but it will not function without an authorized SDK key issued by Auron.

To become a partner:

Once approved, you'll receive API credentials to activate the SDK.

Attribution model: the key's user binding IS the attribution. Every shake this SDK mints is owned by the partner user your key is assigned to (user_id / partner_id) and stamped with the minting key (api_key_id). Per-end-user attribution inside your app is your client reference (the id field on attest calls), which lands in the idempotency namespace and handshake_metadata. Agent identity (X-Agent-Id / X-Agent-Type) is recorded as labeled-untrusted asserted_agent metadata for audit — it never sets ownership. If your key is unassigned, creations degrade to anonymous ("access": "public"); claim the key via POST /api/sdk/v1/partner/keys/claim.


What is Shuka?

Shuka provides cryptographically verified trust handshakes for AI-to-AI and AI-to-human data transfers. Every exchange is attested, auditable, and verifiable.

Use cases:

  • Healthcare ROI (Release of Information) management
  • Construction contractor/permit verification
  • Cross-jurisdiction compliance attestation
  • Data portability between enterprise systems
  • AI agent verification and trust negotiation

The Shuka Shake is:

  • Schema-agnostic - any data format works
  • Industry-agnostic - healthcare, construction, finance, legal, government
  • Jurisdiction-agnostic - works across borders and regulatory frameworks

Install

bash
npm install @shukashake/agent

Quick Start

javascript
const { ShukaSDK } = require('@shukashake/agent');
const shuka = new ShukaSDK({  apiKey: process.env.SHUKA_API_KEY  // your SDK key});
// Create an attestation (the Shuka Shake)const result = await shuka.attest(  'Patient John Doe consents to release records to Dr. Smith',  { industry: 'healthcare', jurisdiction: 'US' });
// Share the proof token - portable, verifiable, universalconsole.log(result.proof_token); // shk_v1.xxx.yyy

Quick Start: The United Flow

javascript
// 1. SHAKE — idempotent: same entity data always yields the same shakeconst shake = await shuka.shake('brand', {  name: 'ACME Studios',  registration: 'US-TM-12345'}, { purpose: 'brand identity attestation', industry: 'universal' });
// 2. TERMS — attach modifiable rules to the immutable handshakeawait shuka.createTerms(shake.handshake_id, {  accessType: 'time_limited',  permittedPurposes: ['licensing', 'verification']});
// 3. OFFERING — issue a license offering anchored to the shakeconst offering = await shuka.issueLicense({  anchorHandshakeId: shake.handshake_id,  brand: 'ACME Studios',  rightsHolder: 'ACME Holdings LLC',  validUntil: '2027-12-31T23:59:59Z',  buyToOpenPrice: 500});
// 4. GRANT — purchase the offering (buyer side)const grant = await shuka.purchaseLicense(offering.license.id, 500);
// 5. REGISTRY PROOF — verify the grant and its ledger chainconst proof = await shuka.verifyGrant(grant.grant_id);

Core Concepts

Proof Tokens

When you create an attestation, Shuka returns a proof token:

shk_v1.YWJjMTIzZGVm.a1b2c3d4

This token is:

  • Portable - share it anywhere, verify it anywhere
  • Verifiable - anyone with API access can verify it
  • Persistent - the attestation record is immutable

Trust Scores

Every attestation has a trust score (0.0 - 1.0):

  • 0.8+ - Safe to proceed
  • 0.6-0.8 - Proceed with caution
  • Below 0.6 - Additional verification recommended

Handshake Types

Shuka supports multiple handshake types for different use cases:

TypeUse Case
attestationGeneral attestations (default)
licenseLicense verification
complianceCompliance attestation
compliance_attestationCompliance with attestation
release_of_informationHealthcare ROI
partner_compliancePartner compliance verification

API Reference

ShukaSDK

Main SDK class for AI agent integration.

javascript
const { ShukaSDK } = require('@shukashake/agent');
const shuka = new ShukaSDK({  apiKey: 'your-api-key',  agentName: 'my-agent'  // For audit trails});
attest(description, options?)

Create a verifiable attestation.

javascript
const result = await shuka.attest(  'Contractor ABC Corp is licensed for electrical work in Texas',  {    industry: 'construction',    jurisdiction: 'US-TX',    metadata: {      contractor_id: 'ABC-123',      license_number: 'TX-ELEC-456'    }  });
// Returns:// {//   success: true,//   proof_token: 'shk_v1.xxx.yyy',//   handshake_id: 'uuid',//   trust_score: 0.85// }
verify(proofToken)

Verify a proof token.

javascript
const result = await shuka.verify('shk_v1.xxx.yyy');
// Returns:// {//   verified: true,//   trust_score: 0.85,//   handshake_id: 'uuid',//   created_at: '2024-01-01T00:00:00Z'// }
negotiate(proofToken, purpose?)

Agent-to-agent trust negotiation. When you receive data with a proof from another agent, ask Shuka to vouch for their attestation.

javascript
const trust = await shuka.negotiate(  incomingProofToken,  'processing patient data for care coordination');
if (trust.recommendation === 'safe_to_proceed') {  // The data exchange is trusted - proceed} else if (trust.recommendation === 'proceed_with_caution') {  // Consider additional verification} else {  // Do not proceed}
acknowledgeReceipt(envelopeId)

Complete the exchange by acknowledging receipt (the S'more model - both ends warm).

javascript
await shuka.acknowledgeReceipt('ENV-xxx');

Terms and Conditions

The terms layer is how data owners set constraints on how their data can be used, and how recipients understand and accept those constraints.

Creating Attestations with Terms

Attach terms when creating attestations to control how data can be accessed:

javascript
const result = await shuka.attest(  'Patient John Doe (US, healthcare) consents to release records to Dr. Smith',  {    terms: {      accessType: 'time_limited',           // How data can be accessed      validityDays: 365,                    // Days the terms remain valid      requireReceipt: true,                 // Accesses must be receipted      permittedPurposes: ['care_coordination', 'treatment'],      prohibitedPurposes: ['marketing', 'research']    }  });

Include industry/jurisdiction context in the attested text itself — the quick-attest endpoint records the text and terms. For richer constraints (max uses, downstream rules, pricing), attach full terms afterwards with createTerms(handshakeId, terms) (see Rules Layer below).

Access Types
TypeDescription
single_useOne-time access, then terms expire
time_limitedAccess valid for a time period
use_limitedAccess valid for N uses
perpetualUnlimited access (rare, high trust)
session_boundAccess tied to active session
windowedAccess only during specific time windows
getTerms(handshakeId)

Get the terms attached to a handshake before processing its data:

javascript
const result = await shuka.getTerms('handshake-uuid');
console.log(result.terms.access_type);         // 'time_limited'console.log(result.terms.permitted_purposes);  // ['care_coordination', 'treatment']console.log(result.terms.id);                  // terms_id for the ID-based methods

Removed in 2.1.1: acceptTerms, checkAccess, revokeAccess, updateTerms, getTermsHistory, and getTermsAcceptors called legacy routes that never existed server-side (every call 404'd). They now throw NOT_SUPPORTED with a pointer to the working equivalent in the Rules Layer: recordTermsAccess, revokeTermsById, updateTermsById, getTermsRevisions, and getTermsReceipts — all keyed by the terms_id returned from getTerms(handshakeId) or createTerms().

getChainOfTrust(handshakeId)

Get the full provenance chain for an attestation.

javascript
const chain = await shuka.getChainOfTrust('handshake-uuid');

One Ring Shakes (Idempotent)

The headline method. Same entity data always produces the same shake — safe to retry, safe to call from multiple agents.

javascript
// Create (or return the existing) shake for an entityconst shake = await shuka.shake('vehicle', {  registration: 'ABC123',  emission_standard: 'euro6'}, {  purpose: 'ULEZ compliance attestation',  industry: 'construction',      // healthcare | construction | finance | legal | government | sdk | universal  handshakeType: 'attestation',  // attestation | verification | transfer | consent  expiresInDays: 365});
// Look up an existing shake without creating oneconst existing = await shuka.lookupShake('vehicle', { registration: 'ABC123', emission_standard: 'euro6' });
// Verify a shake by IDconst status = await shuka.verifyShake(shake.handshake_id);

The deterministic entity ID is derived client-side as ENTITY- + SHA-256 of the canonicalized (key-sorted) entity data.

Marketplace (Shake-Anchored Licenses)

Every license offering is anchored to a Shuka Shake; every purchase produces a grant with its own proof token and registry entry.

javascript
// Browse offeringsconst results = await shuka.searchLicenses({ q: 'ACME', brand: 'ACME Studios', page: 1 });
// Inspect and validate a specific offeringconst details = await shuka.getLicense(licenseId);const validity = await shuka.validateLicense(licenseId);
// Issue an offering FROM a handshake (requires SDK key with license:write + issuer role)const offering = await shuka.issueLicense({  anchorHandshakeId: 'handshake-uuid',   // required  brand: 'ACME Studios',                 // required  rightsHolder: 'ACME Holdings LLC',     // required  validUntil: '2027-12-31T23:59:59Z',    // required  buyToOpenPrice: 500,  permittedUses: ['merchandising'],  prohibitedUses: ['resale'],  maxGrants: 100,  royaltyPercentage: 5});
// Purchase → grant (alias: acquireLicense). Idempotent per buyer+license:// replays and already-owned licenses return 409 with no double charge;// a stale payment amount returns 400 carrying the current license_price.// (Escrow is not available.)const grant = await shuka.purchaseLicense(licenseId, 500);
// Verify a grant + its ledger chain integrity (public)const proof = await shuka.verifyGrant('GRANT-xxx');
// Your holdings and any entity's ledger historyconst portfolio = await shuka.getPortfolio();const history = await shuka.getHistory('license', licenseId);

Enterprise Licensing

Seat-based licensing for teams:

javascript
const offers = await shuka.browseEnterpriseLicenses({ brand: 'ACME', minSeats: 50 });

Acquisition not yet available: the enterprise seat model is not built server-side — acquireEnterpriseSeats currently returns 501 not_implemented for every request. Use purchaseLicense for single-grant acquisitions.

Rules Layer (Terms by ID)

Modifiable terms on immutable handshakes — the rules travel with the shake, and every change is receipted:

javascript
// Create terms bound to a handshakeconst terms = await shuka.createTerms('handshake-uuid', {  accessType: 'use_limited',  accessConfig: { max_uses: 10 },  permittedPurposes: ['care_coordination'],  prohibitedPurposes: ['marketing']});
// Read / amend / revokeawait shuka.getTermsById(terms.terms_id);await shuka.amendTerms(terms.terms_id, { permitted_purposes: ['care_coordination', 'billing'] });await shuka.revokeTermsById(terms.terms_id, { reason: 'Consent withdrawn', cascadeDownstream: true });
// Record an access against the terms (creates a receipt)await shuka.recordAccess(terms.terms_id, { purpose: 'care_coordination' });
// Full audit trailawait shuka.getTermsRevisions(terms.terms_id);await shuka.getTermsReceipts(terms.terms_id);await shuka.getHandshakeTerms('handshake-uuid');  // all terms on a handshake

Registry Discovery (SDK Pass-Throughs)

Also available directly on ShukaSDK:

javascript
await shuka.discoverRegistries({ industry: 'healthcare', verifiedOnly: true });await shuka.lookupRegistry('hospital-abc');await shuka.canIssue('hospital-abc', 'release_of_information');await shuka.willAccept('clinic-xyz', 'release_of_information');await shuka.checkInteroperability('hospital-abc', 'clinic-xyz', 'release_of_information');

ShukaClient

Low-level client with direct API access, caching, and deduplication.

javascript
const { ShukaClient } = require('@shukashake/agent/client');
const client = new ShukaClient({  apiKey: 'your-api-key',  agentId: 'my-agent',  agentType: 'claude'});
Registry Discovery

Find organizations that issue or accept specific shake types:

javascript
// Discover healthcare organizationsconst registries = await client.discoverRegistries({  industry: 'healthcare',  shakeType: 'release_of_information',  verifiedOnly: true});
// Check if an entity can issue a shake typeconst canIssue = await client.canIssue('hospital-abc', 'release_of_information');
// Check if an entity will accept a shake typeconst willAccept = await client.willAccept('clinic-xyz', 'release_of_information');
Interoperability Checking

Check if data can flow between two entities:

javascript
const interop = await client.checkInteroperability(  'hospital-abc',      // issuer  'clinic-xyz',        // receiver  'release_of_information');
if (interop.interoperable) {  // Clinic XYZ will accept ROI from Hospital ABC}

AI Platform Integrations

Claude Integration
javascript
const { ClaudeIntegration } = require('@shukashake/agent');
const claude = new ClaudeIntegration({ apiKey: '...' });
// Returns Claude-formatted responsesconst result = await claude.attestForClaude('My claim');const verified = await claude.verifyForClaude('shk_v1.xxx.yyy');const trust = await claude.negotiateForClaude(proofToken, 'purpose');
ChatGPT Integration
javascript
const { ChatGPTIntegration } = require('@shukashake/agent');
const gpt = new ChatGPTIntegration({ apiKey: '...' });
// Returns GPT function-calling formatted responsesconst result = await gpt.attestForGPT('My claim');const verified = await gpt.verifyForGPT('shk_v1.xxx.yyy');const trust = await gpt.negotiateForGPT(proofToken, 'purpose');

Middleware

Create middleware for your agent pipeline:

javascript
const { createShukaMiddleware, createAttestationMiddleware } = require('@shukashake/agent');
// Verification middleware for incoming dataconst verifyTrust = createShukaMiddleware({ apiKey: '...' });
const trust = await verifyTrust(incomingProofToken, 'processing request');if (trust.shouldProceed) {  // Safe to act on the data}
// Attestation middleware for outbound dataconst createProof = createAttestationMiddleware({ apiKey: '...' });
const proof = await createProof('My claim', { industry: 'healthcare' });// Include proof.proofToken in your response

MCP Server (Claude Desktop)

Run as an MCP server for Claude Desktop integration:

bash
npx @shukashake/agent/mcp

Or configure in Claude Desktop's claude_desktop_config.json:

json
{  "mcpServers": {    "shuka": {      "command": "npx",      "args": ["@shukashake/agent/mcp"],      "env": {        "SHUKA_API_KEY": "your-api-key"      }    }  }}

Available MCP Tools (15, united):

One Ring shakes

  • create_idempotent_shake - RECOMMENDED: create (or return existing) shake for any entity - same input, same shake
  • lookup_shake - Find an existing shake by entity data without creating one
  • verify_shake - Verify a shake by its handshake ID

Attestation (legacy-compatible)

  • create_attestation - Create a verifiable attestation
  • verify_proof - Verify a proof token
  • negotiate_trust - Agent-to-agent trust negotiation

Marketplace

  • browse_marketplace - Search shake-anchored license offerings, or inspect one by ID
  • issue_license - Issue a license offering FROM a handshake (requires license:write)
  • purchase_license - Purchase an offering → grant with proof token
  • verify_grant - Verify a grant, its anchoring license, and ledger chain integrity

Enterprise

  • enterprise_licenses - Browse or acquire seat-based enterprise licenses

Rules layer

  • manage_terms - Create/get/update/revoke terms, record access, revisions, receipts

The drawbridge (v2.2.0)

  • check_access - THE decision point: signed allow/deny over the stored terms + revocation state; allowed crossings receipted + ledgered
  • revoke_grant - Issuer/admin grant revocation with the transactional GRANT_REVOKED ledger event

Registry

  • registry - Ledger history, registry discovery, can-issue/will-accept, interop checks

Available MCP Resources:

  • attestation://{proof_token} - Look up attestation details
  • grant://{grant_id} - Public grant verification

shuka.guard — the enforcement point (NEW)

The drawbridge, installed in front of YOUR data API. On every crossing the guard asks Shuka's decision point whether this accessor may use this data for this purpose right now — terms, validity window, remaining uses, purpose binding, and revocation state. Denials stop the request; allowed crossings are receipted on the hash-chained ledger.

javascript
const { createGuard } = require('@shukashake/agent/guard');
const guard = createGuard({ apiKey: process.env.SHUKA_CROSSING_PASS });
// Express: protect any data routeapp.get('/patients/:id/records',  guard.express(),   // 403 unless Shuka says allow; req.shuka = signed verdict  (req, res) => res.json(loadRecords(req.params.id)));
// Framework-agnosticconst verdict = await guard.checkAccess({  proofToken: 'shk_v1....', purpose: 'care_coordination' });

Fail-closed by default: if Shuka is unreachable the bridge stays up.

Crossing-passes — agents never hold the partner key (NEW)

Exchange your partner key for a short-lived, scope-limited pass per agent run:

POST /api/sdk/v1/keys/exchange{ "expires_in_seconds": 900, "permissions": ["handshake:verify"], "name": "agent-7" }

The pass is sent as X-SDK-API-Key, self-destructs at expiry (60s–1h), can never create keys or exchange for further passes, and can never hold scopes its parent lacks. Keep the partner key in your vault/CI.

Caching

The client includes built-in LRU caching with TTL:

OperationCache Duration
verify()5 minutes (success), 30 seconds (failure)
getChainOfTrust()10 minutes
discoverRegistries()15 minutes
checkInteroperability()10 minutes
getTerms()5 minutes
checkAccess()2.5 minutes
verifyShake()5 minutes (success), 30 seconds (failure)
verifyGrant()5 minutes (success), 30 seconds (failure)

Duplicate in-flight requests are automatically deduplicated.

javascript
// Check cache statsconst stats = shuka.getCacheStats();console.log(stats);// {//   verify: { size: 5, hits: 10, misses: 2, hitRate: '83.3%' },//   chain: { size: 2, ... },//   ...// }
// Clear cacheshuka.clearCache();
// Invalidate specific tokenshuka.invalidate('shk_v1.xxx.yyy');

TypeScript

Full TypeScript support with type declarations:

typescript
import {  ShukaSDK,  HandshakeType,  TrustRecommendation,  Industry,  AccessType,  TermsStatus,  type AttestationResult,  type NegotiationResult,  type TermsResult,  type AccessCheckResult} from '@shukashake/agent';
const shuka = new ShukaSDK({ apiKey: process.env.SHUKA_API_KEY });
// Create attestation with termsconst result: AttestationResult = await shuka.attest('My claim', {  industry: Industry.HEALTHCARE,  terms: {    accessType: AccessType.TIME_LIMITED,    validUntil: '2026-12-31T23:59:59Z',    permittedPurposes: ['care_coordination'],    requiresAcceptance: true  }});
// Check terms before processingconst terms: TermsResult = await shuka.getTerms(result.proof_token!);if (terms.requires_acceptance) {  await shuka.acceptTerms(result.proof_token!, { purpose: 'care_coordination' });}
// Verify access is permittedconst access: AccessCheckResult = await shuka.checkAccess(result.proof_token!, {  purpose: 'care_coordination'});
if (access.permitted) {  const trust: NegotiationResult = await shuka.negotiate(result.proof_token!);  if (trust.recommendation === TrustRecommendation.SAFE_TO_PROCEED) {    // Proceed with data  }}

Environment Variables

VariableDescription
SHUKA_API_KEYYour Shuka SDK API key
SHUKA_API_URLAPI base URL (default: production)

Pricing

Shuka uses pay-per-use pricing with volume discounts for partners.

Pricing tiers:

  • Developer (pay-per-use) - Billed per operation via Stripe
  • Enterprise (subscription) - Included handshake quotas with overage billing

Pricing details are provided during partner onboarding. Volume discounts up to 30% available for enterprise partners.

Live prices come from the shared backend price book at GET /api/sdk/v1/pricing — never hardcode amounts (the response also carries tier_discounts and per-product blocks such as ip_report). As across the whole Shuka surface (SDK v2 billing semantics): there is no free tier, registering a shake is billable, verifying existing proofs/tokens/grants is free, and identical billable requests are content-idempotent (replays return the existing record — was_created: false on the idempotent shake surface — with no new charge). Agent trust negotiation (negotiate) and the portfolio read (getPortfolio) are also billable.

Become a partner: [email protected] or visit shuka.app

Links

  • Platform: shuka.app
  • Demo: shuka.app/demo
  • Python SDK (v2.0.0): distributed as a presigned tarball via GET /api/sdk/v1/download — no PyPI package. See shukaSDK/README.md, shukaSDK/API_SPECIFICATION.md (generated from the route registry), and shukaSDK/MIGRATION.md in the Auron_Shuka repo.

Company

Built by Auron - the gold standard of trust.

License

MIT

来源:README.md,提交 938b4b4

工具

15

create_idempotent_shake

Create or retrieve an idempotent Shuka shake. RECOMMENDED for most use cases. The One Ring: Same entity_data always returns the same shake. This is the magic that enables AI agents to repeatedly attest to the same data without creating duplicates - critical for enterprise integrations. This shake is the anchor for EVERYTHING else in the united flow: attach terms (manage_terms), issue a marketplace offering from it (issue_license), and its lifecycle is recorded in the registry (registry). Use this when you need to: - Attest to data that may be referenced multiple times - Create portable proofs that persist across sessions - Ensure billing accuracy (only charged on first creation) - Build reliable audit trails without duplicate entries Returns the shake with was_created=true (new) or was_created=false (existing).

输入参数purpose必填industryentity_data必填entity_type必填handshake_typeexpires_in_days

lookup_shake

Look up an existing shake by entity identifiers. Use this to check if a shake already exists before creating a new one, or to retrieve shake details for data you've previously attested. Returns the shake if found, or null if not found.

输入参数entity_data必填entity_type必填

verify_shake

Verify a shake by its ID and get trust information. Use this to confirm a shake is valid and check its trust score before proceeding with a data exchange.

输入参数shake_id必填

create_attestation

Create a verifiable Shuka attestation for any claim or data. Use this when you need to: - Prove a claim is true with cryptographic certainty - Create an audit trail for data being shared - Attest to compliance, consent, or authorization - Generate a portable proof that other agents can verify Returns a proof token (shk_v1.xxx.yyy) that anyone can verify. Include industry/jurisdiction context directly in the description text — the attestation records the text and optional terms.

输入参数termsdescription必填

verify_proof

Verify a Shuka proof token and get details about the attestation. Use this when you: - Receive a proof token and need to confirm it's valid - Want to check the trust score before proceeding - Need to see what was attested and when - Want to verify claims before acting on data Proof tokens look like: shk_v1.YWJjMTIz.a1b2c3 or ENV-xxx

输入参数proof_token必填

negotiate_trust

Perform agent-to-agent trust negotiation with Shuka as the arbiter. Use this when: - Another agent presents a proof and you need Shuka to vouch for it - You need a recommendation on whether to proceed with a data exchange - You want detailed validation evidence before trusting external data Returns a recommendation: safe_to_proceed, proceed_with_caution, additional_verification_recommended, or do_not_proceed. NOTE: negotiation is a billable operation (standard shake rate). An invalid proof is rejected by a free pre-check before any charge.

输入参数purposeproof_token必填

browse_marketplace

Browse the shake-anchored license marketplace. Every offering in the marketplace is anchored to a Shuka shake that proves the underlying rights. Without a license_id this searches offerings; with a license_id it returns full details plus a validation check. Use this to: - Discover license offerings by keyword or brand - Inspect a specific offering before purchasing (purchase_license) - Confirm an offering is real, active, and in good standing

输入参数pagebrandsearchper_pagelicense_id

issue_license

Issue a license offering anchored to one of YOUR handshakes (shakes). The united flow: your shake proves the underlying rights; the offering is issued FROM that shake; buyers purchase grants against it; every event is recorded in the append-only registry. Requires an SDK key with license:write permission and an issuer-capable account (Partner/Admin). Get keys at https://shuka.app/dashboard/api-keys Use this to: - Turn an attested asset (voice likeness, IP, dataset rights) into a sellable offering - Set pricing, permitted/prohibited uses, royalties, and grant caps

输入参数brand必填image_urlmax_grantsvalid_until必填rights_holder必填permitted_usesprohibited_usesroyalty_cap_usdbuy_to_open_priceroyalty_percentageanchor_handshake_id必填platform_fee_percentage

purchase_license

Purchase a license from the marketplace (creates a grant). Returns the transaction, portfolio entry, and the attestation (handshake + proof_token) anchoring the grant to the registry ledger. The proof_token is portable - any agent can verify it with verify_proof. Acquisition is idempotent per buyer+license: a replay returns 409 with no double charge; a license you already own returns 409 already_owned; a payment_amount that doesn't match the current list price returns 400 carrying license_price. Use this to: - Acquire usage rights for an offering found via browse_marketplace - Get a cryptographic proof of your grant for downstream agents

输入参数license_id必填payment_amount必填

verify_grant

Verify a marketplace grant against the append-only registry ledger. Returns the grant status, the anchoring license offering, the attestation, and the integrity of the ledger chain. This is how any agent confirms a grant is real, active, and unrevoked - without trusting the grant holder. Use this when: - Another party claims to hold a license grant - You need to confirm a grant before honoring its permitted uses

输入参数grant_id必填

enterprise_licenses

Browse enterprise (multi-seat) license offerings. action="browse": list enterprise offerings (filter by brand, min_seats, max_price). action="acquire": NOT CURRENTLY AVAILABLE — the enterprise seat model is not built yet and the backend returns 501 not_implemented. Use purchase_license for single-grant acquisitions.

输入参数brandaction必填max_pricemin_seatslicense_idseats_needed

manage_terms

Manage the rules layer: modifiable terms riding on immutable handshakes. The shake never changes; the terms on it can be amended, re-priced, or revoked WITHOUT re-attesting. This is how user IP stays under the owner's control after attestation. Actions (all require an SDK key assigned to a user; most are billable): - create: attach terms to a handshake (requires handshake_id; access_type defaults to perpetual; 409 terms_exist if the handshake already has terms; needs license:write, $0.05) - get: fetch terms by terms_id - update: amend terms (updates MUST include change_reason or the backend 400s; new revision recorded; needs license:write, $0.03) - revoke: revoke terms (reason is REQUIRED; needs license:write, $0.02) - record_access: log an access under the terms (creates a receipt; purpose must be in permitted_purposes when those are set; needs license:read, $0.01) - revisions: amendment history for terms - receipts: access receipts (audit trail) for terms - by_handshake: get the current terms attached to a handshake

输入参数action必填reasonpurposeupdatesterms_idaccess_typeaccessor_idhandshake_idaccess_configpermitted_purposesprohibited_purposes

registry

Query the Shuka registry: the append-only ledger and interoperability layer. Actions: - history: full chronological ledger history for an entity (requires entity_type + entity_id) - discover: find registries by industry / shake_type - lookup: look up a registry entity by entity_id - can_issue: check whether an entity can issue a shake type (requires entity_id + shake_type) - will_accept: check whether an entity accepts a shake type from an issuer (requires entity_id + shake_type + issuer_id) - interop_check: full issuer-to-receiver interoperability check (requires issuer_id + receiver_id + shake_type) Use this to trace provenance (every license and grant event is in the ledger) and to confirm two parties can exchange a given shake type BEFORE attempting it.

输入参数action必填industryentity_idissuer_idshake_typeentity_typereceiver_id

check_access

THE DECISION POINT: may this accessor use this data for this purpose right now? Evaluates the stored Terms Layer (status, validity window, remaining uses, purpose binding) AND the shake's revocation state, server-side. Returns a SIGNED verdict. Allowed crossings are receipted and land as ACCESSED events on the hash-chained ledger; a revoked shake denies with consent_revoked. Call this BEFORE acting on data protected by a Shuka proof — it is the same check shuka.guard performs at enterprise enforcement points.

输入参数recordpurposeterms_idproof_tokenhandshake_id

revoke_grant

Revoke a license grant (issuer or admin only). Writes the transactional GRANT_REVOKED event on the grant's ledger chain and revokes the grant's proof token — verify_grant reports it immediately.

输入参数reasongrant_id必填

版本历史

4
  1. v2.2.0最新Oct 26, 2026
  2. v2.1.2Oct 15, 2026
  3. v2.1.1Oct 2, 2026
  4. v1.0.2Sep 16, 2026

评分

已满足适用检查项的 90%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分
  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分