LogVeil, from Zindagi Technologies

Send the bundle. Keep the network.

LogVeil takes an OEM diagnostic bundle in and gives back the same bundle with every sensitive value rewritten consistently under the customer's own policy, plus a signed Sanitisation Attestation stating exactly what was done, what was checked and what is not asserted — so the bundle can go to the vendor's technical assistance centre without exposing the network it came from.

SPECIMEN — SYNTHETIC VALUES · a specimen of intended behaviour, not a claim about today
! fmc-troubleshoot · running-config hostname EXAMPLE-CORE-01 SITE-07-CORE-01 interface Management0/0 ip address 203.0.113.17 10.1.1.17 255.255.255.0 snmp-server community s3cr3t-c0mmun1ty <REDACTED:S7> RO ntp server 203.0.113.9 10.1.1.9 license udi sn SN-000123 SN-9c41e7 ! archived: /var/log/ capture-jdoe.pcap capture-4f9a.pcap neighbor 203.0.113.17 10.1.1.17 state established attested · policy-conformant sanitisation, verified by independent scanners, with declared non-assertions · signed Ed25519

The problem, in the buyer's words

The bundle is the network

What a bundle carries

Every network team that runs Cisco, Check Point, Radware, Fortinet or Infoblox gear eventually opens a case with the vendor's technical assistance centre, and the TAC asks for the diagnostic bundle: the firewall-management troubleshoot file, the identity-services support bundle, the network-controller RCA, the single enormous text dump from the firewall cluster. That bundle is the network in a box — management and data addresses, subnets, hostnames that encode sites, serial numbers, SNMP communities and RADIUS secrets, hundreds of certificates and private keys, usernames, engineers' names in filenames, and timestamps and paths that give away the rest. The vendor is honest but foreign-jurisdiction, under no duty to protect the topology, and may keep the bundle indefinitely.

Three choices, all bad

Today the team has three choices, all bad. Send it raw and accept the exposure. Scrub it by hand — days of search-and-replace on a multi-gigabyte archive that nests eleven levels deep, with binary members nobody can open, and no way to know what was missed. Do not send it and live with the outage while the case stalls.

Scale, measured on real bundles in our lab.

files
11,412
seven levels deep — one Cisco FMC troubleshoot bundle
files
40,821
nine deep — a Cisco FTD high-availability troubleshoot
files
11,529
eleven deep — a third bundle
one member
4.98 GB
inside a Cisco ISE support bundle
expansion
15×
a Catalyst Center RCA bundle, to 73 GB
of content
113.8 GB
from 11.4 GB on disk — nine bundles, 66,802 files, 2,216 nested archives

A single Cisco FMC troubleshoot bundle holds 11,412 files nested seven levels deep; a Cisco FTD high-availability troubleshoot, 40,821 files, nine deep; a third bundle, 11,529 files, eleven deep; a Cisco ISE support bundle carries one member of 4.98 GB; a Catalyst Center RCA bundle expands fifteen-fold, to 73 GB. Across nine bundles: 66,802 files, 2,216 nested archives, 113.8 GB of content from 11.4 GB on disk. Nobody hand-scrubs that.

How LogVeil works

Seven stages, one compiled map, a signed statement

in development

