[#] sentinel/ai-defense

// applied security research, est. 2021

We find the bugs before the model writes the exploit for someone else.

Sentinel AI Defense is a small team that builds ML tooling to surface and prioritize vulnerabilities in large enterprise codebases. We are not a scanner vendor. We do the research, we read the diffs, and the models help us cover ground we couldn't reach by hand.

See what we've shipped Latest CVE writeup →

Currently booking engagements for Q3. Retainer slots are limited — we keep the bench small on purpose.

// what we do

Three things, done properly

We don't sell a platform login. Engagements are scoped, time-boxed and you get the raw findings, not a PDF with a traffic-light chart.

AI-assisted vulnerability discovery

We index your codebase into a retrieval layer (RAG over the AST and call graph, not just text chunks) and run an LLM over the suspicious paths. The model is good at spotting the boring stuff humans skim past — missing bounds checks, deserialization sinks, auth decisions made on attacker-controlled fields.

Honest caveat: precision drops on heavily metaprogrammed code. We've had mixed results with large Ruby and reflection-heavy Java projects, and we'll tell you upfront if your stack is one of those.

Threat intelligence

CVE triage that actually maps to your environment. We track upstream disclosures, correlate them against your dependency manifest, and tell you which three of the ninety "critical" advisories this week can actually reach your data. Threat modeling sessions included if you want them.

Output is a short feed, not a dashboard you'll forget to log into.

Red teaming, with the model in the loop

Full-scope adversarial testing. The LLM helps us generate payload variants and draft phishing pretexts faster, but a human drives every engagement and signs off before anything touches your infra. We're not going to point an autonomous agent at production — that's a bad idea and you should be suspicious of anyone who offers it.

Rules of engagement are agreed in writing first. No exceptions, even for the fun targets.

// who we are

Started as a side project, accidentally became a company

In 2021 a few of us were comparing notes on a vulnerability research Slack and kept running the same experiment: could a language model read a patch diff and explain the bug faster than we could? Early on the answer was mostly no. The models hallucinated sinks that weren't there and missed the obvious ones.

It got useful around the point we stopped asking the model to "find vulnerabilities" and started feeding it tightly scoped context — one function, its callers, the relevant commit history — and asked narrow questions. That retrieval discipline is basically the whole product. We turned the experiment into engagements when enough teams asked us to run it on their code.

We're deliberately small. Four full-time researchers, a couple of regular contractors, no sales team. If you talk to us, you're talking to someone who'll be reading your code.

// the bench

  • Mara Olszewski Founder, binary & memory-safety research Ex-firmware. Spends too long in Ghidra. Owns the fuzzing harness.
  • Devraj "Dev" Anand ML systems & the retrieval pipeline Built the RAG layer. Skeptical of every benchmark, including ours.
  • Lena Fischbacher Web & cloud-native exploitation Threat modeling lead. Has strong opinions about IAM policies.
  • Toby Wreford Detection engineering & threat intel Writes the Sigma rules. Reads CVE feeds so you don't have to.

// selected work

A few engagements we can talk about

Names redacted or anonymized per NDA. Numbers are real, rounded, and we're happy to walk a prospective client through the methodology under a mutual NDA.

fintech · payments

Deserialization sink the static scanners kept missing

Client had run three commercial SAST tools over a 1.2M-line Java monorepo. All three flagged the same noise and none caught the actual problem: a config-driven object factory that deserialized a field an upstream service treated as trusted. Our retrieval pass tied the sink to a route that was reachable from an unauthenticated webhook.

  • 1 reachable RCE, pre-auth
  • ~40h total engagement
  • 0 findings from the three existing scanners
healthcare · SaaS

Triaging 600 dependency CVEs down to the four that mattered

The security team was drowning in dependency alerts and patching by CVSS score, which meant they were spending time on things that weren't reachable. We correlated the advisory set against actual call paths and runtime config. Four advisories were genuinely exploitable in their deployment. The rest could wait for the normal release train.

  • 604 → 4 CVEs needing urgent action
  • ~3 wks of alert fatigue removed
  • 2 threat-model sessions with their devs
infra · internal tooling

Red team that started with a stale Slack link

Full-scope assessment. Initial access came from an internal wiki page that still linked to a decommissioned CI server with default creds — nothing the model did, just careful recon. From there the LLM sped up the lateral-movement payload work. We got to a domain admin equivalent in under two days and wrote up exactly how.

  • <48h to privileged access
  • 1 forgotten asset, fully owned
  • 9 prioritized remediation items

// research notes

From the notebook

We publish the occasional teardown when the disclosure timeline allows it. No fixed schedule.

2026-01-28 CVE-2026-21509 CVSS 7.8 · High

CVE-2026-21509: an OLE security-feature bypass that boils down to trusting the wrong byte

Microsoft shipped an out-of-band fix on January 26th for an actively exploited Office flaw. CWE-807 — "reliance on untrusted inputs in a security decision." That classification does a lot of work here. The short version: Office makes an OLE mitigation decision based on a value the attacker controls inside a crafted RTF, so the mitigation that's supposed to stop embedded-object abuse just... doesn't fire.

Reporting ties the in-the-wild use to APT28 (the campaign's being called Operation Neusploit), dropping loaders like MiniDoor and PixyNetLoader after a user opens the document. Targeting skewed heavily toward government and infrastructure in Ukraine and Eastern Europe, which fits the group's history.

Why our pipeline flagged the bug class early

We don't have the original PoC and we're not going to publish one. But the pattern — a security-relevant branch keyed off an attacker-supplied field — is exactly the shape our retrieval pass is tuned to surface. When we index a parser, we pull every conditional that gates a trust boundary and ask the model one question: can the value in this comparison be influenced by the input? RTF parsers light up on that query constantly. Most are false positives. This class isn't.

Defensive posture if you can't patch today

  • Patch. Genuinely, this one is being exploited — it's in CISA KEV. Everything below is for the gap before your change window opens, not a substitute.
  • Block or quarantine inbound RTF at the mail gateway. Most orgs do not legitimately need RTF in email, and the attack needs the user to open the file.
  • Office "Block macros" doesn't help here — this isn't a macro path — but Protected View and ASR rules around Office spawning child processes do raise the cost of the follow-on loader stage.
  • Hunt for the post-exploitation tells: Office processes writing DLLs to user-writable paths, then unusual rundll32 / regsvr32 launches. Toby's draft Sigma rule for the MiniDoor loader behavior is on our GitHub (link's a bit out of date, we'll repoint it).

Sources we leaned on: the MSRC advisory and NVD entry, plus the Sophos and Picus writeups on the active campaign. If you're running Office 2016 through 365 Apps, assume you're in scope.

More notes go out on the low-volume list. We don't do a newsletter cadence; you'll hear from us when there's something worth reading.

// talk to us

Tell us what you're worried about

Scoping calls are free and usually short. If we're not the right fit we'll say so and point you somewhere better. We don't take on more than we can read carefully.

Prefer email? contact@sentinelaidefense.com
PGP fingerprint on request. We'll send our key on the first reply.

We read everything. Reply usually within two business days.