New stories

Hi HN!

I kept rewriting the same foundation for every SaaS I built — auth, payments, email, logging, environment setup — so I packaged it all up as SaaS Forge.

It’s a modular boilerplate generator for SaaS apps with AI in mind. You can use it two ways:

* 1. Open-source CLI (free, unlimited)*

  npx saas-forge my-app

This launches a local scaffold where you choose modules via a form and download a ready-to-deploy repo.

* 2. Web Scaffold (20 credits)*

Live at: boilerplate.bayesian-labs.com

A guided UI that helps you select features, configure env vars (e.g. auth keys, DB URLs, etc.), and deploy correctly.

What you get out of the box: - Auth: Better Auth — email/password + GitHub, Google, LinkedIn OAuth + email verification + password reset - Payments: Dodo Payments/ Stripe — webhooks, credit system - Database: PostgreSQL(AWS RDS/Neon/Supabase/Railway) + Prisma ORM - Storage: Vercel Blob / Cloudflare R2 - Email: Resend / SMTP (Coming Soon) - Analytics: Google Analytics / Vercel Analytics - Security: Upstash Rate Limit - API: tRPC end-to-end type safety - CMS: Notion as a headless CMS for landing pages, docs, and legal pages - Caching: Redis via Upstash - Logging: Winston + Logtail + BetterStack (with guided env setup in the web scaffold) - UI: shadcn ui + aceternity ui+ Tailwind CSS 4 + Framer Motion + 50+ components - Monorepo: Turborepo + pnpm workspaces

Idea is simple: skip boilerplate and ship what’s actually unique in your product.

The CLI is free and open-source — fork it, extend it, or just use it raw. The web scaffold is for folks who want error-proof setup with minimal config.

Live demo: https://boilerplate.bayesian-labs.com GitHub: https://github.com/anoopkarnik/saas-forge Docs: https://boilerplate.bayesian-labs.com/landing/doc Demo Video: https://www.youtube.com/watch?v=0zpQTtcsPtk

Happy to answer anything about design decisions, architecture, or roadmap. Would love feedback — what’s missing, broken, or too much?

Please star the repo, if you find usage of this repo.

We give autonomous AI agents shell access and API keys, relying on system prompts or Docker for security. This is fundamentally broken. When an agent is hit with an indirect prompt injection, it doesn't download a rootkit. It uses standard, signed binaries like curl or base64 to exfiltrate data. To the OS, this looks like a legitimate user executing a legitimate request. EDR fails because the binary isn't malware. Docker fails because it still allows outbound network access.

I’ve been engineering a split-plane defense architecture to solve this. Telos is an experimental hybrid runtime bridging LLM intent tracking with low-level kernel isolation. Instead of static firewall rules, Telos dynamically bounds execution and network access in real-time using eBPF-LSM hooks, Information Flow Control (IFC), and XDP hardware drops.

The Dual-Gate Architecture

Telos operates on one rule: Intent equals the perimeter. Agents declare intent to a local control plane, which translates it into O(1) eBPF hash maps.

1. Execution Gate (lsm/bprm_check_security)

Intercepts the execve() syscall. Telos checks the binary against the process's intent-map. If an agent authorized to "read logs" tries to execute nc, the kernel instantly returns -EACCES. This inherits down the process tree, killing fork/exec evasion.

2. Network Gate (lsm/socket_connect)

Intercepts outbound connections. Windows auto-expire via a TTL. If the agent is tricked into connecting to an unauthorized IP, the socket is killed before the TCP handshake.

The Capstone: Cross-Vector Taint Tracking (IFC)

What stops an agent from curl-ing a sensitive file it's allowed to read to a malicious server?

Telos monitors lsm/file_open, checking targets against an inode sensitivity map.

If the agent reads a CRITICAL file (like .env), Telos dynamically elevates the agent's taint to TAINT_CRITICAL in the eBPF process map.

The moment that process invokes socket_connect, Telos checks the taint state and triggers a Network Slam.

All outbound connections permanently return -EPERM. The data cannot leave the machine.

Escaping the OS: The Hyperion XDP Bridge

Telos routes agent DNS through a proxy pipeline (checking for typosquatting/homoglyphs). If a domain is flagged malicious, Telos resolves the IPs and pushes them via RPC to Hyperion XDP on the physical NIC. Packets matching that IP are dropped with XDP_DROP at wire-speed, before the Linux kernel even allocates an SKB.

The "AI" Anti-Hype

Putting an LLM in the hot path introduces massive latency. Telos keeps AI entirely out of the kernel hot path. All enforcement happens via deterministic, O(1) hash table lookups in C. The LLM only adjudicates complex edge cases asynchronously in the control plane.

Benchmarks and Trade-offs

I ran a 10-million operation torture test on bare-metal (AMD Ryzen 7 Pro 5850U, 5.15+ kernel).

file_open: +2.27 µs overhead (+8.5%)

bprm_check_security: +193 µs overhead (+3.0%)

socket_connect: +3.89 µs overhead (+1.9%)

Trade-offs: Telos fails closed; unparsed actions are instantly killed. Heavy bash-scripting workloads involving thousands of rapid fork() calls experience elevated eBPF map contention. To mitigate this under memory pressure, Telos utilizes BPF_MAP_TYPE_LRU_HASH to gracefully evict stale process states.

What's Next

Securing AI requires enforcement at the layer the AI cannot manipulate: the kernel. Telos is an open-source research runtime. I am particularly interested in feedback on bypass vectors I haven't considered, whether the IFC taint model holds under heavily multi-threaded agent workloads, or ways to optimize eBPF map lookups.

GitHub Repository: https://github.com/nevinshine/telos-runtime