Nothing is rewritten until the whole map exists. The first pass walks every member and collects the observed value set per class. The map is then compiled as a total function over the observed set — dictionary first, algorithmic fallback, validation against the output pool, and an injectivity check: no two originals may share a replacement, and no algorithmic output may collide with a dictionary target or with an observed unmapped value; on a collision the value is re-derived with a recorded tweak counter. The second pass rewrites. No unmapped value leaves the engine unless it is on the preserve list — silent pass-through would make reversal ambiguous.

  1. ingest

    Containers are detected by their bytes, never by their names, and nested archives are walked to any depth; the input is hashed before anything runs.

  2. inventory

    Every member discovered — path hash, size, detected type, depth, container chain — is recorded before any transform runs; the attestation is later checked against it.

  3. collect

    The first pass walks every member and collects the observed value set per class; filenames, archive paths and container headers count as content.

  4. compile

    The complete map is compiled before anything is rewritten — dictionary first, key-derived transforms as the fallback — and checked so that no two originals share a replacement.

  5. rewrite

    The second pass rewrites. No unmapped value leaves the engine unless it is on the preserve list; secrets are dropped and marked, never tokenised.

  6. verify

    A separate stage with its own code path re-scans the output with independent scanners and fails closed: a canary hit, an unresolved review item or a scanner error means no output.

  7. attest

    A signed Sanitisation Attestation records what was done, what was checked, by which scanners, with what result — and what is explicitly not asserted.

Structure-aware, whole-bundle

in development

LogVeil understands the anatomy of the bundle — every member, every nested archive, every filename and header — and has no file-size ceiling.

LogVeil detects containers by their bytes, not their names, and walks nested archives to any depth. It knows what a Cisco FMC or FTD troubleshoot, an ISE support bundle and a Catalyst Center RCA look like inside — which members are logs, which are object dumps, which are certificates, which are database exports — and it treats filenames, archive paths and container headers as content, because they leak too: in one Catalyst Center bundle, fifty-five gzip headers were found carrying original filenames. Processing streams member by member with bounded memory, so a multi-gigabyte member is handled the same way as a small one.

Your policy, your dictionary, your key

in development

The customer writes the rules and holds the key; Zindagi never sees either.

The policy is a versioned, signed YAML document owned by the customer. Explicit dictionary pins — this subnet to that subnet, this site name to SITE-07 — always win; prefix length is preserved, and a rule whose two sides differ in length is rejected when the policy is compiled. Everything else is rewritten by key-derived, prefix-preserving transforms, so subnet structure survives and the TAC can still reason about the topology. The same key gives the same replacement across bundles and across time, so a case thread that spans several uploads stays coherent. Secrets are never tokenised — credentials, keys and private-key bodies are dropped and marked.

Verified — and honest about what isn’t

in development

A separate verification stage re-scans the output with independent scanners, fails closed, and signs an attestation that also says what is not claimed.

Verification is its own stage with its own code path, run on the output bundle, never on the engine's internal state. The engine's recognisers re-run on the output; a differential canary scan searches for every original value in every enumerated encoding across every member and every container-metadata field; independent secret scanners (gitleaks and detect-secrets) run unmodified; container metadata is checked against a versioned residual-leak catalogue; every passed-through binary is listed. A job with a canary hit, an unresolved review item or a scanner error produces no downloadable output. The signed Sanitisation Attestation records per-member actions with hashes, policy and pack versions, the scanners run and their results, the time source — and the non-assertions: classes outside the policy, encodings outside the enumerated list, binaries passed through by name, structural inference that was not rewritten, unknown member formats, anything the review queue overrode. A standalone tool verifies any output against its attestation without the server.

Reversible under control

in development

When the TAC replies about a masked address, your engineer can translate it back — and nobody else can.

Nothing unmapped leaves the engine; the complete map is compiled before anything is rewritten, checked for collisions, and stored encrypted with envelope keys. Reversal is per token: a Reverser submits a masked value and a justification, a second person approves, the original is returned, and the whole exchange is written to an append-only, hash-chained audit log. Bulk export of the map is not a function of the product. The key-encryption key is never at rest in plaintext.

In depth: how it works →

Verified — and honest about what isn't

What the attestation says — and what it doesn't

in development

Does an attestation mean the output contains nothing sensitive? No. LogVeil does not promise that nothing sensitive remains. It states, in a signed attestation, what was rewritten, what was dropped, what was passed through, which scanners checked the output and what they found, and what is explicitly not asserted. In the vocabulary the attestation itself uses: policy-conformant sanitisation, verified by independent scanners, with declared non-assertions. The non-assertions are mandatory text in every attestation, and they are the part to read first, because they tell the security cell exactly where to look.

