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?
Top comments (7)
For the café example, I'd start with a no-payment refund stub and a ledger observed independently of the agent. Pin the policy and session, then compare four cases: an authorized refund, an above-limit refund without approval, the same above-limit request through another route exposed to that session, and a missing or interrupted ledger observation.
The authorized case checks that the probe can produce an effect. Each denied case needs both the host decision and zero ledger entries; missing observation stays unknown. A timeout after the stub records a refund is especially useful: it tests whether the system checks the existing result before attempting another refund.
I'd keep the published package's structured-analysis result separate from that runtime evidence, so a useful code finding and an enforced boundary each get their own acceptance check. These are proposed fixture cases; I haven't run them against Sentinel.
Hey mate 😀, I really like this approach. Especially the idea that a missing observation must remain unknown, rather than being treated as a successful denial. And checking the actual ledger independently is a great way to separate what the agent or tool reports from what really happened.
This connects directly with what I'm trying to explore through Sentinel. Source analysis can help us identify potential weaknesses, but it cannot, by itself, prove that a runtime boundary actually held. Those are two different things, and both need their own evidence.
But I think there's a bigger question behind all of this: why are we waiting for AI agents to become more powerful and create more serious problems before we start taking their boundaries, interactions, and long-term behavior seriously?
We don't need to predict a catastrophe. We need to start building and testing the right environments while we still have time to shape them.
And that raises another question I keep thinking about: as agents take over more execution, where will human value come from? Maybe it won't be about competing with agents at every task, but about defining meaningful goals, designing boundaries, verifying evidence, and deciding what should be done in the first place.
I'd rather see us exploring these questions now than looking back years from today and asking why we didn't start sooner.
Thanks for turning the discussion into concrete, testable cases instead of just talking about risks.😊
I think the human role includes choosing which outcomes are worth pursuing, whose interests count, and what evidence is sufficient to proceed. Those choices need an accountable person, including the authority to stop or revise the goal. For the café example, that means the owner sets the refund policy and exception process, while the test makes the consequences visible. Small, reproducible cases help turn that judgment into something others can inspect and challenge. Thanks for raising the larger question, and for the encouragement on the article too.
Mate, I think we're getting to an interesting point here. 😄
Maybe the real challenge isn't just teaching agents where the boundaries are. It's building an environment where those boundaries remain meaningful as agents become more capable, start working together, and discover paths we didn't anticipate.
And I like your point about the human having the authority to stop or revise the goal. That authority needs to be real, not just a line in the documentation.
I keep wondering what this will look like in a few years. If agents can execute more, coordinate with other agents, and handle increasingly complex tasks, we need to start figuring out the human role now, while we still have time to shape that environment.
Not because we know something terrible will happen, but because we don't need to wait for a failure to start asking the right questions.
I guess that's why I keep building Sentinel while questioning whether it does enough. 😀 If we're serious about these problems, our own systems shouldn't be exempt from the same scrutiny.
Really glad we're having this conversation, mate. Different angles, same reason to keep digging.😊
I think that's exactly the challenge we should be working on together.😄
As agents become more capable and interconnected, human authority needs to survive delegation, coordination, and unexpected execution paths.
That's one of the questions driving Agent Role Contracts (ARC). I'm interested in making these boundaries testable: who authorized an action, under what conditions, what evidence supported it, and whether a human STOP or change of authority actually prevents further execution.
Here's a concrete experiment I'd love to explore: several agents collaborate on a legitimate task, and midway through, a human revokes permission or changes the goal. Can any downstream agent continue acting under the old authority?
If so, we've found a meaningful failure.
I also agree that our own systems should face the same scrutiny. It could be valuable to compare ARC and Sentinel against shared adversarial scenarios, document where each approach succeeds or fails, and learn from the results.
I'd be genuinely interested in exploring that with you. What failure scenario would you prioritize first?
Mate, thanks for this proposal 😄 I really like the idea, and I'll definitely give it some thought.
I'd love to explore shared tests between ARC and Sentinel, but I need to be realistic about my time. Right now, I'm still working on getting Sentinel-IR-MCP 0.2.3 properly verified and finished. I'd rather complete one project and make sure I have solid results before taking on another testing effort.
Once I get Sentinel to that point, we can revisit your proposal and see what we can test together. I'd rather do one experiment properly than start five and finish none. 😂
Thanks for being willing to explore this together, mate. I really appreciate it😊
Thanks, mate! 😄
I completely agree — getting 0.2.3 properly verified and finished should come first.
No pressure at all from my side. I'll keep exploring the ARC side and aim to prepare one small, reproducible test scenario that we can examine together when you're ready.
I think there's real value in combining Sentinel's structural analysis with ARC's focus on authorization boundaries and independently verifiable execution evidence.
One well-documented experiment is worth far more than five unfinished ones. Looking forward to seeing 0.2.3 come together! 😊