Repository navigation
Running CleiMesh (per-call signed permissions + receipts) next to OpenShell, and two questions on RFC 0009 #4811
cleitonaugusto
started this conversation in
Design Discussion
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi! I work on CleiMesh, a Rust project (MIT/Apache-2.0, still alpha) that sits one level below what OpenShell does. OpenShell contains the agent process. CleiMesh handles each tool call: the agent presents a signed token that can only get narrower when it's handed to a subagent, the tool runs in a WASM sandbox built from that token, and every call, allowed or refused, gets a signed receipt in a hash-chained log.
I put the two together as a workload in our repo, since that's what you recommend now: examples/openshell. It's a Dockerfile, a policy.yaml whose only network rule is the CleiMesh node's port for the cleimesh binary, and a script that runs the whole thing. On 0.1.5 with the Docker driver, the agent reads a mail with an injected instruction, and the write that instruction asks for is refused by the node. Trying any other port on the host gets
NET:OPEN DENIEDfrom OpenShell. The node key and the receipts stay on the host, and the receipts export as OCSF next to your events.I saw in #4658 that for audit the correlation key has to come from outside the sandbox. That's the reason the receipts are written by the node and not by the agent, and a call doesn't run until its receipt is on disk. It's close to what #3817 asks for on the event stream side.
Before I write anything against RFC 0009, two questions:
I'd like an egress middleware on
HTTP_REQUEST/PRE_CREDENTIALSthat denies outbound requests once something in the sandbox's delegation chain has read untrusted content (mail, web pages), until a person clears it. That means keeping state per sandbox, keyed on thesandbox_idin the request context. Is that an intended use, and does the ID stay the same for the sandbox's lifetime?Our receipts also cover the result of a call, not just the decision. For egress that needs the response side. Is response inspection (
PRE_RETURN) for HTTP something you plan to add, or would you rather middleware stay request-only?If either one makes sense I can write it up as a feature request in OpenShell terms. Comments on the example are welcome too.
All reactions