💬 NLP

The Decomposition Is the Fingerprint: Per-Component Identity for Agent Skills

This paper introduces a compact, locality-sensitive per-component fingerprinting method for AI agent skills that uses multi-bank SimHash to generate fixed-size signatures, enabling the identification of skill lineage and structural relationships through paraphrasing or refactoring while distinguishing independent re-implementations, all without replacing the need for behavioral safety verification.

Original authors: Hongliang Liu, Yuhao Wu, Tung-Ling Li

Published 2026-07-01

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Hongliang Liu, Yuhao Wu, Tung-Ling Li

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are managing a massive library of "skills" for AI agents. These aren't just books; they are digital toolkits containing instructions (prompts), code, and connections to other tools. As more people create these skills, the library gets messy. The same skill might be copied, renamed, rewritten in a different style, or even translated into another programming language.

The big problem? How do you know if two skills are actually the same thing, even if they look different on the surface?

The Old Way: The "Fingerprint" That Breaks

Traditionally, to check if two files are the same, we use a cryptographic hash (like a digital fingerprint). But this method is too sensitive. It's like taking a photo of a person's face, but if they change their hair by one inch or put on glasses, the photo looks completely different. In the digital world, changing just one letter in a prompt or renaming a function in the code makes the "fingerprint" look totally new. This is useless for finding duplicates that have been tweaked.

The New Way: The "Per-Component" Fingerprint

The authors propose a new kind of fingerprint that is smart and modular. Instead of looking at the whole skill as one big blob, they break it down into three distinct parts:

The Prompt: The natural language instructions.
The Code: The actual logic and functions.
The Tools: The list of APIs or external tools it uses.

Here is how their system works, using a simple analogy:

1. The "Translator" (Embedding)

First, the system acts like a super-smart translator. It reads the prompt, code, or tools and converts them into a "meaning vector."

Analogy: Imagine you have a sentence in English and the same sentence in French. A normal scanner sees them as totally different strings of letters. This "translator" understands that they mean the same thing and gives them the same "concept ID." It does this for code too, understanding that calculate_sum and add_numbers are doing the same job.

2. The "Compressor" (Multi-Bank SimHash)

The "concept ID" is still too big to store easily for millions of skills. So, the system compresses it into a tiny, fixed-size digital signature (just 120 bytes, or 320 bits).

Analogy: Think of this as taking a high-resolution photo of a person and shrinking it down to a tiny, 320-pixel icon. Even though it's tiny, if you compare two icons, you can still tell if they are the same person. Crucially, if the person changes their shirt (a minor edit), the icon stays recognizable.

3. The "Three-Part ID Card" (The Triple)

This is the paper's most important innovation. Instead of squishing the three parts (Prompt, Code, Tools) into one single score, they keep them as three separate numbers on an ID card.

Analogy: Imagine a security badge with three separate photos: one of the person's face, one of their ID number, and one of their job title.
- If someone changes the Job Title but keeps the Face and ID Number the same, you know it's the same person with a new role.
- If someone changes the Face (rewrites the code) but keeps the Job Title (prompt) the same, you know it's a different person doing the same job.
- If all three match, it's a perfect clone.

What This Solves

By keeping these three parts separate, the system can answer complex questions that a simple "yes/no" hash cannot:

Cloning: "Is this a copy of that skill?" (All three parts match).
Repurposing: "Is this the same code being used for a different purpose?" (Code matches, Prompt is different).
Reimplementation: "Is this the same idea written in a totally different way?" (Prompt matches, Code is different).
Tampering: "Did someone sneak a virus into a trusted skill?" (The system sees that the "Face" and "Job Title" match a trusted skill, but the "ID Number" (code) has changed slightly. It flags it as a modified copy).

The "Safety" Warning

The paper makes a very clear distinction: This system identifies what a skill is, not if it is safe.

Analogy: This system is like a police database that recognizes a car as a "2020 Toyota Camry." It can tell you, "This car is a modified version of a known model, and the engine has been swapped."
However, it cannot tell you if the car is driving recklessly or if the new engine is dangerous. That requires a different kind of test (behavioral verification).
The authors found that many malicious skills are just "tampered copies" of safe skills. Their system catches them as "modified copies," but a human or a different safety tool must decide if the modification is dangerous.

Why It Matters

This method creates a "Registry" for AI skills. It allows platforms to:

Stop duplicates: Find skills that are the same but look different.
Track lineage: Know where a skill came from and how it changed.
Detect tampering: Spot when a trusted skill has been quietly altered.
Save space: The new fingerprint is 77 times smaller than the original data, making it fast to search through millions of skills instantly.

In short, the paper argues that to manage the chaos of AI skills, we need a fingerprint that understands meaning and structure, not just a scanner that looks for exact letter matches. And by keeping the parts separate, we get a much clearer picture of how skills are related.

Technical Summary: Per-Component Identity for Agent Skills

1. Problem Statement

As Large Language Model (LLM) agents increasingly acquire and execute skills at runtime—bundles of prompts, executable code, and tool declarations sourced from marketplaces and other agents—platforms face a critical governance challenge: identity. Current methods for determining if two skills are the "same" fail to meet the specific requirements of the agent ecosystem:

Cryptographic Hashing: Fails because it is not rewrite-invariant; a single character edit (paraphrase, renaming, refactoring) completely scrambles the digest, destroying similarity.
Fuzzy Hashing (e.g., ssdeep, TLSH): Relies on spatial byte locality, which skills lack due to semantic rewriting. These methods perform near chance (AUC 0.53–0.63) on rewritten skills.
Raw Embeddings: While accurate in capturing semantic similarity, they store kilobyte-scale floating-point vectors, lacking the constant-size, bit-indexable signatures required for scalable registries.
Standard SimHash: Designed for single-document deduplication, it lacks component decomposition and cannot distinguish between "same code, different purpose" and "same purpose, different code."

