DEV Community: oleg-vdv

"Your company banned ChatGPT. There's a third option."

oleg-vdv — Tue, 01 Sep 2026 16:29:23 +0000

Most companies handle the "employees are pasting customer data into ChatGPT" problem in one of two ways.

Option one: block it. Firewall rules, an acceptable-use policy, a stern email. What actually happens is that people use their phones, personal laptops, and a browser profile you don't manage. You haven't stopped the leak; you've stopped seeing it.

Option two: allow it and hope. Training, a wiki page about "don't paste PII", and an incident waiting to be discovered by someone else.

There's a third option that I don't think gets built often enough: let the request through, but strip the sensitive parts on the way out and put them back on the way in. The model never sees the customer's name. The employee never notices anything happened.

That's what I built AI-Gate for.

The idea in one example

An internal app sends this prompt:

Customer Yerzhan Nursultanuly, ID 900715300005, disputes a charge of 145,000 KZT...

What actually leaves your network:

Customer [PERSON_1], ID [NATIONAL_ID_1], disputes a charge of [AMOUNT_1]...

The model answers about [PERSON_1]. The gateway substitutes the real values back before the response reaches the application. From the app's perspective it just talked to OpenAI normally. From OpenAI's perspective, it never received a single piece of personal data.

The mapping between [PERSON_1] and the real name lives in memory only, encrypted, with a TTL and guaranteed destruction once the response is detokenized. It is never written to disk and never appears in the audit log — the log records types and counts, not values.

Integrating it is one line

For any application already using an OpenAI-compatible client, you change the base URL and nothing else:

from openai import OpenAI

client = OpenAI(
    base_url="http://aigate.internal:8080/v1",
    api_key="<channel key>",
)
resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Customer Yerzhan Nursultanuly, ID 900715300005..."}],
)

A detail that matters more than it looks: the real provider API key lives only on the gateway. Applications get a channel key instead. Revoking one team's access stops being a redeployment and starts being a config change — and a leaked application key no longer means a leaked OpenAI key.

Three channels, because the leak isn't only in your code

An egress proxy covers your own applications, RAG pipelines and n8n workflows. It does not cover the two places people actually leak data:

The browser. A Chrome extension intercepts text before it's sent to chat.openai.com, claude.ai or gemini.google.com, masks it through the gateway, and substitutes values back into the assistant's reply as it renders. Deployable via GPO/MDM, so it's not opt-in.

The clipboard. A workstation agent catches sensitive data on its way into local LLM apps — Cursor, Claude Desktop — and detokenizes copied responses. This is the gap neither the browser nor the network perimeter can see, and it's the one that grows every month as AI moves into desktop tools.

Design decisions worth arguing about

Fail-closed, always. Any error in detection or parsing blocks the request instead of passing it through. This will occasionally annoy someone. The alternative is that a parser bug becomes a data breach, and the asymmetry there isn't close: a false block costs a retry, a false pass costs a regulatory fine and a disclosure letter.

Zero dependencies. The core is pure Python 3.11+ standard library. No PyPI at install time, which means it drops into air-gapped environments — exactly the kind of environment where this problem is most acute and where "just pip install" is not an available move. It also means the supply-chain attack surface of a tool that sees all your prompts is approximately zero.

Tamper-evident audit. The log is append-only JSONL with a SHA-256 hash chain. You can't quietly delete the record of a blocked request; verification detects it. For a compliance tool this is the difference between "we have logs" and "we have evidence".

Sensitive prompts can be routed to a local model. The provider registry supports OpenAI-compatible endpoints including vLLM, Ollama and LM Studio, plus the Anthropic Messages API. A policy rule can say: anything containing sensitive data goes to the local model only, never to a vendor. Masking and routing solve different halves of the same problem.

Semantic detection on top of pattern detection. Regexes catch IDs, account numbers and names. They do not catch "our Q3 acquisition target is a logistics company in Almaty with a 40% margin" — a leak with no PII in it at all. An LLM-judge runs over the already anonymized text and flags meaning-level leaks, in flag or block mode, fail-closed if the judge is unreachable.

Try it

cp .env.example .env      # set AIGATE_PROVIDER_API_KEY
python -m gateway.main    # gateway on :8080

or on-prem in a container:

docker compose up -d

The control plane console is at http://localhost:8080/admin — policies, RBAC, dashboards and compliance reports.

Where this is honest about its limits

Detection is imperfect and always will be. Names in particular are the hard case in every language, and a masking gateway that claims 100% recall is lying. Fail-closed helps, the local-model routing rule helps more, and semantic detection catches a class regexes structurally cannot — but the right mental model is defense in depth, not a solved problem.

It's also worth saying plainly: this reduces exposure, it doesn't create legal compliance by itself. What it gives you is the technical control and the evidence trail that a compliance program needs underneath it.

Repo: https://github.com/oleg-vdv/AI-Gateway

I'd be interested to hear how others are handling this. Has your organization landed on block, allow, or something in between — and if you've deployed a masking layer, what broke first?

---

From Infrastructure to Open Source: Lessons Learned Building 4 Security & Automation Tools

oleg-vdv — Fri, 24 Jul 2026 00:47:58 +0000

Coming from a strong sysadmin and infrastructure background, I spent years managing servers, networks, and keeping systems alive. Over time, I realized a fundamental truth: the most dangerous system risks are often the ones you don't even have visible inventory for.

That mindset naturally led me into the world of open source. I started building tools to solve real-world problems around API governance, edge safety, data integrity, and automation.

Here is what I’ve been building in public, what each project taught me, and why these areas matter today:

1. Governing LLM & API Traffic: AI-Gateway

