A few months ago I had a moment of uncomfortable clarity.
I was using Cursor to work on a project that had database credentials in an .env file. The AI had full access to the codebase. I wasn't thinking about it - I was just coding. And then it hit me: all of this is going to their servers right now. The keys, the internal URLs, everything.
I stopped and thought about how long I'd been doing this without a second thought. And then I asked a few colleagues. Same story. Nobody was really thinking about it. We all just... trusted that it was fine.
It probably is fine, most of the time. But "probably fine" is not a compliance posture. And as AI coding tools get deeper access to our codebases, the surface area for accidental leaks keeps growing.
That's why I built Velar — a local proxy that sits between your app and AI providers, detects sensitive data, and masks it before it ever leaves your machine.
The problem is getting worse, not better
Copilot, Cursor - these tools are genuinely useful. But they work by sending your code (and often a lot of surrounding context) to external APIs. Most developers don't think carefully about what's in that context.
Common things that end up in AI requests without people realizing:
- AWS/GCP/Azure credentials accidentally committed or present in env files
- Database connection strings
- Internal API endpoints and tokens
- Customer emails or names in logs you're debugging
- JWTs from test sessions
None of this is malicious. It's just how development works. But "it's not malicious" doesn't mean it's not a problem when you're dealing with regulated data or working in an enterprise environment.
How Velar works
Velar runs locally as an HTTP/HTTPS proxy with MITM support. You configure it to intercept traffic to specific domains (like api.openai.com), and it inspects outbound payloads before forwarding them.
Your app → Velar → AI provider
When it detects something sensitive, it replaces it with a deterministic placeholder:
alice@company.com → [EMAIL_1]
AKIAIOSFODNN7EXAMPLE → [AWS_KEY_1]
Then, when the response comes back, Velar restores the original values — so your app keeps working exactly as expected.
Everything happens locally. No external services, no logging to the cloud, no callbacks home. You can read the full source and verify this yourself — it's MIT-licensed Go code.
What it detects
Current detection is regex-based and covers:
- Emails, phone numbers, names
- AWS, GCP, Azure credentials
- Private keys
- Database URLs
- JWTs
- High-entropy strings (potential secrets)
There's also optional ONNX NER support via a locally-downloaded model (dslim/bert-base-NER) for more accurate PII detection. Fair warning: this part is still rough and doesn't always behave as expected — it's something I'm actively working on.
"But wait — you're asking me to install a MITM proxy?"
Yes. This is the obvious concern, and it's a fair one.
Here's the honest answer: Velar only intercepts traffic to domains you explicitly configure. By default that's api.openai.com. It doesn't touch your banking traffic, your Slack messages, or anything else.
More importantly — you can verify this. The network code is small and straightforward. There are no background processes phoning home. No analytics. No telemetry. Just a local proxy doing exactly what it says.
I understand if that's still not enough for some people, and that's fine. But for developers who are already sending sensitive data to AI providers without any filtering layer — Velar represents a net improvement in privacy, not a reduction.
Quick start
git clone https://github.com/ubcent/velar.git
cd velar
make build
./velar ca init
./velar start
./velar proxy on
That's it. You'll start seeing local notifications when Velar masks something in your AI traffic.
Where it's going
Honestly — I'm not entirely sure yet. This is v0.0.3, explicitly experimental, and I'm still figuring out the right direction. Some things I'm thinking about: stricter blocking mode, a local dashboard, better cross-platform support (notifications are currently macOS-only, though the proxy itself runs anywhere). But nothing is set in stone.
What I do know is that I'd rather ship something real and iterate based on feedback than plan in a vacuum.
If this sounds useful, check it out on GitHub. Issues, PRs, and honest feedback are all welcome.
And if you've had your own "oh no, what have I been sending to ChatGPT/Claude" moment — I'd love to hear about it in the comments.
Top comments (0)