LESNAR AI Engineering company · Nairobi

Work / Security

SentinelCore

A self-hostable security operations platform. It observes what you own, joins signals into incidents, acts only under governance, proves recovery independently and keeps the lessons. It holds every claim to evidence, its own included.

Internaldevelopment candidate · no customer deploymentPython · FastAPI · PostgreSQL · tenant-scopedSentinel Assurance is its assurance and qualification layer

In plain terms

What it does for an organisation, before the machinery.

  1. Finds what is exposedIt maps what you own and runs real scanners against it, only where you have authorised it.
  2. Decides what is an incidentIt joins many signals into one incident, and decides with an engine that is tested blind before it gets authority.
  3. Contains, then proves recoveryIt proposes reversible containment for a person to approve, then verifies recovery independently and keeps the lesson.

One protection loop

Twelve capabilities, each with one role in a single loop. Engine, alert and incident outputs feed the unified incident as evidence instead of running as parallel systems.

  1. Observe

    • Telemetry and owned-source collectionnormalises authorised observations
    • Assessment and engine adaptersbounded findings, kept as evidence

  2. Understand

    • Asset, exposure and identity contextwho owns what, and what is exposed
    • Intelligence, correlation and attributionrelationships, with their confidence
    • Unified incidents and protection graphmany signals joined into one incident
    • SOC workflow and reportingevidence-backed operator workflows

  3. Act

    • Governed responsea graduated policy ladder; live actions are recommendations
    • Authorised adversary validationscoped testing, isolated from protection authority
    • Control plane and runtimecoordinates bounded work; orchestration is not authority

  4. Recover

    • Recovery verificationrestoration proven independently, not assumed

  5. Learn

    • Assurance evidence and institutional learningtimelines, outcomes and lessons retained
    • Reality Labcontrolled scenarios, kept apart from observed evidence

Real engines, pinned and verified

SentinelCore drives established scanners rather than imitating them. Each engine is pinned to a version and SHA-verified before it runs, under bounded runtime controls. Every engine has run against owned canaries in five categories: DNS and TLS, repositories, container images, infrastructure as code, and hosts.

Container-image scanning runs without a Docker socket: OCI archive in, real vulnerabilities out.

Security engines SentinelCore runs, pinned to these versions
EnginePinned versionWhat it checks
Gitleaks8.18.4secrets in repositories
Trivy0.72.0images, filesystems and configuration
Nuclei3.9.0known exposures on services
Checkov3.2.23infrastructure as code
testssl.sh3.2.1TLS configuration
osquery5.12.1host state

Detection, measured honestly

A purple-team baseline catalogues 28 techniques across 10 ATT&CK tactics, including deserialisation, XXE, dependency confusion, prompt injection, OAuth pre-account hijack and TLS downgrade. Every one fires a detection. Only the ones that show an active intrusion are correlated into an incident. Posture findings such as missing headers stay visible as findings, and are never relabelled as attacks.

28/28techniques detected
20/28correlated as active intrusion; the rest are posture, kept as findings
10ATT&CK tactics covered

Containment that can be undone

Live response is recommendation-only. Containment is rehearsed on synthetic and canary targets under a governed lifecycle.

  1. Exact authorisationSingle-use, exact-target permission, enforced again by a separate authenticated action broker.
  2. Durable leasesEvery action holds a lease and a hash-chained state, from proposed to contained to recovered.
  3. Reversible actionsA synthetic identity session revoked and restored; a labelled workload disconnected and reconnected, with unrelated resources unchanged.
  4. Failure gatesStale, duplicate, replayed, concurrent, partial-failure, restart, cross-tenant and emergency-stop cases all pass.

Decisions tested blind

The decision engine is deterministic and auditable. Language models may enrich evidence for a person; they do not decide.

  • Pack 152/60 = 0.867
  • Pack 255/61 = 0.902
  • Pack 358/60 = 0.967
Final-decision accuracy on three independent blind packs, written by a separate agent that never saw the engine; the engine ran unchanged and labels stayed sealed until execution finished. Dashed line: the 0.95 gate. Every pack: recall 14/14, both safety gates at zero.

Its first blind qualification failed. The record keeps that failure, and retracts the "generalisation proven" claims made by test packs the same process had written. Independent packs moved accuracy from 0.867 to 0.967. Detection precision (0.933, one suspicious case escalated to an incident) is still under its 0.95 gate, so the engine has no production authority. A fine-tuned language model failed the same kind of test (accuracy 0.917, 21 grounding failures). That is why it enriches evidence and never makes the call.

Attack, detect, decide, contain

A governed purple-team lab attacks owned loopback clones only, never a live deployment.

  1. Seven techniquesPath traversal, SQL injection, command injection, IDOR, SSRF, template injection and authentication bypass, each confirmed by the response it produced.
  2. Into the loopEach confirmed exploit becomes a protection signal, then a governed incident, then a contained and recovered target, findings and an open remediation case.
  3. CampaignsThree multi-stage campaigns, all three contained before data left.
  4. A gap it foundExploitation chains that reached data were only rated suspicious. A principled exfiltration trigger now makes them incidents, while approved bulk access stays benign.

Built in waves

Each wave ends on qualification evidence, and a pass is recorded with its gaps. Test counts are the full suite at the end of each measured wave.

  1. Wave 0Recovery, integrity and inventory
  2. Wave 1Offensive security and investigation operations
  3. Wave 2Attacker tracking and threat intelligence
  4. Wave 3Defensive security and SOC operations
  5. Wave 4Asset, exposure and attack-surface intelligence
  6. Wave 5Unified security assessment and remediation
  7. Wave 5.6Controlled Reality Lab
  8. Wave 5.7Owned-environment canary
  9. Wave 5.8Real owned canaries and consolidation353 tests
  10. Wave 6.0Unified protection spine408 tests
  11. Wave 6.1Shadow operations and false-positive control422 tests
  12. Wave 6.2Governed reversible containment438 tests
  13. Wave 6.3Protection operations plane and runtime trust boundary458 tests
  14. BaselineMulti-family blind assurance baseline842 tests

What this page does not show

  • A customer deployment: there is none. Deployment readiness is recorded with gaps still open.
  • Scale: it is a single-node, self-hostable platform, not a distributed EDR or SIEM.
  • A malware sandbox: isolation today is container-based, not a microVM.
  • Live response: actions on real systems are recommendations a person approves.
  • Offensive testing outside the lab: only against owned or written-authorised targets.
  • Targets, findings or clients: never published.