Limitations & responsible use

Smart contracts

• An EVM contract scan needs a working on-chain proof to run at all. If the chain's sibling testnet has no funded internal faucet, the scan is refused outright — not queued, not billed, not run with a note that the simulation was skipped. Funding is checked live against the testnet itself (a drip contract's real balance and payout), never assumed from a configuration flag; an RPC that does not answer counts as not funded.
• The deep verification tier — mutation testing plus Echidna invariant fuzzing — is offered only when a repository structurally qualifies: mutation testing needs a Foundry project with a green test suite (it measures whether your tests catch a broken guard), and Echidna needs an invariant harness declaring at least one property to falsify. A repository with neither has nothing for that tier to measure, and is told exactly what is missing rather than billed for a run that could not do anything.
• Verified-source lookup depends on the chain having a working explorer API. Some chains are explicitly registered as unsupported rather than silently omitted — Cronos, for one, has no working verified-source API as checked by this platform, across every provider tried.

Web and DNS

• No web or DNS target can be scanned without proof of possession — a verified DNS TXT record or well-known file — except for addresses that are nobody's asset but the operator's own (loopback, private ranges), which need no proof because proof could never be offered for them either.
• Any module that actively sends adversarial input to a live target — a runtime prompt-injection probe against an agent endpoint, or sustained load testing — is disarmed by default. Arming it requires the operator's explicit switch, a consent phrase typed verbatim by the caller for that specific target, and (outside loopback) an explicit allow-listed host set before the process starts. None of this is a rented attack tool: every active module refuses anything that was not declared through its own consent path, and a target discovered by another scanner cannot become a declared target by accident of plumbing.

Hosts and telemetry

• Host log ingestion reads journald and syslog, and treats them as the same underlying records — on the systems this was measured against, syslog and journald are two views of one stream, not two independent sources. There is no Windows Event Log ingestion in this codebase; host telemetry here is Linux-oriented throughout, including the ransomware-detection agent, whose own containment logic is written against Linux-specific mechanisms.
• Selection from a host log is by record shape — a curated set of identifiers and message patterns — never by volume, priority, or facility alone, because the highest-volume facility on a real host measured for this platform was not security-relevant at all. Anything not selected is counted and reported by reason rather than silently discarded, so a quiet-looking stream can be told apart from a stream nobody is reading.
• A privileged network-flow sensor is optional infrastructure the operator installs separately; without it running, that producer reports its own explicit "no source" rather than an empty, and therefore falsely reassuring, result.

Site lockdown

• It protects HTTP traffic through the one reverse proxy you installed the template on — not SSH, not a database, not any other listener on the host.
• Anyone with root on the host can remove the flag file directly, bypassing Sentinelleai entirely; this is a response tool for a proxy-level incident, not a guarantee against a fully compromised host.
• There is no auto-release and no auto-expiry — a lock stays engaged until you end it, by the Release command or by rm of the flag file over SSH. Sentinelleai never releases a lock on its own.
• A rehearsal deliberately puts the real site into read-only mode through the proxy for a few seconds, so what you see verified is the actual behaviour, not a simulation of it.

Host containment

• Containment is refused unless explicitly armed on that host, and even then it only ever acts on that same host's own CRITICAL ransomware alert — it is not a general-purpose "kill any process" or "isolate any host" tool.
• Process attribution can name the wrong process, or none at all, during a fast-moving burst — see the same limitation on Hosts & ransomware. A kill only ever targets whichever process was attributed; a wrong attribution can stop a legitimate job while the real one keeps running.
• Network isolation is a tagged set of iptables rules, not a hardware kill switch — anyone with root on the host can remove it directly. It is reversible and, by default, time-limited, but that undo depends on the agent's own restore logic running, not on anything external to the host.
• Linux only, and no credential or session-token revocation happens as part of containment — it acts on a process and on network traffic, never on identity.

Cloud

