Concept

Security

Webhook signature verification, API key scopes, relay latency guarantees, and vulnerability disclosure.

Webhook signature verification

Kite automatically verifies incoming webhook signatures before relaying. Verification happens at the relay server — payloads that fail signature checks are rejected before they reach your CLI.

Supported signature schemes:

GitHub — HMAC-SHA256 over the body, verified against X-Hub-Signature-256
Stripe — timestamp + HMAC-SHA256, verified against Stripe-Signature
Slack — HMAC-SHA256 with timestamp replay protection, X-Slack-Signature
Linear — HMAC-SHA256, Linear-Signature
Shopify — HMAC-SHA256, X-Shopify-Hmac-Sha256
Vercel — HMAC-SHA1, X-Vercel-Signature
Discord — Ed25519, X-Signature-Ed25519 and X-Signature-Timestamp

Kite stores provider signing secrets encrypted at rest. GitHub endpoint creation can generate a one-time secret for GitHub's webhook settings; providers such as Linear and Stripe issue the signing secret, and you paste that value into Kite when creating or rotating the endpoint.

API key scopes and permissions

API keys have fine-grained scopes. Create keys with only the permissions needed:

bash

kite keys create --name "ci-bot" --scopes "stream:read" --expires-at "2027-01-01T00:00:00Z"

Available scopes include stream:read, endpoints:write, keys:write, and logs:read. Manage keys via the dashboard or the CLI.

Delivery behavior

Kite provides these delivery controls:

At-least-once delivery — failed deliveries are queued for retry
Cursor tracking — set --client-id for resumable streams across reconnects

For declarative source and sink configuration, see the kite.json manifest.

x402 bootstrap security

Bootstrap credentials issued via POST /api/v1/bootstrap/x402 are only available for a short replay window after first issuance. Store them immediately — subsequent requests require re-payment.

Vulnerability disclosure

Security issues can be reported via the policy published at `/.well-known/security.txt`.