What Webcuris does

The short version#

Webcuris looks at things you own — a website, a git repository, the AI components inside it — and reports security problems it can prove from evidence it collected. It re-checks them on a schedule, tells you what changed, and keeps a history so you can show somebody the problem is fixed.

It is not an AI product. Nothing here asks a language model what it thinks of your site. Every finding comes from a specific check that fetched a specific thing and compared it against a rule, which is why every finding can tell you what it looked at.

Three kinds of target#

The platform assesses three things, and they behave differently because the access they need is different.

• A website, by URL. Most checks need nothing but an ordinary HTTP request, so a scan can start seconds after you paste the address.
• A repository, by connecting a read-only token or by scanning it on your own machine so the code never leaves it.
• The AI components found inside a scanned repository — model SDKs, agent frameworks, vector stores — inventoried and assessed as a group, because an agent that can call a tool is not the same risk as a client that sends text somewhere.

Two depths of website scan#

A standard scan runs against any address you give it. Everything it does is something an ordinary visitor's browser would do: fetch pages, read headers, resolve DNS, inspect certificates.

A deep scan runs additional checks that send requests a normal visitor would not, and those stay switched off until you have proved the domain is yours. That is not a paywall — it is the line between assessing your own systems and probing somebody else's.

What it deliberately will not do#

A scanner that promises everything is a scanner that guesses. Several classes of vulnerability can only be confirmed by performing the attack — running the injected command, exhausting the rate limit, desynchronising a connection other people are using. Those are refused, and the refusal is published with its reason rather than hidden behind a silent gap in the results.

The practical consequence: a clean result here means the checks that ran found nothing. It never means every possible problem was looked for. Where a check did not run, the interface says so in its own words rather than showing a reassuring dash.

Confidence, on every finding#

Each finding carries how sure the engine is, and that grade travels with it into exports and reports. A response header that is missing is a fact. A technology guessed from the shape of a URL is not, and it is not presented as one.

This is the single most useful thing to understand before you read a result. It is why a finding here can usually be handed to an engineer without being re-verified first.