LifecycleZero

Local AI models have a security blind spot. LifecycleZero tracks local AI usage and lets IT admins isolate compromised endpoints at the database level instantly.

Comment

LifecycleZero - B2B Endpoint Security for the Shadow AI Era

Inspiration

A few months back, a developer at a company i was consulting for was running Llama 3 locally on his work laptop. Feeding it internal API docs and proprietary architecture files. Completely offline. Their $200k/year DLP software saw absolutely nothing.

That kept bothering me. Every security tool i knew, web proxies, EDRs, firewalls, they all assume data leaves through the network. Local AI models broke that assumption completely. The binary isn't malware so antivirus ignores it. Theres no outbound connection so the proxy has nothing to block. The threat just exists, invisibly, in RAM.

I built LifecycleZero because i couldn't find anything that actually solved this without deploying something so heavy that developers disable it within a week.

Who buys this

The buyer is a CISO or IT Manager at a company with 500 to 5000 employees. They already pay for network security tools. They know their developers are using local AI. What they don't have is a way to audit which AI, on which device, touching which files, without something so invasive that engineering pushes back and kills it.

LifecycleZero is priced per monitored device, billed monthly. The agent is lightweight enough that developers don't notice it. Thats not a nice-to-have, thats the entire go-to-market strategy. A security tool that gets disabled is worse than no tool at all.

What it does

LifecycleZero runs a lightweight agent on employee laptops. It watches system telemetry, active processes, file access patterns, CPU and memory spikes, and streams it to a central dashboard for IT and security teams.

When the agent detects patterns consistent with a local AI model loading large weight files or ingesting sensitive directories, it flags the device. The admin sees the alert on the dashboard and can isolate the device with one click, locked out of the corporate fleet instantly.

The critical design constraint: we never send file contents or corporate data to any cloud AI provider. Threat evaluation runs on a local Ollama instance running on our own infrastructure. You can't build a tool to stop data leakage and then leak data to OpenAI to do the analysis. That would defeat the whole point.

Why DynamoDB and not Aurora or Aurora DSQL

All three AWS databases were available to us. We picked DynamoDB deliberately and rejected the other two for specific reasons.

Why not Aurora: Aurora is a relational database. Great for structured data with complex joins, billing systems, product catalogs. Our data is flat events. A telemetry ping is just device ID, timestamp, process list, CPU reading, file touched. No joins. No foreign keys. Forcing that into rows and tables adds complexity with zero benefit.

The bigger problem is connections. Our agents ping the API every few seconds from thousands of devices simultaneously. Vercel runs serverless functions, every request spins up a fresh instance. Aurora uses persistent TCP connections. Thousands of serverless functions all opening their own Aurora connection simultaneously will exhaust the connection pool and crash the database. This is a known documented problem, not a theory.

Why not Aurora DSQL: Aurora DSQL is designed for distributed transactional workloads that need SQL, think financial systems moving money between accounts across regions. We don't need SQL. We don't need multi-region distributed transactions. Using Aurora DSQL here would be solving a problem we don't have and paying for complexity we don't need.

Why DynamoDB: Our data model is key-value at its core. Device ID maps to telemetry events. DynamoDB was literally built for this pattern.

It communicates over stateless HTTP. Every serverless function makes an independent HTTP request. No connection pool. No crash. Scales to zero and back up automatically.

Pay-per-request pricing means when employees go home and agents stop pinging, our database cost drops to exactly zero. Aurora charges you whether anyone is using it or not. For a per-device SaaS product that's the difference between healthy margins and burning money overnight.

How i built it

Frontend: Next.js App Router deployed on Vercel. Used v0 to build the dashboard UI fast then customized heavily for security operations context, alert triage, device isolation controls, audit logs, fleet overview.

Ingestion pipeline: Agent on the laptop signs every request with HMAC-SHA256 before sending. Vercel Edge Middleware verifies the signature before the request even reaches the backend. Unsigned requests get dropped immediately. This prevents any rogue endpoint from spoofing a device identity and poisoning the fleet data.

Why SQS in the middle: Writing telemetry directly to DynamoDB at high frequency from thousands of devices is risky. Traffic spikes would hammer the database unevenly. I put Amazon SQS between the API and DynamoDB. The agent pings the API, SQS absorbs the burst, a background worker drains the queue and writes to DynamoDB at a controlled steady pace.

Hot partition fix: DynamoDB distributes data across partitions by key. If all telemetry writes use the same key pattern, all writes hit the same partition and it becomes a bottleneck. I used a polynomial hash of the device ID to spread writes evenly across shards. Took longer to get right than i expected.

Offline threat evaluation: Complex telemetry payloads get routed to a local Ollama instance for threat analysis. No data ever touches a cloud AI provider. This was a hard constraint from day one, the product exists to stop data leakage so the product itself cannot leak data.

Sparse GSI2 index: Most telemetry is boring, normal heartbeats, safe processes. I don't index those at all. Only flagged events get written to GSI2. The dashboard queries that sparse index and loads only actual alerts. Query cost is nearly zero even at fleet scale because it skips millions of safe pings entirely.

Device isolation: When an admin clicks Isolate Device, it triggers a DynamoDB TransactWriteItems call. One atomic operation that locks the device state AND writes the audit log at the exact same moment. No race conditions. No partial states. Once committed, the edge API immediately drops all future pings from that device with 403 Forbidden. This audit trail pattern is required for SOC 2 compliance which enterprise customers will ask for.

Challenges

Getting HMAC-SHA256 verification working on Vercel Edge Middleware was painful. Edge runtime has a restricted crypto API and i had to rewrite the verification logic twice before it was consistent across all request types.

Routing to local Ollama without ever falling back silently to a cloud endpoint required careful error handling. Silent degradation here would be a security failure, not just a bug.

DynamoDB single-table design took three full restructures before the access patterns were clean. The sparse index approach only clicked after i mapped out every single read and write pattern on paper first.

What i learned

DynamoDB single-table design is genuinely hard to get right the first time. But once the access patterns are mapped correctly, the economics are dramatic, dashboard query costs dropped roughly 95% compared to my first naive design.

Building privacy into the architecture from day one is completely different from adding it later. Every decision in LifecycleZero flows from one constraint, no corporate data leaves the perimeter. That constraint shaped the database choice, the inference routing, the agent signing, everything.

The unit economics of DynamoDB pay-per-request make the SaaS margins work in a way Aurora simply couldn't. At 1000 monitored devices, overnight idle cost is zero. That's the business model working at the infrastructure level.

Built With

Share this project:

Updates