VectorPin: Cryptographic Provenance for Embeddings

• VectorPin is a cryptographic provenance protocol that binds embeddings to their source text, model, and issuer to ensure tamper detection.
• It uses SHA-256 and Ed25519 signatures on canonical representations, providing cross-platform integrity verification in embedding stores.
• The protocol defends against steganographic exfiltration by flagging any post-embedding modifications with clear verification outcomes such as VECTOR_TAMPERED and MODEL_MISMATCH.

VectorPin is a cryptographic provenance protocol for embedding stores: a signed commitment that binds each embedding to its source text, producing model, and issuer, so any post-embedding tampering becomes detectable on read. It was proposed in "VectorSmuggle: Steganographic Exfiltration in Embedding Stores and a Cryptographic Provenance Defense" (Wanger, 13 May 2026) as a defense against steganographic exfiltration in retrieval-augmented generation systems, where embeddings are stored in vector databases that treat the resulting numerical artifacts as opaque.

1. Threat model and problem setting

The protocol is motivated by a class of attacks in which an adversary with write access to the ingestion pipeline hides payload data inside embeddings using post-embedding perturbations while preserving the surface-level retrieval behavior exposed to legitimate users. The paper formalizes three adversary tiers: A: Insider with backup access, which is the main evaluated model; B: Compromised vector-DB credentials; and C: Query-only, which is out of scope (Wanger, 13 May 2026).

The core exfiltration mechanism is simple: the attacker modifies a clean embedding $v \in \mathbb{R}^d$ after the model produces it, stores the modified vector, and later recovers the payload from the vector store or from backups. The studied perturbation variants are noise injection, rotation, scaling, offset, and a combined pipeline of noise $\to$ rotation $\to$ scaling $\to$ offset. The paper also studies cross-model fragmentation, which splits the source across multiple models or stores so that each store sees only a fragment. In all of these cases, the attack requires post-embedding modification or substitution, and that is precisely the condition that VectorPin commits to and detects.

The paper gives three reasons steganographic exfiltration is attractive relative to direct corpus dumping. Egress shaping makes traffic look like ordinary ingestion or read traffic. Targeted recovery means that only specific high-value documents need to be recoverable. Plausible deniability follows because stored vectors look like routine embeddings. VectorPin is therefore framed not as a retrieval-quality mechanism, but as an integrity control for the embedding substrate itself.

2. Canonical representation and attestation format

VectorPin uses SHA-256 for hashing, Ed25519 for signatures, and a canonical byte representation of the embedding so signatures are reproducible across languages. The paper explicitly notes that this is not a novel crypto primitive; it is a disciplined application of ordinary cryptographic provenance to a substrate that lacks native integrity controls (Wanger, 13 May 2026).

The vector commitment is defined by

$$hash\_vector(v, dtype) := \text{"sha256:"} \,\Vert\, \mathrm{hex}(\mathrm{SHA256}(\mathrm{canonical\_bytes}(v, dtype))).$$

Here canonical_bytes(v, dtype) casts the vector to the declared dtype (f32 or f64), stores it in little-endian byte order, and packs it as contiguous, 1-D bytes. The source-text commitment is

$$hash\_text(s) := \text{"sha256:"} \,\Vert\, \mathrm{hex}(\mathrm{SHA256}(\mathrm{UTF8}(\mathrm{NFC}(s)))).$$

The requirement of Unicode NFC normalization is significant because semantically equivalent strings are not allowed to mismatch due to normalization differences.

A VectorPin attestation is a JSON object with fixed provenance fields and two signature-related fields. Optional fields must be omitted entirely if not set, not emitted as null.

Field	Role	Requirement
v	protocol version	required
model	embedding model identifier	required
model_hash	hash of model weights	optional
source_hash	SHA-256 hash of normalized source text	required
vec_hash	SHA-256 hash of canonical embedding bytes	required
vec_dtype	embedding dtype	required
vec_dim	vector dimensionality	required
ts	RFC 3339 timestamp	required
extra	string-to-string map	optional
kid	signing key identifier	required
sig	Ed25519 signature	required

The signed material is not the raw JSON serialization as emitted by an arbitrary implementation. The signature excludes kid and sig themselves, and instead covers a canonical byte sequence of the header fields with all keys sorted lexicographically, no whitespace, UTF-8 encoding, extra key-sorted if present, and model_hash and extra omitted entirely when absent. This canonicalization is the interoperability anchor of the protocol.

3. Issuance and verification semantics

The issuance flow is defined as a fixed sequence. The issuer computes source_hash, computes vec_hash, constructs the canonical header JSON, signs the canonical bytes with the private Ed25519 key, and stores kid and sig in the Pin. Verifiers obtain the public key through a kid -> public key registry (Wanger, 13 May 2026).