The core problem is the need for a compact, locality-sensitive fingerprint that is rewrite-invariant, constant-size, component-localizing, and calibrated, capable of identifying skill families rather than just exact byte matches.

2. Methodology

The authors propose a per-component, locality-sensitive fingerprint pipeline (Figure 1) that decomposes a skill into its constituent parts before hashing.

2.1 Decomposition

A skill $S$ is treated as a structured artifact composed of textual components:

Prompt: Natural language instructions.
Code: Executable implementation.
Tools: API or tool declarations.
(Optional components like config or examples are also supported.)

2.2 Convergent Transformation (Embedding)

Each component is independently embedded using a learned text encoder $E(\cdot) \to \mathbb{R}^d$ (specifically Google's text-embedding-005, $d=768$ ). This encoder acts as a convergent transformation, mapping functionally equivalent components (despite paraphrasing, renaming, or refactoring) to geometrically proximate vectors. The embedding model provides the rewrite invariance.

2.3 Multi-Bank SimHash

To achieve compactness, each 768-dimensional embedding is projected to bits using SimHash [5].

Mechanism: For each component, 320 independent random hyperplanes are drawn. The sign of the dot product between the embedding and each hyperplane normal determines a single bit.
Structure: The 320 bits are packed into five 64-bit words ("banks").
Result: A fixed 120-byte signature (3 components × 40 bytes each) for the skill. Crucially, the three component codes are never collapsed into a single scalar within the fingerprint; they remain a triple.

2.4 Comparison

Two skills are compared component-by-component using Hamming distance.

Similarity for a component: $sim = 1 - \frac{\text{popcount}(F_A \oplus F_B)}{320}$ .
The comparison is $O(1)$ and extremely fast (microseconds), utilizing bitwise XOR and population count instructions.
Applications can aggregate the triple (e.g., max for recall, min for strict cloning, or weighted means) based on specific registry needs.

3. Key Contributions

Per-Component Decomposition: The primary contribution is retaining the fingerprint as a triple (prompt, code, tools) rather than a single score. This allows the system to:
- Distinguish between lineage (structural similarity) and behavioral equivalence.
- Localize exactly which part of a skill has been reused or tampered with (e.g., same code, different prompt = repurposing; same prompt, different code = reimplementation).
- Enable relationship classification (clones, variants, tool swaps) without additional models.
Compact, High-Fidelity Signature: The method compresses a 24,576-bit embedding into 120 bytes (77× compression) while preserving the ranking of the original cosine similarity to within 1% AUC.
Registry Primitive: The fingerprint serves as the structural axis for a skill registry, enabling deduplication, family clustering, novelty detection, and the generation of a portable SkillBOM (Software Bill of Materials).
Identity vs. Safety Distinction: The paper explicitly claims that the fingerprint provides identity (lineage), not safety. It can identify a skill as a tampered copy of a known benign base but cannot determine if the copy is malicious.

4. Experimental Results

The authors evaluated the fingerprint across multiple corpora and benchmarks:

Fidelity to Embedding: On 4,950 pairwise comparisons of constructed skill variants, the fingerprint achieved an AUC of 0.974 (95% CI [0.956, 0.994]). Per component, it tracked the embedding cosine within 1% (0.992 vs 0.993) at 77× compression.
Adversarial Robustness: On a benchmark of 50 adversarial rewrites (including cross-language translation, obfuscation, and full rewrites), the fingerprint recognized 45/50 rewrites, whereas a lexical TF-IDF baseline recognized only 5/50.
Relationship Classification: The per-component triple correctly classified 62% of same-group pairs as clones and 24% as tool-swaps, with a false-clone rate of only 0.2% across cross-group pairs.
Tamper Localization: In a 906-skill injection benchmark, the fingerprint identified 83.7% of malicious skills as near-clones of benign ones. Crucially, it localized the tampering: the code component similarity dropped (0.92–0.95) while prompt and tools remained high, pinpointing the injection location.
Safety Limitation: As a safety detector alone, the structural fingerprint achieved an F1 of 0.735 (vs. 0.946 for behavioral verification), confirming that structural identity is orthogonal to behavioral integrity.

5. Significance and Claims

The paper argues that identity is the structural axis of a skill registry, distinct from and complementary to behavioral verification.

Lineage over Equivalence: The fingerprint claims to identify "lineage" (is this a copy/variant of a known skill?) rather than "behavioral equivalence" (does it do the same thing?). This distinction is vital for governance, allowing platforms to audit provenance and detect tampering without making safety verdicts.
Scalability: By reducing skills to 120-byte, bit-indexable signatures, the method enables constant-time comparisons and efficient indexing for millions of skills, a feat impossible with raw embeddings.
Composability: The authors posit a "two-axis model" of trust: Structural Identity (this work) + Behavioral Integrity (runtime verification). The fingerprint handles the "who/what" (lineage, tampering, reuse), while behavioral checks handle the "how safe" (runtime behavior).
Modesty: The authors explicitly state that the fingerprint is not collision-resistant (an adversary could theoretically craft a skill to mimic a trusted family) and is not a safety verdict. It is a triage and lineage signal designed to be paired with cryptographic hashes and behavioral checks.

In summary, the paper presents a practical, mathematically grounded solution for managing the exploding supply of AI agent skills, transforming similarity from a single number into a rich, component-level signal for registry management and provenance tracking.