Verify compliance criteria, explore audit logs, and preview the Shamir Secret Sharing algorithm in an interactive sandbox (M-of-N quorum decryption is on the product roadmap).
ShareBolt secures every session and ledger block using formal mathematical bounds.
Vault keys are divided into \(N\) distinct cryptographic shares. Any subset of size \(M\) can reconstruct the master key \(S = f(0)\) via Lagrange polynomial interpolation over the Galois Field \(GF(2^8)\):
To guarantee perfect forward secrecy, ShareBolt rooms dynamically rotate encryption keys at every transfer step using a one-way ratcheting function based on HKDF-SHA256:
Establishing identity verification, runtime isolation boundaries, and network quotas for agentic workflows.
Traditional file transfers rely on centralized API keys or user passwords—credentials that cannot be safely managed by autonomous LLM agents without risk of exposure. ShareBolt shifts authorization to a cryptographic challenge model. Each agent generates an Ed25519 keypair and registers a Decentralized Identifier (DID) structured as a unique hex identifier. The public key is registered separately in the DID document — it is not embedded in the DID string itself:
When an agent requests a file download, the edge worker issues an ephemeral challenge string. The agent signs this challenge using its locally isolated private key and returns the signature. The proxy verifies the signature against the agent's DID document, authorizing the transfer without credentials ever passing over the wire.
AI agents are susceptible to prompt injection attacks where malicious files or inputs instruct the LLM to read private configuration directories (e.g. `/etc/passwd` or `.env` files) and exfiltrate them. ShareBolt enforces strict directory sandboxing on the client application level:
// Dart implementation verifying sandbox boundaries before file upload bool verifySandboxPath(String requestedPath, String allowedSandboxRoot) { final resolvedPath = File(requestedPath).absolute.path; final resolvedRoot = Directory(allowedSandboxRoot).absolute.path; // ✅ SAFE: require path separator after root to prevent directory-confusion attack. // e.g. '/tmp/sandboxEvil'.startsWith('/tmp/sandbox') === true — a false positive. // Adding Platform.pathSeparator closes this escape vector. return resolvedPath == resolvedRoot || resolvedPath.startsWith(resolvedRoot + Platform.pathSeparator); }
startsWith(root) check passes /tmp/sandboxEvil when the allowed root is /tmp/sandbox. The path separator suffix closes this gap — any resolved path that doesn't begin with /tmp/sandbox/ is rejected.
Any attempt by the agent to reference file paths outside the declared sandbox directory triggers an immediate violation trap, halting the transfer and logging a SECURITY_STATUS: SEC_AUDIT_REQUIRED block on the ledger.
To prevent compromised agents from silently streaming massive volumes of sensitive files, ShareBolt enforces daily upload limits in megabytes (MB) that are verified during chunk streams.
If an agent's daily cumulative transfers exceed its policy limit (e.g., 500 MB/day for standard agents), the edge gateway halts active chunk transfers, preventing runaway exfiltration loops and alerting the compliance administrator.
ShareBolt stores all logs in an immutable hash chain. Try tampering with Block 2 and see how our mathematical chain breaks instantly.
[iv:12][tag:16][ciphertext] — authentication tag prevents silent ciphertext tampering.sharebolt-envelope-key-v1 and sharebolt-ratchet-next-v1), so past session keys cannot be derived even if the current key is compromised.Platform.pathSeparator after the root; bare startsWith(root) is vulnerable to /tmp/sandboxEvil escapes.blockIndex|action|sender|recipient|fileHash|fileSize|classification|timestamp|prevHash|region — modifying any field breaks every downstream block.ShareBolt uses AES-256-GCM for file payload encryption (with a random 12-byte IV per file), X25519 for key exchange, Ed25519 for agent DID signing, and HKDF-SHA256 (RFC 5869) for perfect forward secrecy key ratcheting. Keys are derived and used client-side; plaintext and raw keys never reach ShareBolt storage.
Each agent registers an Ed25519 public key and receives a DID (did:bolt:agent:<hex-id>). On every transfer request the edge issues an ephemeral challenge string; the agent signs it with its local private key and the edge verifies against the DID document — no passwords or API keys traverse the wire.
A bare startsWith("/tmp/sandbox") check passes /tmp/sandboxEvil because the string is a prefix match. ShareBolt requires a path separator suffix (startsWith(root + Platform.pathSeparator)) so only genuine children of the allowed directory are accepted.
A vault key is split into N shares using Lagrange polynomial interpolation over Galois Field GF(2⁸). Any M of those shares can reconstruct the secret — without M shares, zero information about the key is leaked. The interactive demo on this page illustrates the algorithm; production M-of-N quorum decryption is on the roadmap.
Call GET /v1/transfers/ledger/verify (admin only). The route recomputes each block's SHA-256 hash from stored fields and checks it against the stored hash and Ed25519 signature. Any tampered field — including the storage region — will produce a hash mismatch flagged in the response. The Ed25519 public key is retrievable at GET /v1/audit/public-key.
ShareBolt stores all logs in an immutable hash chain. Try tampering with Block 2 and see how our mathematical chain breaks instantly.
Experience M-of-N secret splitting. Split the master vault key into shares, then collect a subset to reconstruct it. This interactive demo illustrates the Shamir Secret Sharing algorithm — production quorum decryption is on the roadmap.