OpenExec — Deterministic Execution Boundary for Agent Systems
ReviewAudited by ClawScan on May 10, 2026.
Overview
OpenExec is transparent about being an execution service, but its approval and replay protections are weaker than its security claims, so production use for real actions needs careful review.
Do not treat this as a production-safe boundary for payments, infrastructure changes, email sending, or deletion until approval artifacts are made one-time or nonce-bound and nonce reservation is atomic. If you test it, bind it to localhost, use ClawShield mode and an action allow-list for any non-demo handler, and protect the execution database.
Findings (6)
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.
If real side-effecting handlers such as payments, email, or infrastructure changes are added, one signed approval could be used to trigger the same approved action more than once.
In ClawShield mode, the approval validation input includes only action and payload. The execution nonce is not bound into the signed request, and the included code does not show approval IDs being stored as consumed, so a valid approval artifact can be reused with different nonces during its lifetime.
action_request = {"action": request.action, "payload": payload}
validate_approval(action_request, request.approval_artifact.model_dump())Bind the nonce and/or a one-time approval ID into the signed approval artifact, persist consumed approval IDs, and define whether approvals are single-use or explicitly multi-use.
For side-effecting handlers, a replay race could perform the same real-world action twice even though the API later reports replay protection.
The registered handler runs before the nonce record is committed. Concurrent requests with the same nonce can both pass the initial lookup and execute the handler before one loses the database uniqueness race.
result = handler(payload) ... db.add(log) db.commit() except IntegrityError:
Reserve the nonce atomically before running the handler, use transaction locks or idempotency records, and ensure handlers are idempotent for retries and races.
Users may deploy the service for payments, infrastructure, or data deletion with more confidence than the implementation currently supports.
This strong guarantee can lead users to overtrust the service for high-impact execution, while the implementation has approval-reuse and non-atomic replay-control gaps noted above.
Replay protection prevents duplicate execution classes entirely.
Revise the security claims to describe the exact guarantees and limitations, and fix the replay/approval design before recommending production use for side-effecting actions.
The built-in actions are low-impact demo actions, but exposure becomes risky if additional handlers are added or if the service is run on a reachable host.
The default mode does not require signed governance, and the documented local run command binds the HTTP service to all network interfaces. This is disclosed, but it is easy to expose an unauthenticated demo execution endpoint.
Demo mode (default, free) No external governance required ... python -m uvicorn main:app --host 0.0.0.0 --port 5000
Bind to 127.0.0.1 unless intentionally exposing the service, enable ClawShield mode for production, and configure OPENEXEC_ALLOWED_ACTIONS.
Sensitive values included in execution payloads or results may remain in the OpenExec database and may leave the host if a remote database is configured.
Execution inputs and results are stored persistently in the database. This is purpose-aligned for receipts/replay protection, but the stored payloads may contain sensitive task data.
payload = Column(Text, nullable=True) result = Column(Text, nullable=True) nonce = Column(String, unique=True, nullable=False)
Treat the database as sensitive, avoid putting secrets in payloads, define retention/deletion practices, and secure any remote database configuration.
Users have less independent context for verifying that the package matches an intended upstream project.
The supplied source files are visible and dependencies are pinned, but the registry metadata does not provide an upstream source or homepage for provenance checking.
Source: unknown Homepage: none
Verify the package source through a trusted channel before deployment and prefer releases with clear repository and maintainer provenance.