Verification is equally explicit. A verifier MUST reject unsupported protocol versions with UNSUPPORTED_VERSION, reject unknown kid values with UNKNOWN_KEY, reconstruct the canonical byte sequence and verify the Ed25519 signature with SIGNATURE_INVALID on failure, recompute hash_text(source) when source text is supplied and return SOURCE_MISMATCH on mismatch, recompute hash_vector(vector, vec_dtype) when a vector is supplied and return VECTOR_TAMPERED or SHAPE_MISMATCH, and compare an expected model identifier against model with MODEL_MISMATCH if needed.

These result codes are operationally important because they distinguish provenance failures that arise from different causes. A signature failure is not the same as a source mismatch, and a tampered vector is not the same as an unsupported protocol version. The protocol therefore provides not only tamper evidence but also structured failure semantics that can be routed differently in production systems.

4. Security coverage against post-embedding tampering

The central security logic is that the signature binds vec_hash, and vec_hash is the hash of the exact canonical bytes of the embedding. Any post-embedding change therefore alters the bytes and changes the hash. If an attacker adds noise, rotates the vector, rescales it, offsets it, or substitutes fragments from another model, the stored vector no longer matches the signed commitment and verification fails (Wanger, 13 May 2026).

The paper maps the studied attacks to verification outcomes. Noise injection, rotation, scaling, offset, and combined attacks all yield VECTOR_TAMPERED. Cross-model fragmentation yields MODEL_MISMATCH. Replay onto a different vector yields VECTOR_TAMPERED. Re-signing with attacker key yields UNKNOWN_KEY or SIGNATURE_INVALID. Source substitution at retrieval yields SOURCE_MISMATCH.

This coverage is important because the attack paper emphasizes that the most difficult cases for distributional detection are exactly those that preserve retrieval behavior. Small-angle orthogonal rotation defeats distribution-based detection across every tested $(\text{model}, \text{corpus})$ pair, yet it still changes the exact embedding bytes and is therefore immediately visible to VectorPin. The defense is described as structurally complete against the studied tamper class because all of the studied attacks rely on changing the embedding after honest generation.

5. Relation to anomaly detection, retrieval behavior, and storage backends

The paper treats anomaly detection as useful but insufficient. For distribution-shifting attacks such as noise, offset, and some scaling, simple detectors including Isolation Forest and One-Class SVM often reach high AUC and can flag many operating points. However, the same evaluation shows that small-angle or few-rotation orthogonal rotations preserve pairwise inner products and per-dimension marginal distributions, leaving such detectors with essentially no signal at default settings (Wanger, 13 May 2026).

A second limitation is adaptivity. With white-box access, the attacker can optimize against the detector and drive AUC toward zero while keeping cosine similarity high. A third limitation is that detectability depends on training-set coverage and local embedding-manifold geometry. The paper’s conclusion is therefore that statistical detection is a useful first filter, but not load-bearing security. VectorPin is presented as the durable control because it does not depend on learned distributional assumptions.

The empirical context extends beyond detectors. The paper reports that attacks survive across multiple vector-store backends, which motivates a backend-independent provenance layer. It notes that scalar int8 quantization in Qdrant does not destroy the attack channel, that non-PQ backends preserve the payload, and that FAISS IVF-PQ reduces recoverable signal, but only incidentally through compression rather than as a provenance defense. It also reports that paraphrased-query retrieval can remain normal under cosine-invariant attacks such as rotation and scaling, so ordinary user-visible quality monitoring may not reveal tampering even when the embedding store has become a covert channel.

6. Guarantees, operational role, and explicit limits

VectorPin adds several concrete controls to retrieval-augmented generation and vector-store systems. It provides tamper evidence for stored embeddings, because any post-ingestion modification is detectable. It provides binding to source and model, because verifiers can detect SOURCE_MISMATCH and MODEL_MISMATCH separately. It provides auditability, because verification outcomes distinguish tampering from forgery from provenance mismatch. It is cross-language, backend-independent provenance, because the protocol uses one signature algorithm, one hash family, and fixed canonical bytes, with reference implementations in Python and Rust and cross-language test vectors enforcing bit-for-bit compatibility. It supports an operational quarantine path, because failed verification can trigger removal or quarantine before retrieval. It also supports key rotation, because multiple kid mappings can coexist during rotation, and it is intended to compose with upstream content provenance such as in-toto, SLSA, or signed-source controls (Wanger, 13 May 2026).

The protocol is equally explicit about what it does not guarantee. It does not solve confidentiality of embeddings, access control, anti-replay across collections by default, source-document authenticity before embedding, malicious signing at ingestion time, or private-key compromise. Those are described as upstream or orthogonal concerns.

Within that scope, VectorPin is a minimal provenance layer that makes the exact stored embedding bytes integrity-critical. Its significance lies in shifting the defense boundary from heuristic anomaly detection to cryptographic verification: if an embedding is changed after honest generation, the system can detect that fact directly, regardless of whether retrieval quality, corpus geometry, or backend behavior would otherwise conceal the modification.