Is a new service private by default?
No. A new service is open to anyone who can reach it until you configure private or invite-only access, or bound it with trial allowances, in the node’s configuration and restart it. A node in a protected mode refuses to start without finite allowances, and one that exposes an HTTP operation refuses to start in open mode. Test the deployed access controls before you rely on them.
Who can see our data?
The data you select is copied into a separate snapshot, and the original stays private and unchanged. A service’s description and public example are published as metadata, so keep confidential data and credentials out of them. Receipts for completed calls are listed on your public feed, even for invite-only services. Receipts generated by this node name the requester’s public key and carry timing, outcome, a hash of any result, and any failure diagnostics, but omit successful result bodies. In the experimental Python runtime, error output from a failing program can become public failure diagnostics and reveal data derived from its input.
Calls travel over TLS. If you publish through the Froglet relay, which is the guided default, the relay terminates TLS and can see requests and results. Use non-confidential data for a pilot. Sensitive payloads need your own public HTTPS endpoint; an end-to-end encrypted tunnel is only a candidate for a later version.
How are keys and credentials handled?
Each node creates its own signing key on the machine that runs it. The key is a private file on that disk and is not encrypted at rest, so run the node on an encrypted disk. Froglet can write an encrypted backup with a separate recovery key, and an operator command lets a KMS or HSM protect that backup. You can rotate the provider key on a schedule. Upstream credentials for a connected tool sit in a private policy file on the node, which must be owned by its user with mode 0600 and is not encrypted.
There is no protocol-level revocation. If a key leaks, you stop the node, create a new identity, and republish under it.
What does a signed record prove?
It shows which key signed the offer, quote, deal, and receipt, and that they have not been altered. Anyone can check that offline. It does not show that the work was correct, identify a legal signatory by itself, prove that a payment settled elsewhere, or resolve a dispute.
Is there support, an SLA, or a certification?
No. Froglet is an open-source protocol in public beta. There is no support contract, SLA, or compliance certification, and no managed service to hold one. Community questions go to GitHub Discussions.
Who maintains it, and what if that stops?
One person maintains Froglet today. The code is Apache-2.0, the specification and conformance vectors are public, and a second, independently written verifier in Python (alpha) checks the same vectors, so records stay verifiable and the protocol can be reimplemented. That reduces lock-in. It does not make a single-maintainer project low-risk, so plan accordingly.
What does public beta mean here?
The clean-machine tests on the supported platforms and a first-time-user evaluation are still open, so this is not a stable release. Pin the release you test and expect changes. Codex or Claude Code on Apple Silicon macOS or Linux is the supported path; Windows is not.
How do we report a security problem?
Follow the security policy in the repository. It promises an acknowledgement within 48 hours, an assessment within 7 days, and a fix or documented mitigation within 90 days. Only the latest release receives security fixes.
Read the security policy