Security

What the agent will not do

You are about to run our software on machines you are responsible for. Here is what it can do and, more to the point, what it cannot — in plain words. Every line below is a test that blocks our own releases: if one of them stops being true, nothing ships.

Nothing to open on your firewall

The agent listens on no port, in any configuration. It calls us, outbound, on 443; we never call it. There is no inbound way in for us, and none for anyone who ever takes our place.

The same rule binds the probes that check your sites from the outside: they open no port either. The one local door is a UNIX socket for the command line, on the machine itself.

We cannot run anything on your machines

Running a program on a monitored host is off by default, and there is no path from here that switches it on: not the dashboard, not the API, not an assistant through MCP. Somebody with a shell on that server turns it on by editing the local file, and names the exact binaries allowed.

So even if our infrastructure were taken over tomorrow, the attacker gets no command execution on a server that had not already allowed it, locally, on purpose. That is the whole point of the design.

It does not need root

The agent runs as its own unprivileged user, under a hardened service: a mostly read-only filesystem, a private temporary directory, no new privileges, a system-call filter. A check that would need more privilege fails with a clear message instead of demanding root for everything else.

Your server's key never leaves your server

At enrolment the agent generates its own key pair on the machine, and the private half is never transmitted — not to us, not once, not even while enrolling. Every request is authorised against that host: one of your servers cannot read another one's data, and neither can anybody else's.

Every instruction we send is signed

Configuration reaches the agent as a signed bundle. The signature covers the content, your organization, that host and the version number, so a bundle meant for one server is refused by every other one, and an old bundle cannot be replayed. Anything unsigned, altered or foreign is rejected and logged, and the agent keeps monitoring with the last configuration that was good.

The key that signs is not held by the API. It lives in a process of its own with no network at all, which checks what it is asked to sign before signing it: it will not sign a check that runs a program, or a field the contract does not have. Getting a shell on our API is not enough to reach it.

Secrets stay out of the logs, and out of the AI

The credentials a check carries — the header of an authenticated HTTP check, a webhook URL — are encrypted for your organization and decrypted on your own machine. They appear in no log at any verbosity, in no API response, and in no screen once they are saved.

Mango AI is no exception. Everything sent to a model is assembled from a list of allowed fields and passes through one redaction step on the way out, tool results included. We prove it by planting fake secrets and demanding they appear in our own records and not in the request that leaves.

One organization cannot read another's data

The isolation is enforced by the database, not by our application code. For every table, a query for another organization's rows comes back with none, and a person removed from an organization loses access on their very next request. It is not a filter somebody can forget to write.

Limits, so noise cannot take the service down

Every authenticated call and every public form goes through a rate limiter, reads counted apart from writes, with the limits and what is left of them in the response headers. The paths your agents and probes use to report are the ones that are never limited: throttling them would be throttling the monitoring itself.

Auditable, and honest about what is not done

Every configuration change is written to an append-only record: who, what, from where, when, and the version before and after. You read it in your own dashboard, because you being able to audit us is part of the deal. The contract every client of ours is built against is public, and this is it: https://api.hopmango.com/openapi.yaml

What is not true yet: the key that signs configuration sits in its own process on our own infrastructure, not on a hardware token outside it. That is the next step, and we would rather write it here than let you assume otherwise.

Found something?

Tell us what you found and how to reproduce it, and we will answer. Nobody is going to be sued for reporting a bug in good faith. hello@hopmango.com