Ask HN: What are you working on? (March 2026)
13 comments
Interesting gap between surface scanning (6.6%) and AI deep audit (16.4%).
Two concerns with the AI audit approach. First, the defense LLM is itself an attack surface — we're already seeing payloads crafted specifically to bypass LLM-based guardrails. If the guardian is injectable, you've added a vulnerability to your security stack.
Second, the Mindgard paper from late 2025 tested 12 character injection techniques against 6 guardrails including ProtectAI's DeBERTa, Meta Prompt Guard, Azure Prompt Shield — some hit 100% evasion rate. Homoglyphs, zero-width chars, leet, diacritics. Simple stuff, but the classifiers see raw tokens and can't handle it.
I built a prompt injection detection library that tackles this from the normalisation layer — 10-stage deterministic pipeline (NFKD, confusable fold, leet, base64, zero-width strip, ROT13, escape sequences) that reduces all evasion to canonical form before any matching. The scan itself is not injectable — it's code, not a model.
Where I think this goes next: small encoder-only classifiers (DeBERTa-small, ModernBERT) running on already-normalised text. Post-normalisation, the model only needs to detect the logical intent pattern, not handle evasion — that's the layer below. Too small to be reprogrammed via prompt, too focused to be redirected. One classifier per attack category: override, extraction, jailbreak, etc.
But these classifiers will only be as good as their training data. Right now everyone trains on static datasets (deepset, safeguard). What's missing is a community-maintained corpus fed by real-world incident reports — like antivirus signature databases. The detection engine matters less than the definitions it runs on. ClamAV isn't great because of its scan loop, it's great because thousands of people report samples.
Your foundry example — no payload until the agent writes it — is the genuinely hard case that needs AI. But for everything else, deterministic normalisation + focused micro-classifiers + community-curated signatures is a more defensible architecture than putting another LLM in the path.
https://github.com/hazyhaar/pkg/tree/main/injection
Two concerns with the AI audit approach. First, the defense LLM is itself an attack surface — we're already seeing payloads crafted specifically to bypass LLM-based guardrails. If the guardian is injectable, you've added a vulnerability to your security stack.
Second, the Mindgard paper from late 2025 tested 12 character injection techniques against 6 guardrails including ProtectAI's DeBERTa, Meta Prompt Guard, Azure Prompt Shield — some hit 100% evasion rate. Homoglyphs, zero-width chars, leet, diacritics. Simple stuff, but the classifiers see raw tokens and can't handle it.
I built a prompt injection detection library that tackles this from the normalisation layer — 10-stage deterministic pipeline (NFKD, confusable fold, leet, base64, zero-width strip, ROT13, escape sequences) that reduces all evasion to canonical form before any matching. The scan itself is not injectable — it's code, not a model.
Where I think this goes next: small encoder-only classifiers (DeBERTa-small, ModernBERT) running on already-normalised text. Post-normalisation, the model only needs to detect the logical intent pattern, not handle evasion — that's the layer below. Too small to be reprogrammed via prompt, too focused to be redirected. One classifier per attack category: override, extraction, jailbreak, etc.
But these classifiers will only be as good as their training data. Right now everyone trains on static datasets (deepset, safeguard). What's missing is a community-maintained corpus fed by real-world incident reports — like antivirus signature databases. The detection engine matters less than the definitions it runs on. ClamAV isn't great because of its scan loop, it's great because thousands of people report samples.
Your foundry example — no payload until the agent writes it — is the genuinely hard case that needs AI. But for everything else, deterministic normalisation + focused micro-classifiers + community-curated signatures is a more defensible architecture than putting another LLM in the path.
https://github.com/hazyhaar/pkg/tree/main/injection
I track everything in my Google Calendar — work blocks, side projects, gym, social time. But I could never answer 'where did my time actually go this week?' Google Workspace has Time Insights, but it's locked to paid accounts and doesn't work for personal Google Calendar.
Calens fills that gap: GitHub-style heatmap showing 52 weeks of calendar activity, weekly/monthly time breakdowns by calendar or tag, a progress chart of planned vs completed time, and a cleaner in-page event editor. Everything runs on-device — no servers, no tracking, no data leaving the browser.
Early-stage, looking for people who already log their life in Google Calendar and want better data on their habits. Happy to give free lifetime access in exchange for honest feedback.
Calens fills that gap: GitHub-style heatmap showing 52 weeks of calendar activity, weekly/monthly time breakdowns by calendar or tag, a progress chart of planned vs completed time, and a cleaner in-page event editor. Everything runs on-device — no servers, no tracking, no data leaving the browser.
Early-stage, looking for people who already log their life in Google Calendar and want better data on their habits. Happy to give free lifetime access in exchange for honest feedback.
I am working on an open-source library for encryption of application data on cloud storage (https://baolib.org/). The idea is a local application where a remote storage is a synchronization media between different peers.
The storage is encrypted and content is accessible only to the granted peers. The library supports file and SQL interface.
I will appreciate any feedback. Thank you!
I will appreciate any feedback. Thank you!
Nice try — the local-first distributed pattern worth building on.
Three questions:
Why blockchain for access rights? A signed Merkle structure or a Certificate Transparency-style log would give the same guarantees without the operational complexity. What does the blockchain add here that a simpler append-only signed registry doesn't?
The threat model is unclear. If the blockchain provider controls validation, the "accessible only to end users" guarantee depends on trusting that provider. This is the oracle problem — the chain guarantees integrity of what's inside it, but not the truthfulness of what gets written in. Who runs the chain, and what happens if they're compromised or write false access rights?
Go is listed first in the bindings but the example code is Python. Is the Go binding at feature parity, or is Python the primary target?
Three questions:
Why blockchain for access rights? A signed Merkle structure or a Certificate Transparency-style log would give the same guarantees without the operational complexity. What does the blockchain add here that a simpler append-only signed registry doesn't?
The threat model is unclear. If the blockchain provider controls validation, the "accessible only to end users" guarantee depends on trusting that provider. This is the oracle problem — the chain guarantees integrity of what's inside it, but not the truthfulness of what gets written in. Who runs the chain, and what happens if they're compromised or write false access rights?
Go is listed first in the bindings but the example code is Python. Is the Go binding at feature parity, or is Python the primary target?
Hi Horos,
thanks for your comments. I really appreciate!
1. Perhaps I am misusing the "blockchain" term. The access is granted with signed blocks. Each block can introduce some changes, like granting/removing access to other users, including the encryption key with an envelope. Each block links to the previous via hash. There is no consensus mechanism.
2. The vault is defined by a storage and the public keys of the creator. A client must know in advance the creator keys and he will use those keys to verify the signature. The creator then can grant admin rights to other users with specific blocks. An access grant not signed by an admin, will be rejected by a user. It is not really about data truth, because the target is more information exchange. Does it answer the question?
3. Go is the implementation language, not really a binding. I use Python in the first example because it is more compact. However the guide shows samples for all supported languages. The primary target is Go for server side and Dart for mobile. Python is effective for samples and experiments.
1. Perhaps I am misusing the "blockchain" term. The access is granted with signed blocks. Each block can introduce some changes, like granting/removing access to other users, including the encryption key with an envelope. Each block links to the previous via hash. There is no consensus mechanism.
2. The vault is defined by a storage and the public keys of the creator. A client must know in advance the creator keys and he will use those keys to verify the signature. The creator then can grant admin rights to other users with specific blocks. An access grant not signed by an admin, will be rejected by a user. It is not really about data truth, because the target is more information exchange. Does it answer the question?
3. Go is the implementation language, not really a binding. I use Python in the first example because it is more compact. However the guide shows samples for all supported languages. The primary target is Go for server side and Dart for mobile. Python is effective for samples and experiments.
Thanks for sharing — always a pleasure to discover what others are building.
A few thoughts after your answers:
The E2E file sync part has existing solutions, and your access rights system is really a signed append-only log rather than a blockchain (no consensus, no decentralization) — which is fine, but the term might create misleading expectations.
What I'm more curious about is the access model itself. How are access tokens created and transferred? Who consumes them, and how does authorization propagate? Have you considered a salted API where each user carries a unique identifier, so the whole grant/revoke/delegate flow goes through a single unified mechanism regardless of what's being accessed?
The SQL sync layer is what actually caught my eye — I've worked on similar problems for specific use cases, and encrypted database sync between peers is a genuinely hard problem. That feels like your real differentiator.
On that note: does the SQL layer reference the file content or file paths? I'm guessing you built both interfaces because they're correlated — the SQL holds structured data that points to the encrypted files. If so, that's worth making explicit, because right now they look like two unrelated features rather than two sides of the same system.
A few thoughts after your answers:
The E2E file sync part has existing solutions, and your access rights system is really a signed append-only log rather than a blockchain (no consensus, no decentralization) — which is fine, but the term might create misleading expectations.
What I'm more curious about is the access model itself. How are access tokens created and transferred? Who consumes them, and how does authorization propagate? Have you considered a salted API where each user carries a unique identifier, so the whole grant/revoke/delegate flow goes through a single unified mechanism regardless of what's being accessed?
The SQL sync layer is what actually caught my eye — I've worked on similar problems for specific use cases, and encrypted database sync between peers is a genuinely hard problem. That feels like your real differentiator.
On that note: does the SQL layer reference the file content or file paths? I'm guessing you built both interfaces because they're correlated — the SQL holds structured data that points to the encrypted files. If so, that's worth making explicit, because right now they look like two unrelated features rather than two sides of the same system.
Built Echomindr this week — extracted 1,150 structured decisions, lessons, and signals from 96 podcast episodes (HIBT, Lenny's, Acquired, YC, 20VC) and made them searchable via API and MCP server.
The idea: AI agents give generic startup advice. This gives them access to what founders actually did, with verbatim quotes and timestamp links to the source.
Stack: Deepgram + Claude + SQLite + FastAPI. Total cost under €50.
https://github.com/echomindr/echomindr
The idea: AI agents give generic startup advice. This gives them access to what founders actually did, with verbatim quotes and timestamp links to the source.
Stack: Deepgram + Claude + SQLite + FastAPI. Total cost under €50.
https://github.com/echomindr/echomindr
I’m currently working on Matricsy, a platform for teams that provides a framework to map team competencies, identify skill gaps, and support better development and decision making: https://matricsy.com/skills-matrix
gave a try:got lost :)
Working on a startup that aims to make decarbonisation profitable,
and speed up the clean energy transition based on the RRETS idea:
https://www.why5.uk
The explainer video is here:
https://www.why5.uk/services
I would appreciate any feedback. Thank you!
https://www.why5.uk
The explainer video is here:
https://www.why5.uk/services
I would appreciate any feedback. Thank you!
Prompt injection detection library in Go, zero regex.
Most injection evasion works by making text look different to a scanner than to the LLM. Homoglyphs, leet speak, zero-width characters, base64 smuggling, ROT13, Unicode confusables — the LLM reads through all of it, but pattern matchers don't.
The project is two curated layers, not code:
Layer 1 — what attackers say. ~35 canonical intent phrases across 8 categories (override, extraction, jailbreak, delimiter, semantic worm, agent proxy, rendering...), multilingual, normalized.
Layer 2 — how they hide it. Curated tables of Unicode confusables, leet speak mappings, LLM-specific delimiters (<|system|>, [INST], <<SYS>>...), dangerous markup patterns. Each table is a maintained dataset that feeds a normalisation stage.
The engine itself is deliberately simple — a 10-stage normalisation pipeline that reduces evasion to canonical form, then strings.Contains + Levenshtein. Think ClamAV: the scan loop is trivial, the definitions are the product.
Long term I'd like both layers to become community-maintained — one curated corpus of injection intents and one of evasion techniques, consumable by any scanner regardless of language or engine.
Everything ships as go:embed JSON, hot-reloadable without rebuild. No regex (no ReDoS), no API calls, no ML in the loop. Single dependency (golang.org/x/text). Scans both inputs and LLM outputs.
result := injection.Scan(text, injection.DefaultIntents()) if result.Risk == "high" { ... }
https://github.com/hazyhaar/pkg/tree/main/injection
Most injection evasion works by making text look different to a scanner than to the LLM. Homoglyphs, leet speak, zero-width characters, base64 smuggling, ROT13, Unicode confusables — the LLM reads through all of it, but pattern matchers don't.
The project is two curated layers, not code:
Layer 1 — what attackers say. ~35 canonical intent phrases across 8 categories (override, extraction, jailbreak, delimiter, semantic worm, agent proxy, rendering...), multilingual, normalized.
Layer 2 — how they hide it. Curated tables of Unicode confusables, leet speak mappings, LLM-specific delimiters (<|system|>, [INST], <<SYS>>...), dangerous markup patterns. Each table is a maintained dataset that feeds a normalisation stage.
The engine itself is deliberately simple — a 10-stage normalisation pipeline that reduces evasion to canonical form, then strings.Contains + Levenshtein. Think ClamAV: the scan loop is trivial, the definitions are the product.
Long term I'd like both layers to become community-maintained — one curated corpus of injection intents and one of evasion techniques, consumable by any scanner regardless of language or engine.
Everything ships as go:embed JSON, hot-reloadable without rebuild. No regex (no ReDoS), no API calls, no ML in the loop. Single dependency (golang.org/x/text). Scans both inputs and LLM outputs.
result := injection.Scan(text, injection.DefaultIntents()) if result.Risk == "high" { ... }
https://github.com/hazyhaar/pkg/tree/main/injection
You're not david927 ;).
I've been scanning all 14,704 skills in the registry and running AI deep audits on ~3,800 so far. The headline finding: surface heuristics (pattern matching, dependency checks, metadata) flag about 6.6% as malicious. AI deep audit of the same skills finds 16.4%. Surface scanning misses roughly 60% of the actual risk.
The reason is that these skills aren't traditional packages — they're markdown instruction files that tell an AI agent what to do, with full shell, file system, and network access. The attacks are in natural language: prompt injection, social engineering targeting the AI itself, instructions to generate and execute code at runtime. There's no malicious code to detect because the payload doesn't exist until the AI writes it during a conversation.
Some of the attack patterns I've documented: one actor published 30 skills under the name "x-trends" across multiple accounts (28/30 confirmed malicious). Another cluster impersonates ClawHub's own CLI with base64 curl|bash payloads. One skill has a "Talking to Your Human" section with a pre-written pitch for the AI to ask the user's permission to mine Monero.
The most counterintuitive case: lekt9/foundry contains zero malicious code. It instructs your AI agent to generate and execute code as part of its normal workflow. Static analysis finds nothing because the dangerous code doesn't exist until the AI writes it during a live conversation. This attack class requires AI to detect AI.
Free to check any skill. All AI audit reports are public.