SPECIMEN — SYNTHETIC VALUES · a Sanitisation Attestation, condensed; field names are illustrative — the schema is published with the full product

Read the non-assertions first

  1. classes outside the policy: S5 location and S10 organisational identifiers were not enabled in policy example-release v3
  2. encodings outside the enumerated list were not searched
  3. binary members passed through unread: db-export.bin, core.7712, trace-04.bin
  4. structural inference (S13) not rewritten: subnet sizes, host counts, timing, port mix
  5. unknown member formats: 2 members of unrecognised type passed through, listed
  6. review overrides: 1 candidate accepted as a version string by the reviewer
  7. truncation: none
job
specimen-fmc-troubleshoot · tenant example-org · 2026-09-05T10:22:41+05:30
time source
chrony against the local clock; not externally verified
input
sha256 e3b0…b855 · 1,557,239,808 bytes · gzip/tar
inventory
1,284 members · 41 nested archives · max depth 5 · manifest 0f2a…77e1
policy
example-release v3 · sha256 7c1e…a90b · signed by policy-author
versions
engine 0.9.2 · profile [email protected] · packs core-network 1.2.0, secrets 1.1.3, cisco 1.0.7 · residual-leak catalogue 1.1.0
key id
tenant-key-example-org-2026-08 (the identifier, never the key)
output pool
100.64.0.0/10
members
rewritten 1,279 · dropped 1 (member action: drop, declare) · passed through as binary 3 · allowlisted 1
scanners
engine-rescan 0.9.2 no hits · canary-differential 0.9.2, 11 encodings, no hits · gitleaks 8.21.2 no findings · detect-secrets 1.5.0 no findings · container-metadata (catalogue 1.1.0) no residue · binary-classifier 3 members listed
review
items 2 · accepted 1 · overridden 1 · operator-01 · reviewer-02
utility checks
structural diff pass · well-formedness pass · referential integrity pass · look-alike survival pass
signature
ed25519 · install-key-2026-08 · RW…

The vocabulary the attestation uses

policy-conformant sanitisation, verified by independent scanners, with declared non-assertions.

The attestation is not a promise: it says, precisely, what was done, what was checked and what is not asserted — the only honest statement a tool can make about arbitrary input, and a more useful one than a promise, because it tells the reader exactly where to look. The words that assert certainty are absent from the attestation, from the product and from these pages, by design.

SPECIMEN — SYNTHETIC VALUES · verifying without the server
$ logveil verify <output-bundle> <attestation>
signature    valid    (install-key-2026-08)
membership   match    (1284 members, 0 missing, 0 extra)
hashes       match    (1284 of 1284)

logveil verify checks an output bundle against its attestation — the signature, the membership, the hashes — without the LogVeil server, on any machine. A security cell can run it before release; an auditor can run it later; the recipient can run it on arrival. The argument form above is a placeholder; the command’s own documentation is definitive.

In depth: the attestation →

Your policy, your dictionary, your key

The customer writes the rules and holds the key

in development

The policy is a versioned, signed YAML document owned by the customer. Explicit dictionary pins — this subnet to that subnet, this site name to SITE-07 — always win; prefix length is preserved, and a rule whose two sides differ in length is rejected when the policy is compiled. Everything else is rewritten by key-derived, prefix-preserving transforms, so subnet structure survives and the TAC can still reason about the topology. The same key gives the same replacement across bundles and across time, so a case thread that spans several uploads stays coherent. Secrets are never tokenised — credentials, keys and private-key bodies are dropped and marked.

SPECIMEN — SYNTHETIC VALUES · dictionary rules from a policy excerpt
  1. subnet

    203.0.113.0/24 becomes 10.1.1.0/24

    an explicit pin — always wins; prefix length preserved

  2. hostname

    EXAMPLE-CORE becomes SITE-07

    a site name pinned to a site token

  3. keyword

    building-c becomes <dropped>

    a location word, dropped and marked

  4. preserve

    198.51.100.1 becomes 198.51.100.1

    a value deliberately left as it is (the documentation range, a resolver, a version string)

