ANIP Playground

1. Book a flight within budget

Goal: Book a flight, but only if the cost is within your delegated budget.

REST / GraphQL / MCP

Call the booking endpoint. Discover the cost after being charged. No way to check budget constraints before execution. No side-effect declaration — you can't tell this is irreversible until it's done.

ANIP

Agent inspects the manifest, sees book_flight is irreversible with cost range $200–$800. Checks delegation budget. Checks permissions. Decides whether to proceed with full context.

Step 1: Check the manifest to see cost and side-effect declarations

curl https://travel.playground.anip.dev/anip/manifest | jq '.capabilities.book_flight.side_effect, .capabilities.book_flight.cost'

Step 2: Get a delegation token with travel.book scope

curl -X POST https://travel.playground.anip.dev/anip/tokens \
  -H "Authorization: Bearer demo-human-key" \
  -H "Content-Type: application/json" \
  -d '{"scope": ["travel.book"], "capability": "book_flight", "subject": "agent:demo"}'

Step 3: Check permissions before invoking

curl -X POST https://travel.playground.anip.dev/anip/permissions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" -d '{}'

Step 4: Invoke with full context — the response includes cost_actual and invocation_id

curl -X POST https://travel.playground.anip.dev/anip/invoke/book_flight \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"parameters": {"flight_number": "AA100"}}'

What ANIP adds: The agent knows cost, irreversibility, and authority before acting. REST/GraphQL/MCP give none of this — the agent discovers constraints by failing.

2. Handle a permission block

Goal: Try an operation you don't have permission for. See how each interface handles it.

REST / GraphQL / MCP

Agent calls the endpoint, gets 403 Forbidden. No information about why, who can fix it, or what's needed. Agent retries or gives up.

ANIP

Agent checks permissions first, sees restricted: missing scope, grantable_by: human:admin@example.com. Reports to user: "I need booking access — shall I request it from admin?"

Step 1: Get a token with only search scope (no booking)

curl -X POST https://travel.playground.anip.dev/anip/tokens \
  -H "Authorization: Bearer demo-human-key" \
  -H "Content-Type: application/json" \
  -d '{"scope": ["travel.search"], "capability": "search_flights", "subject": "agent:demo"}'

Step 2: Check permissions — see what's available vs restricted

curl -X POST https://travel.playground.anip.dev/anip/permissions \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" -d '{}'

Step 3: The response tells the agent exactly what's missing and who can grant it

What ANIP adds: Structured recovery guidance. The agent doesn't just know it's blocked — it knows what's needed, who can grant it, and what to tell the user.

3. Audit what happened

Goal: After a series of actions, review what happened, who authorized it, and what it cost.

REST / GraphQL / MCP

No standard audit API. Check application logs manually (if they exist). No event classification, no lineage, no protocol-level retention.

ANIP

Agent queries /anip/audit to see every invocation: capability, caller, event classification, success/failure, timestamp. Checkpoints provide tamper-evident verification.

Step 1: Run a few invocations first (search flights, attempt a booking)

Step 2: Query the audit log

curl -X POST https://travel.playground.anip.dev/anip/audit \
  -H "Authorization: Bearer demo-human-key" \
  -H "Content-Type: application/json" -d '{}'

Step 3: Check Merkle checkpoints for tamper-evident verification

curl https://travel.playground.anip.dev/anip/checkpoints

What ANIP adds: Protocol-level audit with event classification, lineage tracking, and cryptographic verification. Not an afterthought — built into the interface.

ANIP Playground

Travel

Finance

DevOps

Try these scenarios

1. Book a flight within budget

2. Handle a permission block

3. Audit what happened