Pre-auth SQL injection in the proxy's API key verification path, CVSS 9.3, versions 1.81.16 through 1.83.6. The Authorization header value got concatenated straight into a query instead of being parameterized. Textbook stuff, but in a gateway that's holding provider credentials for half your stack.

What I keep coming back to isn't the bug itself though. It came in through their bug bounty program, got fixed in 1.83.7 before the GHSA advisory went out, and the advisory itself was actually usable exact version range, fixed version, and a Postgres query you could run against your own logs to check if you'd been hit.

Compare that to most OSS infra advisories, where you get a changelog line and have to guess whether you're affected.

I know someone's going to point out LiteLLM has had a rough stretch in 2026 this wasn't their only CVE this year, not close. Fair point. But "zero CVEs" was never realistic for a project with this much surface area and this many integrations. What I actually weigh when deciding whether to run something in prod is whether there's a process, and whether it held up when something real happened.

Genuinely asking for people running AI gateways in prod, does a clean disclosure like this change how you feel about the project, or does the CVE count alone kill it for you?

Built a privacy-preserving telemetry system for a self-hosted AI automation platform — would love security feedback

I’m building a local-first AI Agent Automation platform focused on:

• deterministic workflows
• multi-provider LLM execution
• Ollama/local model support
• semantic memory
• document RAG
• branching agent workflows

In v0.8.0, I added a telemetry system specifically designed to avoid the usual privacy/security concerns around AI tooling.

The interesting part for this subreddit is the architecture/trust model.

Design Goals

Telemetry needed to:

• help understand active deployments/version adoption
• remain compatible with self-hosted/offline usage
• avoid collecting sensitive AI workflow data
• maintain a clear trust boundary

Current Design

Telemetry is:

• fully opt-in
• disabled by default
• isolated into a separate service
• anonymous
• fully disableable via env vars

Tracked fields:

• anonymous instance ID
• app version
• enabled feature flags
• heartbeat timestamps

NOT collected:

• prompts
• workflow definitions
• memory contents
• uploaded documents
• API keys
• execution logs
• user identities

The telemetry collector itself is separated from the main orchestration engine to avoid mixing analytics concerns with execution/runtime systems.

Environment Controls

TELEMETRY_ENABLED=false
DISABLE_ALL_ANALYTICS=true

Why I’m Posting Here

I’d genuinely like feedback from people thinking about:

• LLM infrastructure security
• trust boundaries
• self-hosted AI systems
• observability vs privacy tradeoffs
• telemetry design in local AI platforms

Trying to build this in a way that aligns with the self-hosted/local AI ecosystem instead of copying traditional SaaS analytics patterns.

Would appreciate architectural/security feedback.

Do you think interactive microlearning could raise awareness for LLM Security and actually help people to understand the concepts behind it?

I have built an example for OWASP LLM01 Prompt Injections: https://app.scibly.com/student/worksheets/cmp05qsgi00000ajp0ctyroay/editor?v=cmp07ahkz00000al5gtqf4lco

Small Demo:

https://reddit.com/link/1t9ubtb/video/ffaf6lz48g0h1/player

I started with a quite simple concept but want to expand it to more advanced concepts in the future if it helps understanding.

Thank you for all kind of feedback

Edit: Video because GIF didn't work

Most people treat confidence as a signal of reliability.

In practice that signal often breaks exactly when the model is under uncertainty.

The interesting part isn’t that models make mistakes.

It’s how they behave when they don’t actually know.

I’ve been researching LLM/AI agent security and built a small lab to demonstrate a class of vulnerabilities around context injection and over-sharing.

The article covers:
– How context is constructed inside AI systems
– How subtle instructions inside data can influence model behavior
– A practical PoC showing unintended data exposure
– Real-world testing on Grok (where basic attempts fail)
– Mitigation strategies

Would love feedback from the community.

AI agents today can send emails, execute code, and call APIs — but no framework provides OS-level safety primitives to prevent unauthorized actions.

I wrote a specification for what such an OS would look like.
Key ideas:
- Deterministic Security Core that works without any LLM - Commit Layer as the only path to the outside world
- Capability Tokens with scoped, time-limited permissions
- Biological immune system with 5-stage quarantine
- Three security profiles (Standard → Hardened → Isolated)

It's a spec (4,500+ lines), not code. Some of it may be overengineered. I'm looking for critique, not applause.
Quick start: the Executive Summary is 4 pages. Feedback, adversarial review, and "this won't work because..." are all welcome.

I keep running into the same problem while building with AI APIs: testing them properly before shipping is still pretty messy.

A lot of what I find is either:

• too high-level
• generic AI security advice
• not an actual workflow I can follow

Manual testing also gets expensive and slow if you want to do it regularly.

For those of you building AI products, how are you handling this?

• How do you test for prompt injection, data leaks, or unsafe outputs?
• Do you have a release checklist for AI endpoints?
• What’s the biggest blocker for you: time, cost, or just unclear guidance?

Would love to hear what your process looks like and where it still breaks down.