Capstone: design an access model

A logistics company is putting three agents into production. Design the access model. The brief is deliberately underspecified in the places real briefs are.

• A quoting agent reads carrier rate cards and answers customer questions on a public web form.
• A booking agent creates shipments through a carrier API, which is billed per call.
• A reconciliation agent runs nightly, reads invoices, and writes a summary to an internal vault path.
• One human operations lead owns all three. Compliance requires that any spend above 500 USD be attributable to a person.

Start with identity. Three agents, three identities, no sharing. That is not bureaucracy: the reconciliation agent runs unattended at night and the quoting agent takes input from the open internet, and when something goes wrong you need the audit trail to distinguish them. Give each its own environment tag, and lock the tag on the two that touch production.

Then scope. Work path by path rather than agent by agent, because the interesting question is which agent should not reach a path:

• rates/** read for the quoting agent only. It never needs write, and it must never reach invoices.
• invoices/** read for reconciliation only, with a deny on the quoting agent even though no allow would have matched it. The deny documents the intent and survives a later broad grant.
• reports/** write for reconciliation only.
• The booking agent gets no secret read at all, which is the interesting part.

1. 1

   Give the booking agent a binding rather than a credential. It calls the carrier API through Execution Intents, so the key stays server-side.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/agents/$BOOKING_AGENT/bindings \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "name": "carrier-api",
       "binding_type": "http",
       "base_url": "https://api.carrier.example",
       "allowed_hosts": ["api.carrier.example"],
       "allowed_paths": ["/v2/shipments"],
       "credential_source": {
         "type": "vault_ref",
         "vault_id": "'$VAULT_ID'",
         "path": "providers/carrier/key"
       }
     }'

2. 2

   Scope the quoting agent to exactly one prefix, and add the deny that documents what it must never reach.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/vaults/$VAULT_ID/policies \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -d '{"principal_type":"agent","principal_id":"'$QUOTE_AGENT'",
          "path_pattern":"rates/**","permissions":["read"],
          "effect":"allow","priority":10}'
   
   curl -s -X POST https://api.1claw.co/v1/vaults/$VAULT_ID/policies \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -d '{"principal_type":"agent","principal_id":"'$QUOTE_AGENT'",
          "path_pattern":"invoices/**","permissions":["read"],
          "effect":"deny","priority":100}'

3. 3

   Satisfy the compliance requirement with an approval policy rather than a hard cap, so large bookings reach the operations lead instead of failing.

   bash Copy

   curl -s -X PATCH https://api.1claw.co/v1/agents/$BOOKING_AGENT \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -d '{"tx_approval_policy":{"min_value_usd":500,"action":"approve"}}'

The pattern to take away: when a request arrives as "agent X needs access to Y", the useful question is what X actually needs to produce. Access is one way to get there and usually the widest one.