Customer onboarding

How a new customer goes from "we'd like to try kilasec" to "we have a collector running and our admin is in the dashboard."

The model

There are two distinct bootstrap flows, and they don't share a token:

	What it bootstraps	Token type
Invite link	a browser session for a human admin	tenant api_token carried in a kilasec_session cookie
Enrollment code	a per-collector identity for a machine	per-collector token, scoped to that one box

You'll usually issue both: one invite for the admin, one or more enrollment codes for the collectors they'll run.

All of steps 1–2 are point-and-click in the staff admin dashboard — sign in as Kilasec staff and use the Tenants page. The CLI shown below is a fallback for scripted/headless use.

1 — create the tenant

Dashboard: Tenants → New tenant → enter the customer name. A tenant API token is shown once; a default policy + scope are seeded automatically.

CLI (fallback), on the cloud VM:

ssh ubuntu@kilasec.com
cd /opt/agentfw && . .venv/bin/activate
python -m cloud.admin_cli tenants create "Acme Corp"

The agt_… value is the tenant API token. It never leaves the VM by default. Invite links and enrollment codes carry shorter random codes that resolve to this tenant only when redeemed.

2 — invite the admin, or issue a collector code directly

Dashboard: on the Tenants row for that customer, either mint an invite link for their human admin (Invites page) or use Issue collector code to get a ready-to-run install command without waiting for them to sign in first.

CLI (fallback):

python -m cloud.admin_cli invites create acme-corp \
  --label "for Pradeep" --ttl-hours 168

Send the invite URL to the customer admin out-of-band (email, Signal, whatever). It's:

• Single-use — the first click consumes it.
• Time-bounded — defaults to 72h.
• Revocable — python -m cloud.admin_cli invites revoke <code> cuts it before use.

3 — admin redeems the invite

Customer clicks the URL → backend validates → sets the kilasec_session cookie (httpOnly, secure, samesite=lax) → lands on their dashboard, which shows a first-run checklist (install & approve a collector → point the network → trust the CA → verify traffic).

The welcome wizard shows three things they'll need: the cloud URL, an API token (in the form of an enrollment-code workflow), and a copy-pasteable install command for their collector.

4 — collector enrollment

The customer's IT runs the install command on the LAN host they've chosen for the collector. The installer:

1. POSTs the enrollment code to https://kilasec.com/api/v1/collectors/enroll.
2. Receives a per-collector token + the docker image registry creds.
3. Pulls the docker image, drops a systemd unit, starts the collector.
4. Reports first heartbeat → the dashboard's Live-Feed pill goes green.

The customer admin sees the collector appear under Collectors within ~30 seconds.

5 — first traffic

Once the collector is reachable on its LAN, AI traffic gets routed through it (DHCP-pushed PAC or per-host proxy config). The first decision shows up on Live Traffic within seconds.

What's wired by default

When the tenant is fresh, kilasec gives the admin a sensible default policy:

- name: log_all_llm_calls
  action: log
- name: redact_pii_on_egress
  match: { contains_pii: true }
  action: redact
- name: approve_external_writes
  match: { action: http_request, arg_regex: { method: "POST|PUT|DELETE" } }
  action: require_approval
- name: deny_unknown_host
  match: { action: http_request }
  action: deny    # default-deny for unknown providers

The customer can edit on Policy Rules → Editor.

→ See Writing policy rules.