Customer Agents — Build a product that ships agents to your customers
Time to working integration: ~10 minutes.
This is the primary SharkAuth use-case: you build a SaaS product, each of your customers gets their own agent identity, and you need a way to provision, bound, and revoke those agents without writing the OAuth server yourself.
Mental model
human (your customer)
└─▶ your app (your backend)
└─▶ customer's agent (provisioned by you per customer)
└─▶ external resource (MCP server, API, etc.)
└─▶ validates via JWKS at /.well-known/jwks.json
SharkAuth sits between your app and the external resource. Your app holds the admin key. The agent holds a DPoP-bound token. The external resource trusts the JWKS endpoint.
When a customer cancels, one call (revoke_agents) kills every token across all their agents instantly — no token TTL to wait out.
Step 1 — Start the server
First boot prints your admin API key (sk_live_...) and opens the dashboard at http://localhost:8080. Copy the key.
screenshot: first-boot terminal with admin key highlighted
Step 2 — Create an Application (your app's OAuth client)
In the dashboard: Applications → New Application. Give it a name (e.g. my-saas-backend). The Application ID (app_...) scopes all agents created by your backend.
screenshot: new application dialog with app_id visible
Alternatively via CLI:
See ./cli/03-applications.md for full CLI reference.
Step 3 — Implement signup: provision a per-customer agent
When a customer signs up in your product, call register_agent() to create their agent identity in SharkAuth. Store the returned client_id and client_secret in your database — the secret is shown once.
The agent client_id (shark_agent_...) is the stable identifier you'll use for every subsequent operation.
Step 4 — Agent runtime requests a DPoP-bound token
At agent runtime (not signup time), the agent generates a keypair, requests a token bound to that key, and uses it for every outbound call.
OAuthClient.get_token_with_dpop() → ../sdk/oauth-clients.md
Step 5 — Agent calls an external resource
The agent makes DPoP-authenticated HTTP calls. The proof is freshly signed per request, binding htm, htu, and ath.
The MCP server validates the token via the JWKS endpoint at:
GET http://localhost:8080/.well-known/jwks.json
No SharkAuth SDK required on the resource server — any RFC 7517-compliant JWKS validator works.
The JWKS endpoint is live at GET /.well-known/jwks.json.
Step 6 — Customer cancels: cascade revoke all their agents
One call. All tokens across all agents created by this customer are immediately invalid — no TTL wait, no polling.
This is Layer 3 of the five-layer revocation model. See 10-five-layer-revocation.md for the full model.
Full example (≤25 lines)
What happens in the audit log
Every step above emits an audit event queryable at GET /api/v1/audit-logs. Example events:
See ../sdk/audit-logs.md.
Next steps
- Add delegation chains so agents act on behalf of your human users: 11 — Delegation Chains
- Understand all five revocation layers: 10 — Five-Layer Revocation
- Drop SharkAuth in front of an MCP server directly: 02 — MCP Server