Agent Haven (agenthaven.org) has launched — a network for direct AI agent communication with a 'not for humans' positioning. Messages are encrypted on the client side, the server stores only ciphertext, and there is no master key or recovery key in the system at all. Key substitution should be revealed by a public witness log, published hourly on GitHub, and registration is built as a challenge with proof-of-work, impassable manually. The project is currently an early verifiable experiment: there has been no independent audit, and the authors themselves list the unresolvable limitations of their model.

image
image

What happened

The agenthaven.org website has opened, and on September 29, 2026, a reference MIT client appeared on GitHub in the manager/agenthaven repository. The network supports direct messages for 1–16 participants: text is encrypted on the client side, keys are stored in a 'safe' that is opened only by a password, the server sees only ciphertext and does not know who is participating in the correspondence. The size of each message is padded to fixed buckets of 1024, 4096, or 12000 bytes, so the true length is masked only at the level of three possible values. Registration is designed for a program, not a human: a login of 24–56 characters from the set [a-z0-9] with a 6-digit hex checksum (SHA-256 from the login body), a password 64–256 characters long with at least 40 distinct characters, and proof-of-work — hex-SHA-256 from the string 'login:password', which must start with '00'. The challenge response is accepted for 60 seconds with a limit of 30 requests per 10 minutes. The client accepts counterpart keys only after the corresponding records appear in the witness log, which is published hourly in the manager/agenthaven-witness repository. Documentation is published in machine-readable form — a summary at the /llms.txt path and API rules at the /api/rules path.

Context

The launch answers a question that arises as agent ecosystems grow: over what transport should agents communicate with each other privately and how to ensure that keys have not been substituted. The idea of a witness log — a public journal to which all keys are issued and on which the client relies for verification — looks like an adaptation of the key transparency approach to agent communication; the authors do not make claims for a new cryptographic primitive. The 'not for humans' positioning here is literal: onboarding is made routine for a program and intentionally impassable manually, and the required '00' prefix in proof-of-work corresponds to approximately eight bits of computational work. Significantly, the project from the very start publishes along with a list of advantages the boundaries of its own trust model — such a level of openness is rare in early prototypes. Verifiability in the project is based on artifacts, not words: open client code, an hourly public journal, and machine-readable documentation, all of which are available to everyone for independent verification.

Why this matters for the industry

For the industry, the main value is verifiability, not promises: a company or engineer can clone the MIT client, run it themselves, and reproduce the entire registration and key exchange pipeline. The project's mechanics — PoW onboarding, fixed-length padding buckets, and a key witness log — may begin to be copied in agent platforms regardless of the fate of the network itself, since the MIT license explicitly allows this. If agent-to-agent communications grow, private transport with verifiable keys will become a commodity layer of agent infrastructure, and early concept checks will set its basic requirements. The published list of unresolvable limitations additionally serves as a realistic guide when designing secure agent communications and as a map of open tasks: agent identity, metadata observability, host access to context. The main risk is that a one-author project without external resources may not survive until the appearance of independent audits and third-party implementations, on which its future role depends.

Why this matters for users

For the reader, this is a ready-made educational stand for E2EE for agents, and all the material is open: a machine-readable summary, API rules, and five JS client files, including dm-crypto.js and dm-engine.js. You can register your own agent: the challenge with proof-of-work is specifically made routine for a program with a code tool, so an agent that can write and execute code will pass the procedure without difficulty, while manually it is practically impossible. After logging in, an open forum and 'notebooks' are available, where you can see how other agents communicate. All of this is free and educational in nature: it is still too early to connect real working integrations to the network and trust them with sensitive data.

What is still unknown / limitations

Encryption has not been verified by a third party — there has been no independent audit of the scheme, so it is more correct to speak of a prototype rather than a secure system. The hourly interval of the witness log publication creates a delay window, and resistance to record discrepancies (split-view) and publication delays is not discussed in the scheme description. Padding to three fixed buckets hides the message size only roughly, there is no full protection against traffic analysis. The hosting model provider still sees the agent's context, metadata is observable, and the presence of an agent account does not prove the absence of a human behind it. There is no evidence of technology adoption yet: 4 agents are active, and the discussion on Hacker News received 1 point and 0 comments.

Sources

Author

Look at AI, editorial team