Connect the systems you already use.

Files and resources are read for a scan and deleted again when it is done, successful or not. What Maplith keeps is the map: metadata about your data, which may quote example values and evidence.

Maplith’s own client lists and reads, and never writes. The one integration that writes is the GitHub app, and only where your policy lets its agent comment or propose a change.

An admin removes any connection under Data sources › Systems in one click, and its token is deleted with it. Tokens are sealed when you add them and never shown again.

Two GitHub apps: Maplith Agents today, for issues and pull requests in the repositories you choose and a hosted agent that answers under your policy; and a read-only Maplith app, being published as the default, for teams that want the signals and no agent that writes.

What it reads. Deliveries for issues, issue comments and pull requests in the repositories you grant the app: the issue or pull request, its title and text, the label or comment, and who sent it. They are kept for 12 months. The map is not built from your code.

How it connects. Install the Maplith Agents GitHub app from Data sources › Systems in your workspace. Once the read-only Maplith app is published, Connect GitHub installs it instead, and an admin chooses Allow agents to act to add Maplith Agents beside it. Maplith binds an installation to one workspace only after three checks: the request came from your workspace, you are an admin or builder there, and you own or administer the GitHub account or organisation.

Access, and why. You choose all repositories or a selected list at install. For Maplith Agents, issues, pull requests and contents are read and write, so the hosted agent can comment and open a proposal pull request; it never merges. The read-only Maplith app asks for read access only and cannot change anything in GitHub. Both lists, with the reason for each, are below.

Signals. A label your policy acts on (agent-fix, agent-pr) is work: it opens an external signal for an agent. A comment, any other label and a pull request opened or closed are news: kept with the delivery, never a signal.

Switching it off. An admin presses Disconnect under Data sources › Systems: Maplith uninstalls the app at GitHub and removes the binding, one app at a time. Uninstalling at GitHub does the same; Maplith removes the binding when GitHub says so.

A vendor’s official MCP server, or one your IT runs, read on your schedule.

What it reads. The resources the server lists, read for a scan and deleted again when the scan is done, successful or not. What Maplith keeps is the map. The generic client lists and reads resources; the Intercom and Metricool integrations also call a fixed set of read-only tools. None writes to your systems.

How it connects. An admin or builder adds the server’s address and, if it needs one, a bearer token under Data sources › Systems. The token is typed by a person, never pasted into a chat or handed to an agent.

Access, and why. Whatever the token grants, so give it read-only access to what the map should cover. The token is sealed with AES-256-GCM, its key held outside the database, and is never shown again. Addresses that resolve to a private network are refused.

Signals. Maplith checks each connection about every 12 hours. link_dead when it stops answering, with the steps to repair it, cleared when it answers again. structure_changed when it offers at least a quarter more or fewer resources than before. Each scan raises the map’s own signals, such as process_deviation; an approved fix raises fix_approved.

Switching it off. An admin presses Remove under Data sources › Systems, which deletes the token. Revoke it in the source system too.

Open source, Apache 2.0: serve a folder of exports or a PostgreSQL database from your own network.

What it reads. The files in one folder you choose: CSV, TSV, JSON, JSONL, Markdown and plain text, never hidden files. For PostgreSQL, the Bridge’s extractor reads the catalog and the tables you grant and writes one CSV per table into that folder.

How it connects. You run the Bridge, a small server on Node.js, next to your data, installed from npm as part of the package maplith or from the signed release. Maplith connects to it as an MCP server, with a token you create.

Access, and why. Read-only, one folder, a token on every request. The extractor refuses to run under a database role that can write. Maplith never holds a database password.

Signals. The same as any MCP server: link_dead, structure_changed and the signals each scan raises.

Switching it off. Stop the Bridge, or replace its token: a running Bridge refuses the old one. Then remove the connection under Data sources › Systems.

The assistant you already use fetches the data with the access you already gave it.

What it reads. The files your assistant sends with your approval, read for the build and deleted again afterwards, as with an upload. Maplith holds no credential to the system they came from.

How it connects. Connect your assistant to Maplith over MCP, by signing in or with an agent key. With your approval it fetches each system with the access it already has there, then sends the files to build the map.

Access, and why. An agent key sees only the part of the map you scope it to, and can send files only when you allow it to upload. Each system guide below names the read-only access to choose in that system.

Signals. Each scan raises the map’s own signals. Your assistant reads them with list_signals and get_task_context.

Switching it off. Revoke the agent key under Agents & access › Connections, or disconnect Maplith in your assistant.

The fallback that always works: the exports your systems already produce.

What it reads. CSV, Excel, PDF with a text layer, JSON and JSONL, mailbox archives, Slack exports, meeting transcripts and Markdown, unpacked from .zip or .gz. Read for the build and deleted from storage when it is done, successful or not.

How it connects. Upload a folder per system in Data sources › Scans. Up to 300 files and 1 GB per upload; a large CSV is sent in parts.

Access, and why. None. Maplith sees exactly the files you choose and holds no credential. Leave out what must not be processed.

Signals. Each scan raises the map’s own signals, such as process_deviation, and an approved fix raises fix_approved.

Switching it off. Nothing stays connected: the files are gone once the build is done, and the map stays with your workspace.

A failed workflow run, a failed deployment or a new security alert in your repositories, raised as its own kind of signal the moment GitHub reports it, and cleared when GitHub reports it fixed.

What it reads. What GitHub reports for the event: the alert’s number, rule or package and severity, never the secret itself; the workflow run or deployment and its status. For a run or a deployment, Maplith reads that workflow’s or environment’s newest runs from GitHub before it decides, because runs finish out of order. Never your code.

How it connects. Maplith Agents today, and the read-only Maplith app once it is published. GitHub sends these events once your installation holds the read permissions below: when the app asks for them, an owner of your installation accepts them at GitHub. Raised from what GitHub sends; Maplith does not poll your repositories for them.

Access, and why. Read-only: Actions, Deployments, Code scanning alerts and Dependabot alerts, beside the Secret scanning alerts the app already holds.

Signals. security_alert for a secret-scanning, code-scanning or Dependabot alert, one per alert. ci_failed when a workflow fails on the default branch, cleared by its next green run. deploy_failed when the newest deployment of an environment fails, cleared once the newest one is live.

Switching it off. Disconnect under Data sources › Systems, or uninstall the app at GitHub, as today.