Designing ichat Against the OWASP Top 10: Privacy Principles Behind an AI Reply Generator

ViVi Li — Wed, 12 Aug 2026 16:38:34 +0000

Most AI writing tools follow the same pattern: open a chat window, paste your message, describe what you want, wait, regenerate if the tone is off. I wanted ichat to skip all of that — select a message, get two ready replies (one casual, one professional), done. But the more interesting problem turned out to be underneath the UI: how do you build something that reads people's private messages and still make it trustworthy?

While designing ichat (by Veyon Solutions), I used the OWASP Top 10 as a mental checklist — not because we're marketing a "security product," but because a tool that touches personal conversations has to earn trust by design, not by policy document.

A01: Broken Access Control → design for "nothing to break into"

The simplest way to avoid access-control bugs is to minimize what there is to control access to. ichat's core flow doesn't persist your message content at all, so there's no long-lived store of other people's data that a bug could ever expose across accounts.

A02: Cryptographic Failures → the best-protected data is data you don't keep

Instead of leaning entirely on encryption-at-rest to protect stored messages, ichat's philosophy is to process a message for the single request it's needed for, then discard it. Less retained data means less that depends on any one cryptographic control holding up forever.

A03: Injection → treat every message as hostile input, always

Since the entire product is "take arbitrary text from a stranger's inbox," every message is treated as untrusted by default — never something to be trusted just because it "looks like" a normal reply.

A04: Insecure Design → the retention policy is the security control

The single biggest architectural decision was choosing not to build a database of user messages in the first place. The one deliberate exception is content a user explicitly reports, which is kept for 90 days purely so it can be reviewed — everything else is designed to not exist after the request completes.

A05: Security Misconfiguration → permissions should match the feature, not the platform default

The Chrome extension only asks for what it needs to add a right-click menu item — not broad access to read every page you visit. If a permission isn't needed for the feature in front of you, it isn't requested.

A09: Security Logging and Monitoring → you can't leak what you didn't log

Because message content isn't stored, it also isn't sitting in application logs waiting to be a future liability — a nice side effect of the "discard by default" philosophy.

Closing thought

None of this makes ichat a security product — it's a small utility for drafting replies. But treating the OWASP Top 10 as a design lens from day one, rather than a checklist bolted on later, is what shaped decisions like never storing messages, keeping the Chrome extension's permissions minimal, and making account deletion instant and self-service from inside the app.

ichat is live on Android and as a Chrome extension, with iOS in development: https://www.veyon.solutions/ichat — built by Veyon Solutions. Feedback on the approach is very welcome.

Red-teaming your AI agent like an attacker would: introducing Argus

ViVi Li — Wed, 12 Aug 2026 16:35:41 +0000

Most LLM eval frameworks score a single prompt and a single response. That's not really what ships to production anymore. What ships is an agent: a system that plans, calls tools, reads documents, opens browsers, and holds state across many turns. The place that system actually breaks is adversarial robustness, not benchmark accuracy — prompt injection through a retrieved document, tool-call confusion, a jailbreak that only lands after three turns of setup.

I built Argus to test agents the way an attacker actually would: as a black box, over the wire, against a live endpoint, with no source access. Apache 2.0, open for anyone to use or extend.

What it does

Argus ships with a library of 167 adversarial probes: hand-authored coverage of the OWASP LLM Top 10, scenarios pulled from public model system cards (crescendo, many-shot jailbreak, sleeper-agent triggers), browser-agent-specific attacks, and wrappers around NVIDIA's garak catalogue. On top of the static probes it runs algorithmic iterative attacks — TAP, PAIR, and black-box GCG — that adapt the prompt based on the target's responses.

It can talk to five kinds of targets out of the box: OpenAI-compatible APIs, Anthropic's native API, arbitrary HTTP endpoints via a templated adapter, gRPC services (with reflection-based auto-discovery), and full browser-driven agents through Playwright.

Findings are judged by an LLM (Haiku by default, escalating to Sonnet on high-severity hits) against per-probe rubrics, then written out as SARIF 2.1.0, JUnit XML, or HTML — so a scan can gate a CI pipeline through GitHub Code Scanning instead of just producing a report nobody reads.

Try it in five minutes, no API keys

The repo ships a deterministic local demo: a deliberately vulnerable FastAPI chatbot whose system prompt hides a few fake secrets, plus a runner that fires a curated probe set at it.

git clone https://github.com/gy15901580825/Argus
cd Argus
pip install fastapi httpx pydantic uvicorn slowapi pyyaml
PYTHONPATH=. python3 demo/run_local_demo.py

You'll see individual probes pass or leak in real time, then a summary attack-success rate. There's also a guardrail mode that puts a prompt-injection classifier in front of the same target, so you can compare the before-and-after numbers yourself.

Real numbers, not just a demo

RESULTS.md in the repo walks through a measured before/after run: adding an input-side guardrail (ProtectAI's deberta-v3-base-prompt-injection-v2, wrapped as "PromptGuard") drops the attack-success rate on the demo target from 22.9% to 2.9%, at roughly 275ms p50 latency overhead — and it documents the one bypass and twelve false positives we found, instead of hiding them.

Pointing it at your own agent

Targets are just a YAML file:

kind: openai_compat
base_url: "https://api.your-agent.example.com/v1"
api_key_env: AGENT_API_KEY
model: "your-agent-prod-v3"

Then run it with the CLI:

pip install argus-probe
argus-probe run --target my_target.yaml --probes owasp_,syscard_ --judge anthropic --report sarif > argus.sarif

For CI, there's a bundled argus-probe-action@v1 GitHub Action with a --block-on-critical flag to fail the build on high-severity findings.

Where it's at

Argus is pre-1.0. The CLI, REST API, probe library, judge harness, and report formats are stable; the orchestrator's internal dispatch contract may still shift. The web UI and SaaS surface are actively being built.

If you're doing any kind of AI security or red-teaming work, I'd genuinely like your feedback — probes that are missing, target adapters you need, report formats that don't fit your pipeline. Issues and PRs are welcome; the contributing guide has the repo layout and probe schema.

Repo: https://github.com/gy15901580825/Argus

DEV Community: ViVi Li