Keep Protocol
WarnAudited by ClawScan on May 10, 2026.
Overview
Keep Protocol matches its stated agent-communication purpose, but it deserves review because it can auto-start local server code and its agent identity/memory-sharing model is broad enough to misroute sensitive messages.
Review before installing. If you use it, run the server only from pinned/trusted artifacts, keep it on localhost or trusted relays, require confirmation before sharing sensitive messages or `scar` memory data, and verify that agent identities are bound to known public keys.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A configured agent could contact or listen to other agents through the Keep server, so mistaken or prompt-influenced tool use could send unintended content.
The skill deliberately exposes MCP tools that let an agent send messages to arbitrary destinations and listen for incoming routed packets. This is core functionality, but users should notice the breadth of tool authority.
`keep_send(dst, body)` | Send a signed packet to another agent ... `keep_listen(timeout)` | Register and receive incoming messages
Use these tools only with trusted relays/agents, require confirmation for sensitive messages, and restrict allowed destinations where possible.
Using the auto-start path may run new external code and leave a local TCP service active without the user separately managing the server lifecycle.
The auto-bootstrap path can download/run unpinned latest server code and start a local service. That is purpose-aligned, but high-impact and not tightly scoped by the skill metadata or install spec.
If not, start via Docker (`ghcr.io/clcrawford-dev/keep-server:latest`) ... If Docker unavailable, try `go install github.com/clcrawford-dev/keep-server@latest`
Pin Docker images or package versions, inspect the server source, and require explicit user approval before auto-starting or installing server components.
Another agent that can reach the same server may be able to claim an agent name, disconnect the prior connection, and receive messages intended for that identity.
The docs show identity is claimed through the packet `src` field and can be overwritten by another connection. They do not show a stable binding between an identity and a known public key.
Registration is implicit: the first signed packet's `src` field maps that identity to the connection. ... Last-write-wins: If a second connection registers the same `src`, the old connection is closed.
Bind each `src` identity to an expected public key, reject unexpected key changes, and use trusted local servers or allowlisted relays for sensitive coordination.
Private institutional knowledge or untrusted memory payloads could be sent to another agent and then reused in later reasoning.
The skill intentionally supports sharing memory-like commit bytes between agents. This is aligned with the feature, but such data can be sensitive or can poison downstream agent context if over-trusted.
Share institutional knowledge between agents using the `scar` field ... `scar=b"<gitmem commit bytes>"`
Only share deliberate, non-sensitive memory payloads, verify the sending identity, and treat received memory as untrusted until reviewed.