Prefix-preserving, key-derived

Everything a dictionary rule does not pin is rewritten by a prefix-preserving, key-derived transform: two addresses that share a prefix before rewriting share one after, so subnet structure survives and the TAC can still reason about the topology. Replacements are drawn into a declared output pool — by default the shared address space 100.64.0.0/10 of RFC 6598 — so a recipient knows that anything in it is a replacement.

Reversible under control

When the TAC replies about a masked address, your engineer can translate it back — and nobody else can.

Nothing unmapped leaves the engine; the complete map is compiled before anything is rewritten, checked for collisions, and stored encrypted with envelope keys. Reversal is per token: a Reverser submits a masked value and a justification, a second person approves, the original is returned, and the whole exchange is written to an append-only, hash-chained audit log. Bulk export of the map is not a function of the product. The key-encryption key is never at rest in plaintext.

In depth: the policy →

Built for the air gap

An offline kit for your own VMs; nothing phones home; AI is optional, off by default, and never touches the result.

in development

LogVeil is delivered as an offline kit — signed image tarballs, a digest-pinned compose file, installer, migrations, a software bill of materials per image, signed checksums and the source archive or written offer for every GPL component shipped — for the customer’s own virtual machines, on amd64 and arm64, on Ubuntu 24.04 LTS or RHEL/Rocky 9. A zero-egress smoke test runs a full job with outbound network blocked. There is no telemetry, no update check, no external font or script. AI is disabled unless an administrator enables a provider; anything not yet verified may be shown only to a local model on the same host with egress blocked; external providers receive verified output or synthetic data, enforced in code; AI opens review items and never changes a map or an attestation. An appliance with a local GPU is on the roadmap.

LogVeil runs inside the customer’s network: the offline kit in the customer’s own virtual machines; the sanitised bundle and its attestation are the one thing that leaves, under the customer’s own release decision; nothing reaches Zindagi. THE CUSTOMER’S NETWORK — AIR GAP · NOTHING OUTBOUND OUTSIDE THE NETWORK Operator · Reviewer · Reverser · Auditor browser over HTTPS; seven roles, enforced OEM diagnostic bundle in upload or mounted path; never leaves the network raw Your policy, your key written and signed by the customer; generated and held in the deployment; Zindagi sees neither LogVeil offline kit in the customer’s own VMs · Docker Compose web — nginx one HTTPS origin;serves the app andproxies the API api every role check onevery request; auditof every change workers ingest · collectcompile · rewriteverify · attest database PostgreSQL; the jobqueue; no broker blob store filesystem or objectstore; inputs deletedafter the job ai-local optional; off bydefault; never changesa result THE MAP encrypted per job; reversalper token, two-person rule;hash-chained audit THE KEY unwrapped at start from theadmin’s passphrase; neverat rest in plaintext zero-egress test: a full job with outbound network blocked no telemetry · no update checks · no external font or script signed images · pinned compose · SBOM per image · signed manifest Sanitised bundle + attestation + report every value rewritten under the policy; non-assertions declared; verified by independent scanners before release Release decision: the customer’s own The vendor’s technical assistance centre receives the sanitised bundle and its attestation Zindagi no channel in or out: no copy of the bundles, the policy, the key, the map, the attestations or the audit log reaches us LogVeil runs inside the customer’s network: the offline kit in the customer’s own virtual machines; the sanitised bundle and its attestation are the one thing that leaves, under the customer’s own release decision; nothing reaches Zindagi. THE CUSTOMER’S NETWORK — AIR GAP Operator · Reviewer · Reverser · Auditor browser over HTTPS; seven roles, enforced on every request OEM diagnostic bundle in upload or mounted path; never leaves the network raw Your policy, your key written and signed by the customer; held in the deployment; Zindagi sees neither LogVeil offline kit in the customer’s own VMs · Docker Compose web — nginx one HTTPS origin api role checks; audit workers ingest … verify · attest database PostgreSQL; no broker blob store inputs deleted after ai-local optional; off by default THE MAP encrypted; per-token reversal THE KEY never at rest in plaintext zero-egress test · no telemetry · no update checks no external font or script · signed images SBOM per image · signed manifest Sanitised bundle + attestation + report every value rewritten under the policy; non-assertions declared; verified before release Release decision: the customer’s own OUTSIDE THE NETWORK The vendor’s technical assistance centre receives the sanitised bundle and attestation Zindagi no channel in or out — nothing reaches us

