Anonmyz

• 

• 

• 

Aşağıdaki metni kod bloğunun içinden kopyalayıp doğrudan Project Story alanına yapıştır:

## Inspiration

AI coding agents are most useful when they can understand a developer’s real working context: source files, configuration, terminal output, environment variables, and project structure. Unfortunately, that context may also contain API keys, access tokens, passwords, private file paths, and other sensitive information.

The usual response is to either trust every cloud request or prohibit AI coding tools entirely. I wanted a practical third option: a local privacy boundary that allows developers and organizations to use cloud AI while keeping sensitive values on their own machine.

That idea became **Anonmyz**: a local-first data loss prevention gateway built specifically for AI-assisted development.

## What it does

Anonmyz runs locally between an AI client and an OpenAI-compatible upstream provider.

Before a request leaves the machine, Anonmyz:

1. Inspects the outgoing structured payload.
2. Detects sensitive values such as API keys, tokens, passwords, private-key blocks, and local file paths.
3. Stores the original values in a thread-safe local vault.
4. Replaces them with unique placeholders.
5. Sends only the sanitized request upstream.

When the model response returns, Anonmyz restores the placeholders locally before delivering the response to the client. The same protection works with streamed Server-Sent Events responses, even when placeholder text is split across network chunks.

The result is a mostly transparent workflow in which the AI can continue reasoning about consistent identifiers without receiving the original sensitive values.

Anonmyz also includes:

- An OpenAI-compatible local proxy
- A protected **Codex Safe Session**
- Local privacy audit records
- A deterministic offline security demonstration
- Fail-closed validation for unsafe or malformed upstream responses

The demonstration requires no API keys, real credentials, or external services.

## How I built it

Anonmyz is implemented in **Go** using only the Go standard library. It runs as a single portable binary without requiring Python, Node.js, Docker, a database, or a hosted control plane.

The main request flow is:

```text
AI client
   |
   v
Local Anonmyz gateway
   |
   +-- Detect sensitive values
   +-- Store originals in the local vault
   +-- Insert unique placeholders
   |
   v
Sanitized upstream request
   |
   v
Model response
   |
   +-- Validate the response
   +-- Restore placeholders locally
   |
   v
AI client

The system uses structured request processing instead of applying blind text replacement to an entire HTTP message. Sensitive-value mappings are protected for concurrent access, and placeholders are unique so multiple requests and values can be handled safely.

For streaming responses, I built a boundary-aware buffering mechanism. It retains enough trailing data to recognize placeholders that may be divided between two or more chunks while continuing to forward normal response data incrementally.

I also built a deterministic demonstration using clearly synthetic secrets. It demonstrates detection, masking, verification that the original values are absent from the upstream request, and local restoration—without transmitting any data to an external service.

During OpenAI Build Week, I used Codex with GPT-5.6 as an engineering collaborator for threat modeling, implementation review, adversarial test design, documentation, and security hardening. Codex helped identify edge cases, but every change was reviewed and verified through automated tests, static analysis, and local builds.

Challenges I faced

Preserving streaming behavior

A placeholder may be split at any byte boundary in a streamed response. Processing each chunk independently can therefore miss a match or expose an unresolved placeholder to the client.

Solving this required a careful buffering algorithm that preserves streaming while recognizing tokens across chunk boundaries.

Failing closed safely

A privacy gateway should not silently forward data when it cannot validate an upstream response. I added strict response checks and fail-closed behavior while preserving useful error information for the developer.

Avoiding accidental data leakage

Logs, audit records, error messages, and demonstrations can become secondary leakage channels. I designed the audit trail around privacy-safe metadata and made the public demonstration use only synthetic values.

Remaining compatible with existing tools

The gateway needed to preserve request structure, streaming semantics, and OpenAI-compatible behavior closely enough that existing clients could use it without extensive modification.

Testing security properties

A successful HTTP request is not sufficient evidence for a privacy tool. The tests needed to verify properties such as:

• Original secrets are absent from sanitized upstream payloads.
• Placeholders remain unique.
• Streamed placeholders are restored across arbitrary chunk boundaries.
• Malformed or unsafe responses are rejected.
• Concurrent access does not corrupt local mappings.

What I learned

I learned that building privacy infrastructure is less about a single detection regular expression and more about securing the complete data lifecycle.

Request transformation, streaming boundaries, concurrency, logs, error handling, restoration, and test evidence all affect whether the privacy guarantee is meaningful.

I also learned the value of deterministic security demonstrations: judges and developers should be able to verify the core behavior without trusting a hosted service or providing real credentials.

Working with Codex reinforced the importance of treating AI-generated code as a proposal rather than proof. Threat-focused review and reproducible tests were essential for turning suggestions into defensible security behavior.

Accomplishments that I am proud of

• Built a working local-first privacy gateway as a single Go binary
• Used no third-party runtime libraries or hosted databases
• Supported OpenAI-compatible clients and streamed responses
• Added a protected Codex workflow
• Implemented local masking and restoration without exposing original values upstream
• Added fail-closed response validation
• Created a deterministic demonstration requiring no credentials or external services
• Added automated tests for masking, streaming, concurrency, and security boundaries
• Verified the project with go test, go vet, and clean builds

What's next for Anonmyz

The next steps are to expand client integrations, improve policy configuration, add organization-level administrative controls, and conduct an independent security review.

I also want to add stronger secret-detection strategies, privacy-preserving observability, signed release artifacts, and deployment options for enterprise and air-gapped environments.

The long-term goal is simple: organizations should not have to choose between developer productivity and control over sensitive data.

Built With

• api
• artificial
• codex
• cybersecurity
• data
• developer
• events
• go
• gpt-5.6
• http
• intelligence
• local-first
• loss
• openai
• prevention
• privacy
• proxy
• regular
• server-sent
• streaming
• tools