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)
The AI Was Wrong. Then It Explained Why. That’s the Bigger Risk.
One misunderstood sentence, one confident explanation, and one hypothetical disaster. Why AI agents need independent security controls, and how Sentinel approaches the problem.
The whole article in 30 seconds
An AI assistant misunderstood a casual sentence about saving an idea to permanent memory. When asked to explain the mistake, another AI produced a confident explanation involving language, context, and mathematical predictions. It then described a hypothetical scenario in which an AI agent could misunderstand a request and delete important files.
Three different problems appeared in one conversation:
- Misinterpretation: The AI may misunderstand what a person means.
- False confidence: The AI may explain its mistake with claims that have not been verified.
- Unsafe execution: An agent may turn a mistaken interpretation into an action if its permissions allow it.
The first two problems concern how AI interprets and explains information. The third concerns security engineering.
My work on Sentinel explores a practical response: give AI structured evidence, check code changes against explicit rules, and separate an AI's recommendations from the authority to execute dangerous operations.
Don't ask AI to be its own security system. Build controls that still work when AI gets something wrong.
Part 1: About 10 minutes, for everyone
- The original mistake was small. The lesson wasn't.
Let's start with a real conversational misunderstanding.
During a conversation, I used this Czech sentence:
«„To nechci 🤣 uložit do paměti natrvalo..“»
The assistant interpreted it differently from what I intended.
It was an ordinary conversation about an idea, not a security incident. No files were deleted, no computer was taken over, and no dangerous tool was executed.
That distinction matters.
The interesting part isn't that an emoji somehow broke artificial intelligence. We don't have access to the model's internal calculations, so we cannot honestly claim to know the exact mechanism behind this particular mistake.
The interesting part is what happened next.
I asked another AI to explain the situation and the potential implications for AI agents. Its answer raised a legitimate concern: a misunderstanding that is harmless in a conversation can have much more serious consequences when an AI agent has permission to take actions.
But the answer also went further. It described supposed internal mechanisms with more certainty than the available evidence justified, then presented a hypothetical scenario involving the deletion of important project files.
This gave me a more useful question to investigate.
What happens when AI not only gets something wrong, but also produces a convincing explanation that makes the mistake look understood?
And what happens when an agent has the tools to act on that mistake?
- Three problems hiding in one conversation
Imagine three warning lights on a dashboard. Each indicates a different failure, and fixing one does not automatically fix the other two.
Warning light 1: The AI misunderstands you
You say:
"That old test isn't needed anymore. Let's get rid of it."
What exactly do you want removed?
One test? The entire test file? An obsolete test directory? The whole testing framework?
A human might ask a follow-up question because the consequences are unclear. An AI might also ask, but it might instead choose one interpretation and continue.
AI systems can be remarkably capable at understanding language. They can also misread ambiguous instructions, lose track of context, or produce an answer that doesn't match the user's intention.
The important distinction is between what the user intended and what the AI inferred.
Those are not necessarily the same thing.
Warning light 2: The AI confidently explains its own mistake
Now suppose you ask the AI why it misunderstood you.
It replies that an emoji changed the attention weights, the mathematical representation shifted toward negation, and the model's prediction mechanism therefore selected the wrong meaning.
That explanation might sound plausible to someone familiar with machine learning.
But unless those internal computations have actually been examined, it is not an established explanation of the specific event.
A language model can describe how language models generally work. That doesn't mean it has direct access to a faithful causal explanation of its own previous response.
This distinction is easy to miss because an AI can explain things fluently even when some of its claims are wrong.
We therefore need to separate three things:
- What we directly observed.
- What we think might explain it.
- What we have actually verified.
A confident paragraph is not a substitute for that separation.
Warning light 3: The mistake becomes an action
Now give the assistant access to your computer.
Instead of merely discussing your project, it can read files, edit code, execute commands, or delete directories.
Suppose it misunderstands your request and selects the wrong directory for deletion.
The consequence depends on the permissions it has, the tools it can access, and the controls around execution.
A deletion is not inevitable. The agent might request confirmation, a tool might reject the request, or a sandbox might limit the damage.
But if the action is permitted and the safeguards fail, the original misunderstanding can become a real incident.
Notice the difference: the first error happened in language; the dangerous outcome requires additional failures in the system around the model.
That is why this isn't simply a story about AI being unreliable.
It is a story about what happens when unreliable interpretation is connected to powerful capabilities without sufficient safeguards.
- Why we shouldn't trust an AI agent blindly
An AI agent is a system that can use tools to work toward a goal. Depending on its design, it may search documents, edit source code, call APIs, or interact with other applications.
The more tools it has, the more important its permissions become.
Think of a person who starts a new job.
They might be brilliant at investigating problems. That doesn't mean they should automatically receive administrator access to every computer in the company.
You would give them access to what they need. You would restrict sensitive operations. You would check important changes. You would expect a record of what happened.
Why should an AI agent be treated differently?
The problem isn't that AI literally has no moral programming or can never recognize a dangerous request. Models can be trained to refuse certain tasks and to ask questions when information is unclear.
The problem is that model behavior is not the same thing as an enforceable security boundary.
An instruction such as "never delete important files" can influence an AI's behavior. It cannot, by itself, establish that the program executing its tool calls is technically unable to delete those files.
For that, we need actual access controls.
- Separate the suggestion from the permission
This is the most important principle in the article.
Imagine your AI says:
"I should delete "old-tests/" because these files appear obsolete."
That sentence is a proposal, not an authorization.
A safer system separates the process into three stages.
Stage one: the AI proposes.
The model identifies a potential solution and explains its reasoning.
Stage two: an independent policy checks.
Trusted application code examines the requested operation. Is the target within the permitted workspace? Is this tool allowed? Is the action destructive? Does it require additional authorization?
Stage three: the execution layer enforces the result.
The operation is allowed, rejected, or sent for explicit approval.
The AI cannot override the policy simply by claiming that the action is necessary.
This matters because the policy can be written, tested, reviewed, and changed under controlled procedures. Its behavior does not need to depend entirely on the model choosing the right interpretation every time.
A simplified example:
Proposed action| Possible policy
List files in an approved project| Allow
Read a file in the approved workspace| Allow, subject to path and access checks
Modify a project file| Permit only within defined write boundaries
Delete an important directory| Require explicit authorization or block
Execute an arbitrary shell command| Block by default or permit only through a tightly controlled execution mechanism
Read unrelated credentials| Deny
These are illustrative policies, not a universal classification. The right restrictions depend on the system's purpose and threat model.
The important point is that the decision happens at a trusted boundary, not merely inside the AI's generated text.
- Where Sentinel fits into this picture
This is the problem I work on with Sentinel.
Rather than assuming the model will always understand the source code and behave correctly, we can give the system structured evidence and use explicit rules to check important changes.
There are two different pieces worth understanding.
Sentinel-IR: give the AI a structured map
When an AI coding agent needs to inspect a source file, it is not always necessary to pass the entire file to the model for its initial analysis.
Sentinel-IR analyzes JavaScript and produces a compact structural representation of selected facts about the code. These can include recognized operations, imports, environmental access, and evidence associated with potential risks.
You can think of it as giving an inspector a floor plan before asking them to investigate a building.
The floor plan doesn't prove that the building is safe. But it provides structured information that can be checked and discussed.
Sentinel-IR aims to make source-code analysis more focused and reproducible, while reducing how much raw source text needs to be placed in an AI prompt.
Public project: "Sentinel-IR on GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir).
Sentinel's security gate: check what changed
The other piece is the security gate.
Instead of relying exclusively on an AI-generated opinion about a proposed code change, a gate can compare structural facts before and after the change and apply explicit rules.
For example, a gate may identify that a JavaScript file has gained the ability to start other processes or execute dynamically supplied code. Depending on the configured policy, the change can be blocked before it is merged.
This does not guarantee that every dangerous change will be detected. A static analyzer has limitations, and a policy only enforces the cases it actually covers.
But it gives us something important: an enforceable check with a defined outcome.
Read the technical explanation here:
"Security Regression Gate Sentinel: block the rise, not the presence" (https://dev.to/jackymencz/security-regression-gate-sentinel-block-the-rise-not-the-presence-42ka).
The broader principle is straightforward:
Let AI help investigate and recommend. Use independent controls to decide which operations are permitted.
Part 2: The developer deep dive, about 20 minutes
The previous section explained the idea without assuming a programming background. Let's now turn it into engineering practice.
- The architecture: don't put the model in charge of its own permissions
A basic agent architecture often looks like this:
User request
|
v
AI agent / language model
|
v
Proposed tool call
|
v
Trusted policy enforcement
|
+----> Reject
|
+----> Require approval
|
+----> Allow within scope
|
v
Controlled tool execution
|
v
Result and audit record
The model can recommend a tool call, but it does not get to determine its own privileges.
In practice, this means every call to a sensitive tool must pass through the enforcement layer. It is not enough to check a request in one interface and leave an alternative execution path unprotected.
The policy should validate the actual operation and arguments, the requesting identity, the target resource, and any necessary authorization.
This is consistent with the "OWASP AI Agent Security Cheat Sheet" (https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), which recommends enforcing authorization outside the agent's context and binding approval to the exact action being approved.
- A small example: allow only explicitly permitted tools
Here is a deliberately minimal JavaScript example of an enforcement boundary.
It allows only two specifically named tools to run automatically. Everything else is denied unless the application implements a separate, trusted authorization workflow.
const AUTO_ALLOWED_TOOLS = new Set([
"list_project_files",
"read_project_file"
]);
function authorizeToolCall(call) {
if (
!call ||
typeof call.name !== "string"
) {
return {
allowed: false,
reason: "Malformed tool request"
};
}
if (!AUTO_ALLOWED_TOOLS.has(call.name)) {
return {
allowed: false,
reason: "Tool is not on the auto-allowlist"
};
}
return {
allowed: true,
reason: "Explicitly allowlisted tool"
};
}
async function executeToolCall(call, tools) {
const decision = authorizeToolCall(call);
if (!decision.allowed) {
throw new Error(
Blocked by policy: ${decision.reason}
);
}
const handler = tools[call.name];
if (typeof handler !== "function") {
throw new Error(
"No trusted implementation registered for tool"
);
}
return handler(call.arguments);
}
module.exports = {
authorizeToolCall,
executeToolCall
};
This example demonstrates one principle: an unknown or unapproved tool does not become authorized simply because the model requested it.
However, this is a teaching example, not a production-ready agent security framework.
The actual application must also validate each tool's arguments and enforce permissions inside the tool implementation. For example, "read_project_file" must genuinely restrict access to approved files. A malicious path or symbolic link must not let it escape the intended workspace.
The trusted application must also protect the execution registry itself. If an untrusted process can replace the registered handlers, the allowlist alone is insufficient.
And read-only tools are not automatically harmless. Reading a sensitive file and then sending its contents to an external service can still expose data.
The lesson is not that a small function solves agent security. It is that authorization belongs in trusted code outside the model's generated answer.
For destructive actions, implement a separate approval path that binds the approval to the precise tool, arguments, user, and time window. Do not let the model supply its own approval flag.
- Analyze JavaScript before treating it as understood
Now let's look at Sentinel-IR.
Install the specific published release:
npm install --save-exact sentinel-ir@0.1.3
The package requires Node.js 20 or newer. Its public implementation focuses on JavaScript structural analysis.
Here is an example based on the published API:
const {
analyzeAsync,
compress
} = require("sentinel-ir");
async function inspectSource() {
const source = `
const cp = require("child_process");
const run = cp.execSync;
const runAgain = run;
runAgain("example");
`;
const result = await analyzeAsync(source, {
target: "example.js"
});
console.log(
JSON.stringify(compress(result), null, 2)
);
if (
result.analysisStatus !== "complete" ||
result.facts?.ast !== true
) {
throw new Error(
"Analysis incomplete. Do not treat this result as clean."
);
}
if (result.facts.operations.processSpawn) {
throw new Error(
"Process-spawning behavior detected. Policy review required."
);
}
}
inspectSource().catch(error => {
console.error(error.message);
process.exitCode = 1;
});
The example analyzes a string representing JavaScript source. It does not execute the "runAgain("example")" expression.
It demonstrates two useful ideas.
First, an analyzer can connect selected alias chains to the capability they represent. In this example, the name "runAgain" is associated with a process-spawning method through multiple assignments.
Second, the result is not accepted blindly when structural analysis is incomplete.
That second point is easy to overlook.
A tool may produce some output even if it cannot fully analyze the source. A consumer should not automatically interpret an incomplete result as a successful security check.
Sentinel-IR's 0.1.3 release adds tested support for selected alias chains, scope-sensitive shadowing cases, indirect "eval", and bracket notation for environment-variable access.
The published release article documents 79 passing repository tests and ten targeted consumer smoke tests. Those are results from specific tests, not evidence that every JavaScript program can be fully understood.
The package also does not prove that a detected operation is malicious. Recognizing a process-spawning capability and proving that a particular execution will cause harm are different tasks.
Full technical walkthrough:
"Sentinel-IR 0.1.3: Better AST Alias Detection" (https://dev.to/jackymencz/sentinel-ir-013-is-live-better-ast-alias-detection-termux-mobile-android-1270).
- The next layer: stop dangerous code changes before merging
Structural analysis can become part of a larger development workflow.
A useful example is a security regression gate that compares the code before and after a merge request.
Suppose a file has been able to read a configuration file for months. A patch fixes a spelling mistake.
It would not be helpful if every change triggered the same generic warning simply because the file already had some potentially dangerous capability.
A change-aware gate asks a more specific question:
What new capability did this change introduce?
Consider the following example.
Before:
function formatReport(report) {
return report.trim();
}
After:
const { execSync } = require("node:child_process");
function formatReport(report) {
execSync(report);
return report.trim();
}
This is an intentionally simplified example. The second version introduces process-spawning behavior using data from a function argument. That deserves careful investigation and, under a strict policy, should be blocked.
A security gate can identify the new process-spawning capability and compare the resulting risk level with the baseline.
It does not need to ask an LLM whether the code "looks suspicious" before it can apply the configured rule.
The actual outcome still depends on the analyzer, policy, threshold, and implementation. No static analysis tool can promise to recognize every dangerous program.
The public Sentinel security-gate article documents a change-aware model that evaluates before-and-after structural facts and can block configured critical-risk regressions.
It also documents specific limitations, including changes that increase risk gradually without reaching the configured threshold and behaviors that span multiple files.
Those limitations matter. A critical-only gate can miss a sequence of changes that moves a file from low to medium risk and later from medium to high risk, without ever reaching critical. The policy must be configured to catch the risks relevant to the project.
- Put the check in CI, where failure has consequences
A report is useful only if the development workflow reacts to it appropriately.
For example, a GitLab merge-request job can run a security report and fail the pipeline when the configured gate blocks a change.
The published Sentinel gate article includes this example:
mr_report:
stage: benchmark
variables:
GIT_DEPTH: 0
script:
- git fetch --quiet origin "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
- set -o pipefail
- npm run mr-report -- --base "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" --gate critical | tee mr-report.md
artifacts:
when: always
expire_in: 1 month
paths:
- mr-report.md
allow_failure: false
This configuration illustrates several important details.
- "GIT_DEPTH: 0" makes the complete Git history available for the comparison workflow.
- The target branch is fetched so that the report can compare the change against the intended baseline.
- "set -o pipefail" prevents a failing report command from being hidden by a successful "tee" command.
- "allow_failure: false" makes a failed job blocking rather than treating it as an optional warning.
The "benchmark" stage must exist in the project's configured stages, and the report command must exist in the repository. Adjust these settings to the actual project.
The important property is that the check can affect whether the change proceeds. A security report that nobody is required to act on is not equivalent to an enforced merge gate.
The published article reports 639 passing tests in its October 12, 2026, test run and a deterministic replay across 118 previously merged changes in the Sentinel repository, with three changes blocked by the configured critical gate.
These are measurable results from that repository and evaluation. They are not proof that the gate will catch every future vulnerability or prevent every real-world incident.
Read the implementation and its documented limitations:
"Security Regression Gate Sentinel: block the rise, not the presence" (https://dev.to/jackymencz/security-regression-gate-sentinel-block-the-rise-not-the-presence-42ka).
- MCP expands the problem beyond code
What if an AI agent doesn't just edit JavaScript?
What if it calls tools exposed through the Model Context Protocol (MCP), accesses company data, sends emails, queries databases, or interacts with remote services?
Then source-code analysis alone is not enough.
MCP provides a standardized way for AI applications to communicate with tools and data sources. It does not automatically guarantee that every connected tool is safe or every operation is authorized.
For MCP-based systems, consider at least six areas.
Tool permissions. Each tool should have only the access it needs. A read-only document assistant should not automatically receive permission to send emails, alter financial records, or administer a server.
Tool definitions. Names, descriptions, parameter schemas, and other metadata can affect how an AI uses tools. Review them, track changes, and re-evaluate when an approved definition changes.
Untrusted content. Webpages, documents, retrieved code, and tool outputs can contain instructions designed to manipulate an AI. Those instructions must not automatically become authorized tool calls.
Argument validation. Validate the actual tool arguments. A syntactically valid path may still escape the permitted workspace. A valid URL may still target an internal service that the caller should not reach.
Execution-time authorization. Verify permissions where the operation actually executes. Do not depend solely on the AI's explanation of why an operation should be allowed.
Human approval and auditability. Destructive, financial, externally visible, and sensitive operations often require stronger authorization, an explicit preview, and a protected audit record.
These recommendations are consistent with the "OWASP MCP Security Cheat Sheet" (https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) and the "OWASP AI Agent Security Cheat Sheet" (https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html).
The U.S. National Security Agency also published "MCP security design considerations for AI-driven automation" (https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-AI-driven-automation-leveraging/) on May 20, 2026. Its guidance highlights the importance of trust boundaries, authorization, input validation, and the risks created when AI systems dynamically invoke tools.
The "OWASP Top 10 for Agentic Applications 2026" (https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) provides another useful starting point for identifying risks in systems that plan, use tools, and take actions.
These are practical references for developers building more than a simple chatbot.
- What would a responsible agent deployment require?
Before allowing an AI agent to modify an important system, I would want clear answers to these questions.
Can the agent access more than it needs?
If yes, restrict its permissions.
Can untrusted content directly trigger a sensitive action?
If yes, separate retrieved content from trusted instructions and validate every proposed operation at the execution boundary.
Can the agent execute an arbitrary command?
If yes, consider replacing unrestricted command execution with narrowly defined tools, argument validation, and a suitable sandbox.
Can it delete data or send sensitive information without a trusted authorization step?
If yes, design an explicit approval mechanism and enforce it independently of the model.
What happens when analysis fails?
An incomplete report must not silently become a clean bill of health.
Can you determine what actually happened?
Keep appropriate audit records while protecting secrets and personal information from unnecessary exposure.
Can you recover?
Use backups, reversible changes, transaction boundaries, or other appropriate recovery mechanisms. Have a tested way to stop execution.
These controls cannot eliminate every security risk. But they reduce reliance on the hope that an AI will always interpret every instruction correctly.
- The actual role of Sentinel
I don't want to present Sentinel as an all-powerful security shield. That would contradict the very lesson this article is trying to teach.
Sentinel-IR focuses on JavaScript source analysis. It provides compact structural evidence that another component can use when reasoning about code.
Sentinel's security-gating approach focuses on explicit rules for identifying and blocking specified dangerous changes.
These are complementary ideas, but they are not interchangeable.
Structural facts are not complete program semantics. A source-level finding is not proof that an exploit exists. A gate with a defined threshold cannot catch a type of risk that its rules and analysis do not cover.
And neither component, by itself, implements all the safeguards an AI agent needs when it can interact with external tools, files, accounts, or production infrastructure.
The value is in the architecture: use tools that produce inspectable evidence, enforce specific policies, and keep the model from being the sole authority over sensitive actions.
For the public implementation of Sentinel-IR, start here:
- Source code: "GitLab" (https://gitlab.com/jakubrojicek11/sentinel-ir)
- Published package: "sentinel-ir 0.1.3 on npm" (https://www.npmjs.com/package/sentinel-ir/v/0.1.3)
- Architecture for everyone: "Don't feed the whole file to the AI: meet Sentinel-IR" (https://dev.to/jackymencz/dont-feed-the-whole-file-to-the-ai-meet-sentinel-ir-8cp)
- Security regression gate: "Block the rise, not the presence" (https://dev.to/jackymencz/security-regression-gate-sentinel-block-the-rise-not-the-presence-42ka)
The public package is a focused building block, not the entire Sentinel system.
Final thought: don't confuse confidence with correctness
Let's return to the original conversation.
The assistant misunderstood a sentence. Another AI offered an explanation that sounded convincing, but some of its causal claims could not be established from the conversation alone. It then described a hypothetical situation in which an agent could cause real damage.
Those are three separate things: an observed mismatch, an unverified explanation, and a possible consequence.
Keeping them separate is important because the same discipline applies to security engineering.
Don't treat a generated explanation as verified evidence. Don't treat an agent's confidence as authorization. Don't treat a security report as proof of safety beyond what it has actually checked.
Instead, test assumptions. Document limitations. Check changes. Restrict access. Enforce authorization outside the model. Make high-impact actions difficult to trigger accidentally.
The aim is not to create an AI that never makes a mistake. The aim is to build a system in which one mistake does not automatically become a disaster.
That's why I believe we should spend more time securing AI agents, not merely making them more capable.
And that's the problem Sentinel is designed to help address.
I'm interested in hearing from developers: where do you draw the line between what an AI agent may propose and what it is actually allowed to execute?
Top comments (0)