mantivor-collector

Runtime security monitoring for an MCP server you run.

The collector is a stdio proxy. You put it between your agent and one MCP server: your agent launches the collector instead of the server, and the collector launches the server. Every response the server returns is forwarded to your agent byte for byte, and inspected on the way past for things that look like an attack on the agent — hidden instructions, role injection, encoded payloads and exfiltration patterns in tool output. What it finds is reported to your Mantivor organisation, where you read it in the dashboard. The rules it matches against are downloaded at startup and change over time, so what it detects is not fixed by the version you install.

It is a monitor, not a firewall. It never blocks, filters or alters a response.

Before it will do anything

Two things have to be true, and it is better to read them here than to meet them as an error on your first run:

1. You need a Mantivor organisation and an API key. Sign up at mantivor.io, add the server you want to monitor, then create a key under Settings → API keys. A collector key needs exactly two scopes, runtime:write and ruleset:read. Scopes are fixed when a key is created — to change them, mint a new key.
2. A person must confirm, in the dashboard, that they are authorised to observe that server. An API key cannot grant this to itself. The confirmation lasts 30 days and can be withdrawn at any time.

Without the first, the collector exits and tells you to log in. Without the second, it starts, forwards your traffic normally, and tells you loudly that it is not monitoring.

pip install mantivor-collector
mantivor login                       # the `mantivor` CLI installs alongside this package
mantivor-collector run \
  --server-id srv_a1b2c3 \
  --upstream python --upstream-arg -m acme.mcp

mantivor-collector doctor --server-id srv_a1b2c3 checks every one of those gates before you wire anything into your agent. Start there.

Names that look like typos but are not

This package is mantivor-collector, but it imports as vorlox_collector and reads environment variables called VORLOX_API_KEY and VORLOX_API_URL.

Vorlox was this product's former name. The import package and the environment variables deliberately kept the old spelling: renaming them would break every existing install and pipeline for no functional gain. They are the correct, current names — not stale documentation, and not something you need to work around.

What it does to your traffic

Nothing. The response your agent receives is always the one your server sent, byte for byte. Inspection happens alongside; if it fails, the call completes normally.

If the collector cannot monitor, it keeps forwarding. A revoked key, an expired authorisation, a plan change, an unreachable API — all of them stop detection. None of them stops your traffic, and none of them exits. You get a loud, repeated warning on stderr instead of a broken agent.

That is one rule to remember: if something is wrong, your traffic still flows and Mantivor tells you it is not watching.

Consent is re-checked every five minutes while running. If it is withdrawn or expires mid-session, observation stops there and then, buffered events are discarded, and forwarding continues.

What leaves your machine

By default, response text does not. A reported event carries which rule matched, its category and weight, where in the response it matched, and a score. It does not carry the matched text.

You can opt in with --redaction none, which adds up to 200 characters of the matched text per signal. The setting is recorded on every event, so the dashboard shows which choice produced each record.

Both the startup banner and mantivor-collector doctor state the current setting in the same words.

Diagnosing it

mantivor-collector doctor --server-id srv_a1b2c3

Runs every check the collector runs at startup and prints each verdict — credential, connectivity, scopes, ruleset, redaction, server, consent, entitlement — exiting non-zero on the first failure. Paste this output into a support request; it is what we would ask for.

Credentials

The collector reads the key stored by mantivor login (from the mantivor CLI, which is installed as a dependency of this package), or VORLOX_API_KEY if set, which wins. A collector key cannot read your findings, start scans, or register servers.

Use one key per collector host. Revoking then affects that machine alone. Each install also generates a random collector id, so the same key presenting from two machines is visible in your organisation's records — which is how a cloned or imaged machine gets noticed.

Detection rules

The collector downloads its detection rules from the Mantivor API at startup and holds them in memory. They are never written to disk.

Being direct about what that does and does not achieve:

A customer with a valid key can extract the ruleset from the collector's memory, and we are not preventing that — no design that runs on someone else's machine can. What changes is that bulk anonymous access ends and access becomes attributable.

Concretely: the rules are not in a package anyone can download without an account, every full fetch is tied to a key and recorded, and access is revocable. We do not claim more than that.

We also do not vary the rules per customer to trace leaks. Doing so would mean different customers get different detection, trading your protection for our attribution, and that is not a trade we will make.

If the rules cannot be downloaded, or require a newer collector than you have installed, the collector refuses them entirely and detects nothing rather than applying the part it understands — a partially applied ruleset scores lower, so a real attack would be reported as clean. It tells you loudly, and keeps forwarding your traffic.

Buffering and delivery

Events are buffered in memory, never on disk, and posted to your Mantivor organisation in batches of up to 100. A batch is sent every 30 seconds, and immediately once a batch's worth has accumulated — so a burst does not sit waiting for a tick, and a quiet server's single detection does not sit for half an hour. A last batch is sent when your agent disconnects.

The buffer holds at most 1000 events and drops anything older than 6 hours; when it fills, the oldest are dropped and the count is reported. Buffered events are lost if the process is killed — that is the cost of never writing your response data to disk, and the flush interval is what keeps the window small.

On a refusal:

A retried batch cannot double-report: each event is stamped with a unique id when it is detected, not when it is sent, so a re-send carries the same ids and the API recognises them.

mantivor-collector prints a status line after each delivery — observed=… events=… delivered=… buffered=… dropped=… — so "detected" and "actually reached Mantivor" are two numbers you can compare rather than one you have to trust.

Install size

This package depends on the MCP SDK, which brings roughly 44 MB of dependencies — including a web server framework it uses for transports a stdio proxy never touches. That is why the collector is a separate package from the mantivor CLI, which stays at about 2.7 MB for CI use.

Licence

Proprietary. Installing and running it against your own Mantivor organisation is permitted; redistribution and modification are not. The full terms ship in the package as LICENSE.

Support: mantivor.io/support · Questions about the licence: contact@mantivor.io