CipherWeave

Technical overview

How CipherWeave protects — and proves — an application path.

Discovery evidence, protection boundaries, cryptography, approval controls, runtime checks and signed evidence, in one reference.

  1. 01Discovery
  2. 02Architecture
  3. 03Cryptography
  4. 04Approval
  5. 05Verification
  6. 06Evidence

01 · Discovery

See the communication paths already inside the application.

CipherWeave examines repository evidence and turns configured endpoints, listeners, protocols and service relationships into a communication map. The operator can compare the visual topology with the underlying evidence, assign deployment boundaries and select the exact path that needs protection.

cipherweave / applications / communication map
CipherWeave communication map showing an MQTT device, application services, a Mosquitto broker and an external service discovered from repository evidence.
Repository-supported communication map. Highlighted connections can be selected for protection; dimmed relationships remain visible for context.
  • Evidence before inferenceEvery path remains linked to the repository findings that support it.
  • Context before selectionApplication, messaging, device and external relationships stay visible together.
  • One bounded pathThe selected connection becomes the scope for design, approval and verification.

02 · Architecture

One protected connection between two Weavelets.

The Field Weavelet sits beside the source and protects its traffic. CW1 carries it between deployment points. The Cloud Weavelet restores the original protocol beside the destination. The application on either side is unchanged.

  • No code changesBoth endpoints keep their existing protocol.
  • Deliberate boundariesProtection is added only on the paths you choose.
  • Bypass is testedDirect and alternate routes are checked to be blocked.

03 · Cryptography

Standardised post-quantum algorithms, end to end.

Every CW1 session uses NIST-standardised algorithms at their highest security levels.

Key establishment ML-KEM-1024

Agrees the session key. Resistant to harvest-now, decrypt-later attacks.

NIST FIPS 203
Peer authentication ML-DSA-87

Each Weavelet proves its identity to the other. Also signs the evidence package.

NIST FIPS 204
Traffic encryption AES-256-GCM

Encrypts and authenticates application traffic inside the channel.

NIST FIPS 197 · SP 800-38D

04 · Approval

One review. Three scoped approval records.

Everything that will run is frozen before approval. Each record binds the exact digest for its scope, so any affecting change requires approval again.

  1. 1
    Protection pathWhich connection is protected, and how.
  2. 2
    Deployment bundleThe exact Weavelet binaries and configuration.
  3. 3
    Functional test contractThe workload and checks the run must satisfy.

The runtime binding to the live connection is recorded separately. It satisfies the execution gate but is not an approval.

cipherweave / configure
CipherWeave approval screen showing three approval records: protection path, deployment bundle and functional test contract, plus the runtime binding.
Product screen from a pilot run on an MQTT device application.

05 · Verification

Fourteen checks across five control questions.

The approved workload runs through the protected path. Every verdict is bound to the application, path, deployment, approval, test contract and run it covers.

4Does the application work?
  • Request accepted
  • Command published
  • Device replied
  • Transaction reconciled
3Did traffic use the protected path?
  • Protected route observed
  • Direct bypass blocked
  • Alternate bypass blocked
3Is required security active?
  • Approved cipher suite in use
  • Weavelet peers authenticated
  • No prohibited plaintext on the wire
3Does deployment match approval?
  • Binary matches approved digest
  • Effective configuration matches
  • Application source identity matches
1Did response time meet the limit?
  • Protected p95 within the approved threshold
PASSThe control was evaluated and held.
FAILThe control was evaluated and did not hold.
INCOMPLETEThe evidence needed to decide was not produced. Never reported as a pass.
cipherweave / results
CipherWeave results screen: selected signed run passed with 14 passed, 0 failed, 0 incomplete; latency p95 53.32 ms against a 1000 ms limit over 20 protected transactions; evidence signed with ML-DSA-87.
Product screen from the same pilot run.

06 · Signed evidence

A verifiable record of one specific run.

The package connects approvals, deployment references, runtime observations and evaluated checks, and is signed so anyone can confirm it has not been altered.

Result
14 passed · 0 failed · 0 incomplete
Response time
p95 53.32 ms · limit 1,000 ms · 20 transactions
Signature
ML-DSA-87 · 19 files · valid

What it does not claim: continuous protection. Any affecting change requires renewed approval and another run.

Start with one connection

Discuss your application with us.

Book a pilot Back to overview