Thanks for support..
Release: "Sentinel-IR-MCP v0.2.2 on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir-mcp/-/tree/v0.2.2?ref_type=tags)

Package: "sentinel-ir-mcp@0.2.2 on npm" (https://www.npmjs.com/package/sentinel-ir-mcp/v/0.2.2)

3-minute read · A story about AI agents, trust, and the uncomfortable job of finding weaknesses.

Imagine you own a small café.

You install a smart security system. The front door is locked, employees have access cards, and every entrance is monitored.

You feel safe.

Then you hire an incredibly capable assistant. It can send emails, update orders, issue refunds, and communicate with other services. You tell it:

"Never issue a refund above $100 without my approval."

Sounds reasonable.

But what happens if one of the services the assistant can access checks that rule differently? Or if another path allows the same action without the approval you expected?

Your security system might work perfectly at the front door while another entrance remains unchecked.

Would you blame someone for testing that entrance before a real burglar finds it?

That's the question behind my work on Sentinel.

The uncomfortable truth about AI agents

We're building systems that can do more than answer questions. They can use tools, access data, make decisions, and take actions.

That creates enormous opportunities. It also means that a misunderstanding, an unexpected tool combination, or a missing permission check can have consequences beyond a bad answer in a chat window.

And this isn't just a theoretical concern.

In 2025, the research paper "CVE-Bench" (https://proceedings.mlr.press/v267/zhu25i.html) reported that an evaluated state-of-the-art agent framework could exploit up to 13% of the vulnerabilities in its benchmark of vulnerable web applications.

In 2026, the UK's AI Security Institute reported results from testing 22 frontier AI agents across 44 deployment scenarios. The competition collected more than 60,000 successful policy violations from 1.8 million submitted prompt-injection attacks.

These results don't mean that every AI agent can break into every system. They don't mean your application is automatically vulnerable.

They mean something more practical: we cannot assume that a security rule works simply because we wrote it down. We need to test whether it holds under pressure.

So why build systems that expose weaknesses?

Fair question.

If a system can discover a weakness, couldn't someone misuse that capability?

Yes. Security research is a dual-use field. The same discovery can help a developer fix a vulnerability or help an attacker understand it.

That's precisely why the environment, permissions, and purpose matter.

Testing an authorized system in a controlled environment is different from attacking someone else's production service. We should reproduce failures safely, document what happened, avoid exposing secrets, and give developers a chance to fix the problem.

The goal isn't to make breaking things easier for everyone.

The goal is to make dangerous assumptions harder to ignore.

Where Sentinel fits in

I don't believe we should ask an AI agent to be its own security guard.

An agent can recommend an action. That doesn't mean it should automatically have the authority to execute it.

The Sentinel concept is about making AI systems easier to examine, introducing independent checks, and separating what an agent wants to do from what it is actually allowed to do.

The public Sentinel-IR package is one part of that work. It provides structured code analysis. It is not a complete security scanner or a universal firewall, and I won't pretend otherwise.

There is still a lot to build, test, and improve.

But the principle matters already: permissions should be enforced, dangerous changes should be checked, and important failures should leave evidence we can examine.

We're on the same side

We're not trying to become enemies of existing software, AI models, or the developers building them.

We're trying to help make their limitations visible while there is still time to address them.

You don't have to trust Sentinel because I built it. You should be able to examine the tests, question the results, reproduce the failures, and tell me where the approach is wrong.

I'd rather hear "your test found nothing" or "your proposed protection failed" today than discover a serious weakness after a real user has paid the price.

A security researcher pointing at a broken door isn't the burglar. But ignoring the warning doesn't repair the lock.

So here's my question to everyone building AI agents:

When your agent can take real actions, what evidence would convince you that your security controls are actually working?

Not what the prompt promises. Not what the documentation says.

What would you test?