I Built a Zero-Config Secret Manager in Rust Because .env Files Are Security Theater

Sruthi a — Mon, 30 Mar 2026 06:21:52 +0000

I Built a Zero-Config Secret Manager in Rust Because .env Files Are Security Theater

Every time I onboard a new developer, the instructions include:

"Ask someone for the .env file. Don't commit it."

That's it. That's our secret management strategy. A file we pass around on Slack.

We've all been there. A .env ends up in a repo. Or in a Slack message. Or gets pasted into a Notion doc for "convenience." Then six months later you're rotating every credential you own because someone found it in a git log.

The problem isn't that developers are careless. The problem is that .env files are the path of least resistance — and they're fundamentally insecure by design.

The Real Problems with .env

Let me be specific about what's wrong:

1. They're plaintext. Your DATABASE_URL sits in a text file on your disk, next to your code. If your laptop is compromised, all your secrets are too.

2. They travel through insecure channels. How do new devs get them? Slack DMs. Email. Sometimes a Google Doc. These aren't encrypted at rest. They're indexed. They persist.

3. They're static. That STRIPE_SECRET_KEY in your .env from 2022? Still valid. Still sitting in your old laptop's backup. Static credentials that never expire are the gift that keeps on giving — to attackers.

4. Git is forever. Even with .gitignore, secrets end up in repos. Accidentally committed, then deleted — but git log remembers everything. GitHub has a secret scanning feature specifically because this happens constantly.

5. No audit trail. Who accessed PROD_DATABASE_URL last Tuesday at 3am? With .env files: no idea. Zero visibility.

What I Built Instead

I got frustrated enough that I spent a weekend building zenv — a zero-config secret injection runtime for developers. zenv

The idea is simple: replace .env files with an encrypted vault that injects secrets at runtime.


bash
# Before zenv
cp .env.example .env
# edit .env with secrets from Slack...
npm start

# After zenv
zenv init
zenv vault import .env  # one-time migration
zenv run -- npm start   # secrets injected at runtime

Why AI Agents Need Knowledge, Not Just Memory

Sruthi a — Wed, 04 Mar 2026 01:11:26 +0000

Every AI agent framework in 2026 has some form of memory. Store a key-value pair, retrieve it later, maybe add a TTL. Problem solved, right?

Not even close.

The Memory Problem No One Talks About

Here's what happens when you give an agent flat key-value memory:

A digital care coordinator agent monitors a patient's records. It stores findings as separate memory entries: patient_vitals, medication_history, cardiac_risk_factors, sleep_irregularities. Clean, organized.

Meanwhile, a lab assistant agent is optimizing experimental designs for a drug trial. It stores: compound_efficacy, cardiac_biomarkers, dosage_response_curves.

The connection between the patient's cardiac risk factors and the lab's cardiac biomarker research? Gone. Invisible. Two agents sitting on related knowledge with no way to discover it.

This isn't a contrived example. It's what happens every day in every agent system using flat memory stores — in hospitals, research labs, and clinical workflows.

What a Knowledge Graph Changes

A knowledge graph doesn't just store facts — it stores relationships between facts. When an agent writes a note about cardiac risk factors and links it to [[Cardiac Biomarkers]], that connection is a first-class entity in the system. It can be traversed, queried, and discovered.

This changes three things fundamentally:

1. Agents discover what they don't know they know.

With flat memory, an agent can only retrieve what it explicitly searches for. With a graph, it can ask: "What's connected to X within 2 hops?" and find relationships it never explicitly created. A care coordinator could discover that a patient's sleep irregularities are linked to a medication whose cardiac biomarkers are being studied in an active trial — without anyone explicitly making that connection.

2. Multi-agent collaboration becomes natural.

A care coordinator agent flags a patient's worsening vitals. A lab assistant agent logs promising results for a new cardiac compound. If both mention [[Cardiac Biomarkers]], the graph links them automatically. A clinical decision agent can traverse from patient vitals → cardiac biomarkers → compound efficacy and surface a potential treatment option none of them could individually.

