The full mechanism behind the Board: what we watch for, how we detect it, and what we never do. No black boxes — this page describes the same code that runs in production, not a marketing-simplified version. Looking for the API reference to integrate Centinela into your own systems? That lives in API documentation.
An MCP server offers an AI agent a list of tools — each with a name, a free-text description, and a schema of what parameters it accepts. The agent reads that description and decides, on its own, when to use the tool and with what data. That's the problem: the agent trusts that text the same way it would trust an instruction from a human, and that text is written by whoever runs the server — nothing reviews it in between.
That opens vectors that don't exist with a traditional API: a description can carry a hidden instruction to manipulate the agent, a schema can ask for far more access than the description lets on, a server can change a tool's behavior after you already trust it (a rug pull), or impersonate a trusted tool with a near-identical name. None of these attacks need a classic software vulnerability — the text the server already publishes is enough.
Centinela never invokes a tool on your server, never executes code, and never touches your data. Everything you see on the Board comes from reading tools/list (the tool list the server already publishes) and cross-referencing it against public metadata — the same kind of information anyone has access to, we just look at it systematically and continuously.
The only network requests we make to a server are the minimum needed to ask for its tool list and check how it responds without credentials — nothing else is sent or received.
22 categories, grouped by where the signal comes from. Each has a default severity (High/Medium/Low) — the one you see on a specific finding can vary by case, see how to read the Board for what each tier means.
Invisible or control characters (zero-width, direction overrides, the Unicode "tag" block) hidden inside the description — a known way to hide text a human never sees but the agent still processes.
Literal phrases like "ignore previous instructions" in the description — the same attack as above, in visible text instead of hidden.
The schema asks for something sensitive (files, running commands, credentials) the description never mentions. With AI enabled, a model understands nuance (a pagination token isn't a credential); without it, falls back to a keyword heuristic.
A literal IP address or a URL shortener (bit.ly and similar) in the description — a legitimate service is referenced by its domain, not hidden behind a shortener or by its IP.
A long block of text that looks base64-encoded inside the description, with no reason to be there in text meant for a human or an agent to read.
The name resembles — via homoglyphs (a Cyrillic letter that looks identical to the Latin one) or a near-typo — an extremely common tool name (reading a file, running a command). Known as tool shadowing: how the agent ends up confusing the malicious tool for the trusted one.
Dozens of consecutive line breaks or spaces before the real content — pushes text outside what a client's approval UI shows, which still reads the full description even if it only displays the first lines.
The schema deliberately declares additionalProperties: true without defining any property of its own — accepts arbitrary JSON from the agent, a way to smuggle fields that were never advertised.
A boolean safety parameter (confirm, force, skip verification) whose default value leaves the protection off without the agent having to ask for it explicitly.
The package (npm, PyPI, or NuGet) the server ships as has a confirmed entry in OSV.dev — a real vulnerability or a package already flagged as malicious, not a guess.
Less than 7 days since its first publish on the registry — nobody has had time to audit it yet, a real supply-chain risk.
The GitHub repository is under 30 days old with under 20 stars — not malicious on its own, but worth a closer look before fully trusting it.
The server's domain is one or two characters off from a real, well-known domain — classic typosquatting, applied to the MCP itself instead of a website.
The actual domain serving the MCP (not the repository its code lives in, which can be different) was registered less than 30 days ago, per RDAP — the standard successor to WHOIS.
The domain appears on URLhaus as already-confirmed phishing, malware, or C2 (command and control) infrastructure — a direct match against a public list, not a heuristic.
The server lets you list and use its tools without any credential. Informational, not a danger on its own — common and legitimate in many public read-only APIs.
Requires something before letting you in, but doesn't follow the OAuth 2.1 standard MCP defines (no WWW-Authenticate header with resource_metadata) — could be a static key or another custom mechanism.
The authorization server does follow the standard, but doesn't advertise PKCE support with S256 — required by OAuth 2.1, the base of the MCP standard.
A tool appeared that wasn't in the previous scan. With AI enabled, its own content is judged for whether it looks suspicious and severity rises if so.
An already-known tool's description changed since the previous scan — the central signal of a rug pull: a tool that started out trustworthy changes behavior after you're already using it.
A tool that used to exist is gone — informational, to keep track of what's changed in the catalog.
The exact same finding, word for word, also appears on another unrelated server — a sign of a cloned template or an attack targeting several servers at once, not an isolated case. Inherits the severity of the finding that repeats.
Every server falls into one of three tiers based on the HIGHEST severity in its latest scan — the same language everywhere:
"We can't verify it" (requires authentication, or unreachable) is never presented as "it's safe" — it's the opposite: we have no visibility into that server at all, so we don't know either way.
In the Vulnerabilities section, each row counts findings, not necessarily servers: a single server can contribute several (a different tool each time, for example). When the number of affected servers differs from the finding count, it's shown underneath — so 2,500 findings of "asks for more access than it advertises" don't read as 2,500 different servers if it's really 800.
Every server in the catalog is re-scanned every 24 hours — an hourly cycle continuously works through the whole catalog, without waiting for anyone to ask. The Board's data in turn refreshes every few minutes off those scans, so what you see is never more than a day behind each server's actual last scan, and usually much less.
Depends on the category — the finding's description on your server's page explains exactly what was detected and why. Many low-severity findings (no authentication, new repository) are informational, not a bug to fix.
No. Claiming a server (verifying you control its domain) lets you attach a scanning credential so we can also watch tools that require authentication — it never hides or modifies any finding already detected.
This very page describes exactly the mechanism running in production — there's no additional hidden check that isn't documented here.