Sentinel MR Report
https://gitlab.com/jakubrojicek11/sentinel-mr-report/-/tree/main?ref_type=heads
See what changed before you ask an AI to review it.
Most code reviews start with a simple question:
«What changed?»
For humans, answering that can mean reading hundreds or thousands of lines of code.
For AI agents, it can be even harder.
They have to understand human-written code, remember what matters, identify security-sensitive operations, and then decide whether a change is safe.
Sentinel MR Report takes a different approach.
Instead of asking an AI to discover everything from raw source code, it first creates a small, deterministic description of what the code actually does.
Think of it as a fact layer between your code and your AI.
🚀 Try the open-source beta
This repository is an early, experimental open-source beta of that idea:
Sentinel MR Report
It is designed to run inside your GitLab CI pipeline.
You give it a merge request.
It compares the old and new versions of the changed JavaScript files and reports things such as:
- new HTTP routes
- new environment or configuration reads
- new filesystem operations
- new network calls
- new process execution
- changes in the risk surface
The result is a small report that a human can read and an automated system can consume.
Why build this?
I started building Sentinel while testing coding agents.
One problem became obvious very quickly:
AI agents are often asked to discover too much from raw source code.
They have to identify what changed, understand the surrounding code, find security-sensitive operations, and then reason about whether those changes matter.
Some of those observations do not need an AI.
A parser can establish many of them deterministically.
That led to a simple question:
«What if the AI didn't need to discover everything from scratch?»
The idea: give the AI facts first
Instead of sending thousands of lines of source code directly to a model, Sentinel can first extract structured facts from the code.
For example, instead of asking an AI to discover that a file now contains:
child_process
process spawning
filesystem access
network access
the deterministic analysis can simply tell it:
{
"process_spawn": true,
"child_process": true,
"filesystem_read": true,
"network_access": true
}
The AI can then reason about those facts.
The source code does not disappear.
It can still be used as a fallback when deeper reasoning is necessary.
The important idea is that the machine does the mechanical observation first, and the AI does the reasoning second.
What this repository does
The current beta focuses on one practical problem:
How did the risk surface of a merge request change?
For example:
Before
low risk
└── filesystem read
After
critical risk
├── filesystem read
├── child_process
└── process spawning
The report can show exactly which file caused the change and which operations were introduced.
It can also produce machine-readable JSON for other automation.
The analysis is based on Tree-sitter and the Git objects available inside your CI runner.
The same input produces the same result.
That makes the report predictable enough to use as part of an automated CI decision.
No AI. No telemetry.
This is an important part of the project.
The MR report itself does not send your source code to an AI service.
The current implementation is:
Your repository
│
▼
GitLab CI
│
▼
Tree-sitter
│
▼
Sentinel fact layer
│
▼
Human-readable report
There is:
- no LLM call
- no external analysis API
- no telemetry service
- no Sentinel account
- no remote source-code analysis
The analysis happens inside your CI environment.
That makes the project useful even if you don't want an AI anywhere near your source code.
And this is where Sentinel-IR comes in
The MR report is one practical application of a larger idea called Sentinel-IR.
The basic idea is simple:
«Don't make an AI rediscover facts that a deterministic program can extract reliably.»
Your source code contains enormous amounts of information.
But an AI does not necessarily need all of it for every task.
A fact layer can extract the parts that matter for a particular decision.
That can mean:
less context → fewer tokens → lower cost → less noise → more room for reasoning
In our live Sentinel-IR experiments, this approach produced substantial token reductions while retaining high accuracy, including a measured 70%+ reduction in input tokens in the tested workflow.
That result is a benchmark observation, not a promise that every repository or every AI task will save 70%.
The size and structure of the source code matter.
You can also use it as a CI gate
The report can optionally block a merge request when a change introduces a new critical operation.
For example:
old:
low
new:
critical
reason:
new child_process / process spawning
The important detail is that the gate reacts to the change, not simply the existence of a dangerous operation.
If a repository already legitimately uses process execution, the tool does not automatically treat every future edit to that file as a new critical event.
The intended risk can also be explicitly acknowledged in the repository.
That makes the decision visible and reviewable instead of hiding it inside an AI prompt.
The current gate exits with code "1" when a file's risk is raised to "critical", while simply remaining at an existing risk level does not trigger the block.
What it does NOT do
This project is intentionally narrow.
It does not claim to understand your entire program.
It does not replace a human security review.
It does not determine whether your business logic is correct.
It does not tell you whether your application is completely secure.
It currently focuses on JavaScript.
TypeScript and Flow-annotated JavaScript are not analysed by the current parser, and files that cannot be parsed are reported rather than guessed at.
That limitation is deliberate.
A deterministic tool should say:
«I don't know.»
rather than inventing an answer.
Why open source?
Because I don't want Sentinel to be a collection of impressive numbers in a blog post.
I want people to be able to run it.
Break it.
Find false positives.
Find false negatives.
Tell me where the idea fails.
And, ideally, improve it.
The repository is still an early beta. The code is not presented as finished enterprise software.
It is an experiment that has become useful enough to publish.
The interesting part is bigger than this repository
Sentinel started as a security experiment around autonomous coding agents.
The broader question became:
«What should an AI agent be allowed to believe about the world?»
If an AI says:
«"This code does X."»
Should we simply trust it?
Or can we first ask a deterministic system:
«"What facts can we actually establish from the code?"»
That distinction becomes increasingly important as AI agents gain the ability to modify code, call tools, deploy applications, access infrastructure, and make decisions on their own.
The goal is not to remove AI from the process.
It is to give the AI better ground truth to reason about.
Start small
You don't need to build a huge AI security system to experiment with the idea.
Add the GitLab CI job.
Run it on a few merge requests.
Read the reports.
See what it catches.
See what it gets wrong.
Then decide whether the fact layer is useful for your project.
The repository includes a copy-paste GitLab CI configuration and supports both human-readable and machine-readable output.
⚠️ Early beta
This is experimental software.
Expect rough edges.
Expect limitations.
And please report them.
A false positive is not an inconvenience to hide. It is useful information about where the analysis needs to improve.
The project is MIT licensed.
Clone it. Run it. Break it. Criticize it. Send a PR.
That's what open source is for.
One sentence version
Sentinel MR Report is a small, deterministic fact layer for GitLab that shows how the risk surface of your code changed before an AI, or a human, has to reason about the whole thing.
🙏 Feedback is welcome
This is my first open-source software project, so I know there is a lot I still have to learn.
If you try Sentinel MR Report, I would genuinely appreciate your feedback.
Especially from developers with more experience than me:
- What would you change?
- Where does the approach make sense?
- Where does it fall short?
- Did you find a false positive or a false negative?
- Would you actually use something like this in your CI pipeline?
- Is there a better way to structure the fact layer or the report?
Please tell me what I got wrong, not just what I got right.
You can leave feedback in the comments, open an issue, or send a pull request.
I'd rather discover the weaknesses of Sentinel from people actually using it than assume the first version is already good enough.
Thank you for taking the time to try it.
Top comments (1)
this is the right instinct, give the model facts instead of asking it to rediscover them from raw source. the CI gate reacting to a rise in risk rather than the mere presence of a risky op is the detail that makes it usable, nobody wants every future edit to a file that already does process spawning treated as critical. curious how it handles the same risky op getting introduced gradually across two separate commits instead of one, does the gate still catch it or does each diff look small enough to pass on its own