I built an open-source PII masking layer for LLM APIs — early traction, looking for design partners
I kept running into the same wall while talking to developers at healthtech and fintech companies: they wanted to use LLMs to automate workflows, but their data had names, emails, Aadhaar numbers, PAN cards, SSNs in it. Sending that to OpenAI or Anthropic felt wrong — legally and ethically.
Most teams were either skipping LLMs entirely or hand-rolling their own scrubbers. Neither felt like the right answer.
So I built Armos.
It wraps the OpenAI and Anthropic Python SDKs. Before your prompt goes out, PII is detected locally (nothing leaves your machine during detection), replaced with reversible tokens. The LLM sees tokens, responds with tokens, Armos swaps real values back. Your app gets the original text. The model never does.
The entire integration is one line:
client = ArmosOpenAI(OpenAI())
Where I am:
- Just launched v1.2.1 on PyPI
- Detects 10 entity types including India-specific ones (Aadhaar, PAN)
- Got a warm lead from a tax automation company for a design partnership
- HN post going up tomorrow
What I'm looking for:
- Developers building on sensitive data (health, finance, legal, HR) who
want to trial this early - Feedback on what's missing — entity types, framework integrations,
async/streaming support - Honest criticism of the approach
Still early and rough around the edges. Would love to connect with anyone
hitting this problem.
GitHub: https://github.com/armos-ai/armos-python
Docs: https://armos.dev
pip install armos
This is a strong wedge because you are not selling “LLM security” in a vague way. You are solving a specific blocker that sensitive-data teams already feel: they want LLM automation, but they cannot casually send names, IDs, tax data, health data, or legal records into external models.
The local detection plus reversible token layer is the right trust angle. I would make that the center of the positioning: Armos is not just a wrapper, it is the privacy boundary between regulated workflows and LLM APIs.
One thing I’d pressure-test before the HN post and design partner conversations is the name. Armos is decent, but for healthtech, fintech, legal, and HR developers, the brand has to immediately feel secure, technical, and serious. This is infrastructure sitting between sensitive data and foundation models, so the name carries trust before the docs even do.
Vroth .com would fit that layer better if you want it to feel like hard security infrastructure for LLM workflows, not just an open-source SDK. The product direction is strong enough that naming is not cosmetic here. It affects whether security-conscious developers read it as a real privacy layer or another early wrapper.
Really appreciate this — the "privacy boundary between regulated workflows and LLM APIs" framing is sharper than how I've been positioning it. Stealing that.
On the name — I hear you, and I don't disagree that names carry
trust in security infra. But I'd rather not sweat it at this stage.
No paid users, no enterprise contracts, nothing that makes a rebrand painful. If the
product earns trust with the right teams, Armos won't have been the thing that stopped them. I'll revisit naming seriously before any real scaling push.
What I'm more focused on right now is getting it in front of sensitive-data teams and letting them pressure-test the actual trust layer — the local detection, the reversible tokens, the zero PII to the model. That's where I want the feedback loop first.
Are you building in any of these spaces? Would love to hear where you'd see this fitting or breaking.
That makes sense. If there are no paid users or enterprise contracts yet, getting the trust layer pressure-tested matters more than renaming today.
I’m not building directly in healthtech/fintech/legal, but the strongest fit I see is sensitive-data workflows where teams already want LLM automation but cannot justify sending raw PII into external models.
Examples:
healthtech admin/support workflows
legal intake and contract review
fintech support/compliance notes
HR records and employee data
insurance claims
B2B SaaS tools handling customer records
Where I think it breaks is if Armos is framed as an SDK feature instead of a privacy boundary.
The sharper first-user angle is probably:
“Use LLMs in sensitive workflows without sending raw PII to the model.”
That is much easier for sensitive-data teams to understand than a generic “LLM security” pitch.
If useful, I can put together a quick GTM/outreach pack around this wedge: target profiles, 3 cold emails, 3 LinkedIn DMs, 3 follow-ups, and the cleanest positioning angle for getting design partners.
I’m doing a few quick ones at $49 to move fast. This one is a good fit because the pain is specific and the buyer profile is clear.
LinkedIn: https://www.linkedin.com/in/aryan-y-0163b0278/
Thanks for this — genuinely useful framing.
On the GTM pack — I appreciate the offer, but right now I'm not focused on outreach. The goal at this stage is developer adoption and finding 3–5 design partners who are actually hitting this problem, so I can let the roadmap be shaped by real use cases before I start selling anything. Happy to revisit when that changes.
If you're building something where this friction comes up, I'd love to hear what it looks like from the inside.