OUR STORY

We saw the gap before
anyone else was looking.

Sentinel was founded by practitioners who spent years working inside and alongside enterprise security and IT organisations. What we kept seeing — across every environment, every industry, every stack — was the same problem. The security teams were good. The tools were mature. But there was a layer nobody could see.

73%
of enterprise developers use AI tools their security team never approved
< 30s
is how long it takes a developer to connect an MCP server to production
0
existing security tools have native visibility into AI prompt traffic

THE PROBLEM WE FOUND

Security teams had coverage everywhere except where AI was actually running.

During our time embedded with security and IT organisations, we ran assessments, designed controls, and reviewed tooling across hundreds of environments. The teams we worked with were thorough — endpoint detection, network monitoring, SIEM pipelines, DLP. But when AI tools started appearing inside those same environments, every one of those controls had a blind spot.

Developers were connecting Cursor to codebases via MCP. Engineers were running local Ollama instances on 0.0.0.0. Finance teams were sending spreadsheets to ChatGPT. Models were accessing databases, pushing code, and querying internal APIs — and the security team had no record of any of it. Not because they weren't looking. Because the tools they trusted simply couldn't see there.

The SIEM was blind to MCP traffic
JSON-RPC over local sockets doesn't produce the kind of events a SIEM is configured to surface. Cursor talking to your codebase left no trace.
DLP couldn't read AI prompts
By the time prompt content hit the network it was inside encrypted TLS. Existing DLP tools had no hook into what was actually being sent.
Firewalls saw domains, not intent
api.openai.com gets through most enterprise proxies. Knowing a request went somewhere is very different from knowing what data left with it.
Approved tool lists were already obsolete
The approval process assumed tools were installed, not that they were npm packages executed inline with a single command.

WHY WE BUILT SENTINEL

The answer wasn't another alert. It was a new layer of visibility.

We didn't build Sentinel to add noise to a security team's day. We built it because the visibility gap was structural — and it required a purpose-built approach to close it. That meant operating at the kernel level, the network layer, and the MCP protocol itself.

01

Network and endpoint coverage

A VPC scanner that sweeps internal CIDRs and a lightweight endpoint agent that sees AI tools as they connect — not after the fact.

02

Deep MCP protocol analysis

We built tooling that speaks JSON-RPC natively, probing every discovered MCP server for authentication gaps, transport flaws, and dangerous capabilities.

03

Kernel-level prompt interception

An eBPF hook on SSL_write captures what developers are actually sending to AI APIs — before encryption — so DLP can run on the content that matters.

HOW WE WORK

We work with teams the way we wished vendors had worked with us.

Clarity over noise

Every finding Sentinel surfaces is something a security engineer can act on. We don't generate reports — we surface decisions.

Speed over process

You should have full visibility within your first hour. Deployment is a Docker container and a one-line agent install. No professional services engagement required.

Practitioners first

We were security engineers and IT operators before we were founders. The product reflects the questions we actually asked during incident response, not the ones on a checklist.

Long-term partnership

We onboard every organisation individually. Day one is a mapping session. Ongoing is a relationship — not a support ticket queue.

See what's already running
in your environment.

30 minutes. We'll map every AI agent and MCP server your team is running — including the ones nobody approved.