• Cloud posture checks are read-only throughout — nothing in this module creates, modifies, or deletes a cloud resource, and the credentials it runs under are scoped to a read-only audit role with no mutating actions in its permission set.
• Every check answers one of three ways, not two: configured badly, configured well, or could not tell. A permission refused, an API a target account does not implement, or a call that timed out is reported as unknown with the reason, never folded into a passing result. An aggregate report can say a fixed number of checks did not run; it cannot say everything is clean while any of them is still outstanding.

The AI panel

• Every model behind the multi-model panel is a third-party model, called after the deterministic tools have already produced their findings — never before, and never as the thing an inline request has to wait on.
• A per-run pass (the web reasoning panel, deep contract verification) is billed against a credit reserved before the run starts and released back if the run does not complete — so an unavailable or degraded model is never charged for reasoning it did not produce.
• A panel pass can fail closed: when a model is unavailable, the surrounding scan does not silently substitute a clean result in its place — see degraded and unknown reporting on Reading a report.

Compliance

Human factor

• A phishing simulation can only ever target your own organisation's domains — recipient scope is checked against the domains captured for your account before a campaign can even be declared, and checked again immediately before anything is sent, so a persistence layer cannot become a side door around that scope check.
• A campaign can only be sent once it has been explicitly declared with a consent phrase and an authorising identity; the send step replays only what was already declared and stored, never a caller-supplied shape that was not declared through that path.

False positives and false negatives

Every automated tool on this platform can be wrong in both directions. A false positive is a reported issue that is not real; Sentinelleai reduces these with the classifier described in Reading a report but does not delete what it flags, because a classifier can itself be wrong. A false negative is a real issue the tools never mention at all — the harder failure to see, because nothing on the report points at it. Coverage figures, grounding checks, and the verdict gate exist specifically to keep a report honest about how much of a system was actually examined, rather than letting a short findings list read as a clean bill of health.

Coverage is a fact about the run, not about the world

A scan result describes what ran, against what it was given, at the moment it ran — never the full state of a target that keeps changing after the scan ends. Two disciplines follow from that, and both are load-bearing across this platform, not just in one module:

• Reference, then drift. A first pass over a new target establishes a baseline and announces nothing on its own — there is nothing yet to compare against. Only what a later pass finds that the baseline did not have is reported as a change. A tool that announced findings on its very first look would be reporting "new" for everything that was simply never looked at before.
• Disappearance is not symmetric with appearance. Something a scan observed was, in fact, observed — that half is simple. But something absent from a scan's output has only genuinely disappeared if a healthy tool, looking in the same place, could have seen it and didn't. A scan that failed, was skipped, or read nothing cannot produce a disappearance — an absence from a walk that did not succeed is not evidence of anything.

In short: an absence only counts as a fact when the platform can show it looked and could have seen something if it were there. Otherwise the honest answer is unknown, not zero.

Acceptable use

Sentinelleai is built to be used only against systems you are entitled to test:

• Targets you own, or have explicit written authorisation to test.
• A hostname must carry a verified proof of possession before any web or DNS scan can run against it — see Proof of possession.
• Phishing simulations may only be sent to your own organisation's captured domains, never to a third party.
• Any active module — one that sends traffic designed to provoke a target rather than merely observe it — requires a consent phrase typed verbatim for that specific declared target, and is disarmed by default until the operator turns the capability on at all.
• No module on this platform is built or offered to attack a system on someone else's behalf.

When to call a professional

Sentinelleai is a strong pre-audit and continuous-monitoring instrument. It is not a substitute for:

• An independent audit firm — before a mainnet launch, or before a contract holds real user funds.
• A penetration test by a qualified firm — before launching a public web application, and at regular intervals afterward.
• A qualified auditor — for any certification or formal compliance opinion; the compliance module here is an evidence map, not an assessment.
• An incident-response firm — for a live incident. Sentinelleai's on-demand forensic analysis is an aid during an incident, not a retainer: it is a hosted service (small cases run on an always-on CPU server in the US; larger cases burst to a rented GPU in the EU, with no hyperscaler and no Chinese-origin model in that path), with short, stated retention, and it does not promise that your data never leaves your perimeter — an own-endpoint tier exists for teams that need exactly that instead.