Sentinel documentation
How the Intelligence Engine actually works, section by section. A full API reference is on the roadmap — the endpoints below are live today.
Every check Sentinel runs produces a raw evidence record — config/metadata only, never file contents, secrets or PII — stored and linked to whatever finding, control status or correlation it informs.
- •Every finding has a "View evidence" drawer with raw evidence, full observation history, and every status change
- •Evidence is never silently overwritten — a control regressing from implemented to not-implemented is itself a tracked event (drift)
Read-only integrations that pull evidence from your existing tools — no agent install required for most of them.
- •Source control & CI/CD: GitHub, Vercel, Cloudflare
- •Cloud: AWS, GCP, Azure
- •Identity: Okta, Google Workspace
- •Code security: Semgrep (SAST/secrets), Trivy (container images, CI-pushed)
- •Runtime: the Sentinel Agent (container/process/port inventory)
Confidence is a first-class, always-visible number — separate from severity — computed from evidence coverage, not from how many findings fired.
- •Per-domain percentage bars: how much of a domain Sentinel currently has evidence for
- •Five-state scale layered on top: Confirmed, Likely, Potential, Unknown, Unable to Verify
- •An unconnected domain shows an honest 0%, never a hidden gap
Sentinel links evidence across sources instead of treating each connector as an island.
- •Deploy events correlated with new findings in a directional time window
- •Route-diff tracking: detects which route files changed between deploys
- •Route confirmation: an HTTP reachability check on changed routes (not a browser — no JS/client-side routing)
- •The Security Knowledge Graph links entities (applications, deployments, findings, routes) so relationships are queryable, not just implied
A continuously running research agent, not an autonomous system.
- •Reads NVD (CVE feed) and GitHub Security Advisories daily
- •Clusters related advisories and drafts recommendations for human review
- •Every recommendation is inert until a person reviews and merges it like a normal code change — nothing is auto-applied
For customers who want to push evidence in from their own CI/CD rather than wait for a pull-based connector.
- •POST /api/v1/sentinel/deploy-event — provider-agnostic deploy reporting from any CI system
- •POST /api/v1/sentinel/trivy-scan — push container-scan results from your own CI
- •POST /api/v1/sentinel/scan — trigger an authorized scan programmatically
- •API keys are scoped (e.g. scan:write) and issued from your account settings
A vendor-neutral People Directory, not an HR product — an identity source for future user lifecycle, access review, and risk-correlation features. Import from any source (CSV, JSON, webhook) instead of requiring an official BambooHR/Workday/HiBob/Personio integration.
- •GET /api/v1/sentinel/people — list/search (?q=, ?department=, ?status=, ?employmentType=)
- •GET /api/v1/sentinel/people/{id} — fetch one person
- •POST /api/v1/sentinel/people — create/upsert one person
- •PUT /api/v1/sentinel/people/{id} — update one person
- •DELETE /api/v1/sentinel/people/{id} — remove one person
- •POST /api/v1/sentinel/people/bulk — batch upsert, body: { people: [...] }, max 5000 per request
- •POST /api/v1/sentinel/people/webhook — push one record or { people: [...] } as your source system changes
- •GET /api/v1/sentinel/people/schema — the canonical Person model, no auth required
- •Auth: X-Api-Key header, needs the people:read and/or people:write scope (issued from the People Directory page)
- •CSV import is UI-only today (People Directory page → Import CSV), session-authenticated, not part of the public API
- •The Connector Framework (sentinel_connectors) is generic — resource_type isn't limited to people, it's built to back future connector types (assets/devices/domains/cloud resources/vendors) the same way
curl -X POST https://klaro.services/api/v1/sentinel/people \
-H "X-Api-Key: sk_sentinel_..." \
-H "Content-Type: application/json" \
-d '{
"externalId": "emp-4471",
"sourceSystem": "internal-hr-db",
"firstName": "Priya",
"lastName": "Nair",
"email": "priya.nair@example.com",
"department": "Engineering",
"title": "Senior Security Engineer",
"employmentType": "employee",
"status": "active"
}'{
"person": {
"id": "b3f1...",
"externalId": "emp-4471",
"sourceSystem": "internal-hr-db",
"firstName": "Priya",
"lastName": "Nair",
"email": "priya.nair@example.com",
"department": "Engineering",
"title": "Senior Security Engineer",
"employmentType": "employee",
"status": "active",
"createdAt": "2026-08-04T10:12:00.000Z",
"lastUpdated": "2026-08-04T10:12:00.000Z"
}
}{ "error": "This key does not have the people:write scope" }Other error statuses: 400 (invalid/missing fields — at least one of email, externalId, or employeeNumber is required), 401 (missing/invalid X-Api-Key), 404 (person not found), 500 (unexpected server error).
External ID,First Name,Last Name,Email,Department,Title,Employment Type,Status emp-4471,Priya,Nair,priya.nair@example.com,Engineering,Senior Security Engineer,employee,active emp-4472,Raj,Mehta,raj.mehta@example.com,Engineering,Engineering Manager,employee,active
Header names are matched case-insensitively against common spellings (e.g. "Email", "Email Address", and "Work Email" all map to the same field) — anything unrecognized is kept in the record's metadata rather than dropped.