Drawn by code from the product’s specification; not a screen.

The offline kit

in development
  • signed image tarballs
  • a digest-pinned compose file
  • installer and migrations
  • a software bill of materials per image
  • signed checksums
  • the source archive or written offer for every GPL component shipped

For the customer’s own virtual machines, on amd64 and arm64, on Ubuntu 24.04 LTS or RHEL/Rocky 9.

Hypervisor images

planned

OVA for VMware, qcow2 for KVM, VHDX for Hyper-V — built from the same kit.

An appliance

planned

A server with a local GPU for local AI and TPM-sealed keys. No bill of quantities, no price — it is a roadmap item.

What Zindagi never receives

No copy of any customer data ever leaves the deployment: not the bundles, not the policy or the key, not the map, not the attestations or the audit log unless the customer chooses to share them. The product has no remote-access or remote-support channel.

In depth: deployment →

The public roadmap

Bundle formats, by status

The table below is LogVeil's public roadmap and carries three statuses only. Supported in early access means within the scope of the early-access programme; in development means being built now; planned means committed but not yet started.

Bundle formats by OEM, with each family’s status
OEM Bundle family Status
Cisco Secure Firewall Management Center (FMC) troubleshoot bundle Nested archives, rotated logs, object dumps, certificates and embedded databases are inventoried and handled per policy. supported in early access
Cisco Secure Firewall Threat Defense (FTD) troubleshoot bundle, including high-availability pairs Same family as the FMC bundle; handled by a profile. supported in early access
Cisco Identity Services Engine (ISE) support bundle Encrypted bundles are decrypted with the key entered at job start and re-encrypted for the recipient; large database exports are declared, never silently passed. supported in early access
Cisco Catalyst Center (formerly DNA Center) RCA and support bundles Very large, deeply nested bundles; processing streams with bounded memory. supported in early access
Check Point Gaia cpinfo Single-file bundle with embedded sections. in development
Cisco IOS-XE show tech-support and binary trace (btrace) archives Binary trace members are declared in the attestation. in development
Radware Alteon ADC and vADC techdata Includes embedded packet captures, which are declared. in development
Radware DefensePro / NIPS support bundle in development
Cisco Catalyst 9800 wireless LAN controller debug bundle planned
Fortinet FortiGate TAC report and console log planned
Infoblox NIOS support bundle planned
Juniper Junos request support information (RSI) planned
Palo Alto Networks PAN-OS tech support file (TSF) planned
Any Packet captures (pcap, pcapng) — standalone or inside a bundle Recognised, inventoried and declared today (passed through or dropped by policy); rewriting of capture contents is planned. planned
Any Generic text archive (unknown bundle types) Conservative defaults with a loud non-assertion in the attestation. planned

Statuses move only on approval, with the date recorded in the register.

In depth: formats by status →

Early access

Request early access

LogVeil is in development. An early-access programme opens after our first field trial.

Early access is a free, guided proof-of-concept on your own bundles inside your own network: you choose the bundles, you write the policy with our help, and you keep the key; we hand over the offline kit, run the first jobs with your engineers, and leave you with the attestations.

Tell us who you are, which estate you run and what you would want the first jobs to cover. We will come back to you when early access opens.

OEM estate

Or write to [email protected].