As AI applications move to production, controlling model access, enforcing limits, and monitoring traffic becomes critical.

The Project: AI-Gateway — A lightweight proxy layer designed to secure, route, and manage API requests and policies for AI services.
Key Lesson: Security in the AI era isn't just about firewall ports; it's about context-aware policy management and dynamic traffic control.

2. Safety at the Edge: AffectGuard-HRI

Moving machine learning onto edge devices and microcontrollers opens up huge potential for robotics, but it introduces strict real-time safety constraints.

The Project: AffectGuard-HRI — An open-source framework tailored for human-robot interaction, focusing on real-time safety, intent tracking, and affective monitoring.
Key Lesson: Edge AI demands extreme efficiency. You can't rely on cloud latency when dealing with physical robotic hardware—safety loops must run reliably at the hardware level.

3. Verifiable Data & Audit Trails: ProofByte

In modern SecOps, logging isn't enough—you need verifiable proof of data integrity for compliance and auditing.

The Project: ProofByte — A lightweight tool aimed at data validation, cryptographic verification, and maintaining tamper-evident audit trails.
Key Lesson: Building trust in distributed workflows requires cryptographic validation at every step of the pipeline.

4. Modern Workflow Governance: AutoGov

Processes in enterprise environments often break down due to manual bottlenecks and fragmented oversight.

The Project: AutoGov — An automation and workflow governance engine built to streamline standard operating procedures and administrative checks.
Key Lesson: Good automation doesn't replace governance—it bakes governance into the infrastructure so compliance happens by default.

What’s Next?

Transitioning from maintaining infrastructure to building developer tools in public has been an incredible learning experience.

I’d love to hear from the community: What is your biggest pain point right now when securing edge devices or managing AI API endpoints?

Feel free to check out the repos, leave stars if you find them useful, or open issues/PRs! Let’s connect! 🚀

The post-quantum deadlines are closer than your roadmap thinks — so I built a CBOM scanner

oleg-vdv — Fri, 17 Jul 2026 00:55:53 +0000

Three regulatory clocks are already ticking:

US: EO 14412 / CNSA 2.0 requires post-quantum cryptography for new national-security acquisitions from 2027 — and explicitly names the "cryptographic bill of materials" (CBOM).
UK: NCSC wants full cryptographic discovery and a migration plan by 2028.
EU: member states start transitioning from the end of 2026.

Yet when an auditor asks the first, most basic question — "where exactly does your codebase use RSA?" — almost nobody can answer. Not because it's hard conceptually, but because nobody ever had a reason to keep an inventory of their cryptography. Now there's a reason.

What "harvest now, decrypt later" actually means

Even if a cryptographically relevant quantum computer is a decade away, traffic recorded today can be decrypted then. If your secrets have a shelf life of more than a few years (medical records, financial data, government contracts), classical key exchange is already a liability. That's the logic behind the deadlines — they don't wait for the quantum computer to exist.

One command, three artifacts

I wanted the discovery step to cost one command instead of one consulting engagement:

npx @proofbyte/pqc-radar scan . --cbom cbom.json --report report.md --sarif findings.sarif

This walks the repository and flags quantum-vulnerable cryptography — RSA, ECC/ECDH, DH, DSA, Curve25519, legacy hashes, weak TLS configs — across Java, Python, JavaScript/TypeScript, Go, C#, Rust, Ruby, PHP, C/C++ and nginx/Apache configs. Out come three artifacts:

cbom.json — a CycloneDX 1.6 CBOM: the machine-readable inventory the mandates ask for;
report.md — a human-readable report: every finding with file:line and its ML-KEM (FIPS 203) / ML-DSA (FIPS 204) migration target;
findings.sarif — SARIF 2.1.0, so findings land straight in GitHub code scanning.

It's fast enough to live in CI: hashicorp/vault (4,827 files) scans in about 9 seconds; a weekly corpus workflow re-scans five well-known OSS projects to catch regressions.

Checking live endpoints, not just code

Code is half the story — the other half is what your servers actually negotiate:

npx @proofbyte/pqc-radar scan-tls your-api.example.com github.com

One TLS handshake per host (no payload sent) reports the protocol, cipher, key-exchange group and certificate key — and whether the endpoint already speaks hybrid post-quantum key exchange (X25519+ML-KEM-768). One honesty detail I'm proud of: when the local TLS stack can't name the negotiated group (older OpenSSL builds can't name hybrid groups), the result is reported as inconclusive, not as a finding. Unknown ≠ vulnerable.

What the v0 honestly can't do

Detection is line-pattern based. That makes it fast, broad and dependency-free, but:

it will miss dynamically constructed crypto calls;
unusual code can false-positive;
absence of findings is not proof of absence — the report says so explicitly.

A deep AST engine (integrating PQCA CBOMkit, which covers Java and Python) is the next milestone. There's also a fun war story: the very first regression test caught the scanner's regexes matching their own source code — the fix was masking pattern literals with character-class tricks (RSA_generate_ke[y]), and a permanent guard test asserting the repo only ever flags its own fixtures.

Security posture

This is a tool you're supposed to run on code you can't share, so: fully offline (the scan command makes zero network calls), zero runtime dependencies, read-only, symlinks not followed. scan-tls is the single network feature and touches only endpoints you name. It's MIT-licensed — read the source rather than trusting this paragraph.

Try it

npx @proofbyte/pqc-radar scan .

GitHub: https://github.com/oleg-vdv/proofbyte (issues and PRs welcome — especially new language patterns with fixtures)
CI one-liner: uses: oleg-vdv/proofbyte@v1

I'd genuinely like to hear from anyone whose org has already been asked for a CBOM — by whom, and what format they accepted.