The claim is narrow and checkable: secrets live in an AES-256 encrypted store on your own device, an agent calls them by name, and plaintext never enters the conversation or the logs. Sealing extends the same idea to scripts — a capsule the recipient executes but cannot read. Two things to plan around: deletion is manual rather than a tool call, and the licence is the project's own rather than a standard open-source one.
A local encrypted execution layer that sits between an agent and your secrets. API keys, credentials and configs go into an encrypted store; scripts can be sealed into capsules that only a target node can decrypt and run. Everything decrypts on-device, and MGC is the boundary rather than an agent itself.
- Store a secret under a name, encrypted locally — `mgc_save`
- Retrieve a stored item for use without the plaintext entering the conversation — `mgc_get`
- List what is stored, metadata only — `mgc_list`
- Seal a script into an execution capsule that only the target node can decrypt and run — even the sender cannot read it back — `mgc_seal`
- Open the local web UI for the parts meant for a human: initialization, manual storage, metadata inspection, audit and deletion — `mgc_open_webui`
- A REST path alongside MCP, so system scripts can fetch encrypted items at runtime with the access token
`pip install mgc-blackbox`, into the same Python environment your MCP agent runs in. `mgc` starts it as a local service; for MCP, configure `command` `mgc` with `args` `["--mcp"]`. The web UI is at `http://127.0.0.1:57218`, stepping down to 57217, 57216 and onwards if the port is taken — the startup output prints the address it actually used. An access token is generated on first run at `~/.mgc/database/mgc_black_box/.mgc_token` and is required for every REST call. There is no delete function: removal is a manual database operation from the web UI's audit view. Integration into third-party products is free but the project asks for authorization first.
One command — pip install mgc-blackbox