3. Knowledge compounds instead of accumulating.

Flat memory grows linearly. A knowledge graph grows combinatorially — each new node potentially connects to every existing node. After 1,000 notes with wiki-links across patient records, lab results, and wearable data, you don't have 1,000 facts. You have a web of clinical relationships that's worth far more than the sum of its parts.

The Current Landscape

The agent memory space is heating up. Mem0 raised $24M and processes 186 million API calls per quarter. Letta (formerly MemGPT) is building OS-inspired memory hierarchies. LangChain has LangMem. Everyone agrees agents need memory.

But here's the gap: almost all of these are flat stores with optional vector search. They're optimized for "remember this, recall that." They're not optimized for "discover connections I didn't know existed."

The enterprise world figured this out years ago. Knowledge graphs power Google's search, Amazon's recommendations, and every pharmaceutical company's drug discovery pipeline. The agentic AI world is still catching up.

What We Built

We built Smriti — a self-hosted knowledge store for AI agents with a knowledge graph at its core.

It's written in Rust (because when agents make millions of memory operations, speed matters), stores everything in SQLite (because self-hosted means no cloud dependency), and speaks MCP natively (because that's becoming the standard protocol for agent-tool communication).

The key design decisions:

Wiki-links as first-class connections. When an agent writes [[Cardiac Biomarkers]] in a note, that creates a traversable edge in the graph. No separate API call needed. A care coordinator logging patient data and a lab agent logging trial results automatically connect through shared concepts.
Graph traversal as a tool. Agents can BFS/DFS through the knowledge graph to find related notes within N hops. This is how a clinical decision agent discovers that a patient's symptoms connect to an active drug trial three hops away.
Self-hosted by default. Your data stays on your machine. No API costs, no cloud dependency, no vendor lock-in. Critical for healthcare use cases where patient data governance and HIPAA compliance are non-negotiable.
MCP server built in. Start with smriti mcp and any MCP-compatible AI can use it as a knowledge store. 8 tools: create, read, search, list, graph, memory_store, memory_retrieve, memory_list.

Who Is This For?

Developers building agentic workflows who need their agents to:

Remember across sessions (not just within a conversation)
Discover connections between stored knowledge
Share a knowledge base across multiple agents
Keep all data local and under their control

It's not for everyone. If you need cloud-hosted memory with managed infrastructure, Mem0 is great. If you need deep research-grade memory hierarchies, Letta is interesting.

But if you want a fast, self-hosted knowledge store where agents can build and traverse a knowledge graph — whether for healthcare coordination, lab automation, or any domain where relationships between data matter — that's what we built.

Try It

cargo install smriti

# Care coordinator logs patient data with wiki-links
smriti create "Patient 4721 Assessment" \
  --content "Elevated resting heart rate from [[Wearable Data]]. History of [[Cardiac Risk Factors]]. Current medication may affect [[Cardiac Biomarkers]]."

# Lab assistant logs trial findings
smriti create "Trial CB-209 Results" \
  --content "Compound shows 40% improvement in [[Cardiac Biomarkers]]. Correlates with [[Dosage Response Curves]]. Monitor [[Patient Vitals]] in Phase 2."

# Discover the connection
smriti graph --note 1 --depth 2

# Start the MCP server
smriti mcp

GitHub: github.com/smriti-AA/smriti
Crates.io: cargo install smriti

DEV Community: Sruthi a

I Built a Zero-Config Secret Manager in Rust Because .env Files Are Security Theater

I Built a Zero-Config Secret Manager in Rust Because .env Files Are Security Theater

The Real Problems with .env

What I Built Instead

Why AI Agents Need Knowledge, Not Just Memory

The Memory Problem No One Talks About

What a Knowledge Graph Changes

1. Agents discover what they don't know they know.

2. Multi-agent collaboration becomes natural.

3. Knowledge compounds instead of accumulating.

The Current Landscape

What We Built

Who Is This For?

Try It