RedAmon Plugins
Plugins are optional features an admin installs into RedAmon from a signed catalog, without waiting for a RedAmon release. Each one is released on its own schedule, runs isolated from the rest of the stack, and can be disabled or removed at any time. With no plugin installed, RedAmon behaves exactly as it does without the platform.
The catalog
Read from the same signed catalog every RedAmon installs from, so this list is exactly what an admin can install today.
Catalog serial 3, Ed25519 signature verified with RedAmon's official key ee4a2df9065d36b1
Turns a finished chat session into a better attack playbook or a better version of your own skill, for you to approve.
Learns from an agent chat session and proposes a better, session-agnostic version of a skill it used. Nothing changes until a person approves it.
samugit83/redamon-plugins
RedAmon's own repository holds only the platform, the machinery that hosts plugins. It contains no plugin code and does not know what any plugin does. Every plugin lives in a second public repository, redamon-plugins, with its source, tests, releases, changelog and the signed catalog that lists them. Installing a plugin downloads one archive, never the repository, and needs no RedAmon rebuild or update.
Each plugin has its manifest (plugin.json, the whole contract with the platform), its Python engine, its tests, a README that says what it reads and stores, and a changelog.
A tag such as skiller-v1.1.0 starts CI: it validates the plugin, runs its tests on the oldest platform version it supports, and packs only that folder into a reproducible archive.
Nothing is published until the repository owner approves the release. The workflow then attaches the archive, adds it to catalog.json and signs the catalog.
A harmful version can be revoked in the catalog. Every RedAmon then stops it at its next check, shows the reason on the plugin's card, and falls back to the factory skill text.
redamon-plugins/
catalog.json signed list of every plugin and release
catalog.json.sig Ed25519 signature over its exact bytes
tools/ validate, pack, catalog, sign
skiller/
plugin.json manifest: permissions, actions, menu items
engine/ the plugin's Python code
tests/ run against the platform SDK's fakes
README.md CHANGELOG.mdTrust model
Plugins run inside a security tool, so their code is treated as untrusted from the moment it is downloaded. These rules hold for every plugin.
RedAmon installs plugins only from a catalog signed with Ed25519, and checks each archive against the SHA-256 the catalog pins. A catalog it cannot verify is not used.
Plugin code runs in its own container, one process and user id per plugin version, with no internet, no database credentials and no LLM keys.
A plugin reaches RedAmon only through the Gateway, which checks a short-lived call token, the permissions an admin granted and your tenancy on every single call.
A plugin can only propose a change to what the agent reads. Nothing applies until a person approves it in RedAmon's own review window.
Disable or uninstall every plugin and RedAmon behaves exactly as before. The agent never waits for plugin code.
A plugin describes its screens in JSON and RedAmon draws them, so no plugin JavaScript ever runs with your login.
Getting started
./redamon.sh install, update and up start the plugin platform with the rest of the stack. It needs Docker Engine 28.0.0 or newer.
Every signed-in user sees the page and each plugin's state. Only admins can install, update, disable or uninstall, because these put code on the host.
The admin reads what the plugin may do and accepts. Its actions then appear where it declares them, each marked with a plugin badge.
No outbound HTTPS from your server? An admin can still use Install from file with the release archive, catalog.json and its signature. Everything else, from updates and rollbacks to uninstalling and exporting a plugin's data, is in the Plugins guide.
Not to be confused with
Signed packages from the RedAmon catalog that add a feature to RedAmon itself, such as Skiller. Their code runs in the isolated plugin runner.
An admin installs them from the Plugins page.
Any Model Context Protocol server connected to the agent as an extra tool: Shodan, GitHub, Censys, your internal MCPs.
Added in Global Settings, MCP Tool Plugins.
The other direction: your own agent connects in and drives RedAmon with a personal access token.
A token minted in Global Settings, MCP Server.
Anyone can propose a plugin, without write access to any repository. A plugin is a folder in redamon-plugins: a manifest that declares its permissions and where it appears, Python actions, and tests against the platform SDK's fakes. Its code may import only the Python standard library, the SDK and its own bundled libraries. One key signs every plugin, so an administrator reviews, merges and releases each one.
Fork redamon-plugins and create your plugin's folder: a manifest with the fewest permissions that work, Python actions, tests and a README.
tools/run.sh validate and tools/run_tests.sh run the same checks as CI, in Docker. Optionally install it on your own RedAmon with a development key.
Against master of redamon-plugins, with its checklist filled in. CI validates, tests and packs it with no secrets.
An administrator reads the code and the permissions, may ask for changes, and is the only one who can merge. Wait for it: nothing is published before.
After the merge, an administrator tags the release and approves the signed catalog. A merge alone is not a release.
Within minutes the plugin appears on the Plugins page of every instance, where each admin decides whether to install it.