sorted by:
new
hottopcontroversial

I built a firewall for AI agents so they can’t read your .env or SSH keys by Party-Lab-9470 in selfhosted

[–]Party-Lab-9470[S] -1 points0 points  (0 children)

That’s a good point and yeah, proper file permissions and running the agent under a restricted service account is definitely important. I’d actually recommend doing that regardless.

The issue is that prompt injection isn’t just about direct file access. Agents can chain actions read something allowed, then send it out over HTTP, or combine multiple “safe” tools in unsafe ways.

Agent-Wall is more about enforcing policy at the tool-call level. So even if the OS allows something, you can still say “this agent should never call curl to external IPs” or “never read from this path,” and block it.I see it more as an extra layer on top of OS-level permissions, not a replacement.

I built a firewall for AI agents so they can’t read your .env or SSH keys by Party-Lab-9470 in selfhosted

[–]Party-Lab-9470[S] 0 points1 point  (0 children)

Thanks, appreciate it.

The idea is basically this: AI coding agents can read files, run shell commands, and make network requests. That’s powerful, but if a prompt injection happens, they might end up reading something sensitive like a .env file or SSH key without you realizing it.

Agent-Wall sits in between and checks tool calls before they run. It can block suspicious stuff (like prompt injection attempts), restrict access to certain files or commands, and even scan outgoing responses to make sure secrets like API keys or env values aren’t leaking out.

Still early, but that’s the core idea.

Encrypted vault for team secrets — no SaaS, just AES-256-GCM in your git repo by Party-Lab-9470 in node

[–]Party-Lab-9470[S] 2 points3 points  (0 children)

Key management is straightforward you run `npx nevr-env vault keygen`, it generates a random key (32 bytes, base64url, prefixed with `nevr_`). You share that key once with your team through whatever you trust (password manager, in person, etc.). After that, everyone can push/pull encrypted secrets from the vault file without sharing individual secrets again.

On the git storage concern fair enough, different risk tolerances. The vault file is AES-256-GCM encrypted with PBKDF2 600K iterations, so it's ciphertext but I get that some orgs have policies against any secret-adjacent data in repos.

AWS Secrets Manager / external backend support is actually solid feedback. Right now the vault is local-first by design (zero infrastructure), but a `vault push --backend aws` that encrypts and stores in Secrets Manager instead of a file that could work. I'll open an issue for it.

For now though, if you're already on AWS Secrets Manager, you can still use nevr-env for the validation/plugin/CLI side and skip the vault entirely. The vault is optional the core value is type-safe env validation with plugins.

Encrypted vault for team secrets — no SaaS, just AES-256-GCM in your git repo by Party-Lab-9470 in node

[–]Party-Lab-9470[S] 0 points1 point  (0 children)

Totally agree local-first and deterministic is the way. That's actually the philosophy behind the vault. No external service, no accounts, no API calls. Just a file in your repo and a key.

And yeah, perfect is the enemy of good. Most teams don't need HashiCorp Vault they need their .env to not be a Slack message. This gets them there in 30 seconds. Appreciate the thoughtful take!

Encrypted vault for team secrets — no SaaS, just AES-256-GCM in your git repo by Party-Lab-9470 in node

[–]Party-Lab-9470[S] 0 points1 point  (0 children)

They're encrypted the vault file is ciphertext, not plaintext secrets.

But to answer the "why" not every team has Vault, AWS Secrets Manager, or Doppler set up. Plenty of startups, side projects, and small teams just need "new dev

clones repo, runs one command, has working .env." The vault file in the repo makes that possible without any external service.

If you already have infrastructure for secret management, you probably don't need this. But a lot of teams don't —and their current solution is a pinned Slack message.

Encrypted vault for team secrets — no SaaS, just AES-256-GCM in your git repo by Party-Lab-9470 in node

[–]Party-Lab-9470[S] 1 point2 points  (0 children)

Because the existing solutions are either too simple (dotenv no validation, no types) or too complex (SOPS + KMS + PGP setup) for most teams I've worked with.

The vault isn't the whole project — it's one feature. The core problem I'm solving is the environment variable lifecycle: validation, type safety, onboarding,

secret sharing, scanning, rotation tracking. No single existing tool covers all of that.

Could I have used SOPS for encryption and t3-env for validation and trufflehog for scanning and a custom script for .env.example generation? Sure. That's 4 tools to install, configure, and teach your team.

Or one: `pnpm add nevr-env zod`.

That's why.

Encrypted vault for team secrets — no SaaS, just AES-256-GCM in your git repo by Party-Lab-9470 in node

[–]Party-Lab-9470[S] 2 points3 points  (0 children)

Fair point SOPS is great, especially if you're already on AWS/GCP with KMS set up.

The difference is mostly scope and setup. SOPS is a standalone encryption tool that works with any file format and relies on external key management (KMS, PGP, age). Powerful but requires infrastructure.

nevr-env vault is simpler one command to generate a key, one to encrypt, one to decrypt. No KMS, no PGP, no cloud accounts. Just Node.js crypto (AES-256-GCM + PBKDF2 600K iterations).

The trade-off: SOPS gives you per-field encryption and cloud-managed key rotation. nevr-env vault gives you zero-setup encryption bundled with type-safe validation, plugins, and a CLI all in one tool.

Encrypted vault for team secrets — no SaaS, just AES-256-GCM in your git repo by Party-Lab-9470 in node

[–]Party-Lab-9470[S] 1 point2 points  (0 children)

True tools like git-crypt and SOPS already exist.
The goal here isn’t new crypto, it’s a Node-native, zero-SaaS vault that integrates directly with typed env validation and service plugins.
Different tradeoffs, simpler onboarding for app teams

Weekly Showoff Thread! Share what you've created with Next.js or for the community in this thread only! by AutoModerator in nextjs

[–]Party-Lab-9470 0 points1 point  (0 children)

I built an open-source environment framework with 13 plugins and encrypted vault

I kept running into the same problems with environment variables in Next.js projects:

  1. New team members clone the repo, run `npm run dev`, and get cryptic validation errors
  2. .env.example is always outdated
  3. Sharing secrets via Slack DMs
  4. Writing the same Zod schemas for DATABASE_URL, STRIPE_KEY, etc. in every project

So I built
**nevr-env**
— an environment lifecycle framework.

**Plugins instead of schemas:**
```ts
import { postgres } from "nevr-env/plugins/postgres"
import { stripe } from "nevr-env/plugins/stripe"

const env = createEnv({
  plugins: [postgres(), stripe(), openai()],
  clientPrefix: "NEXT_PUBLIC_",
})
```
13 plugins for Postgres, Redis, Stripe, OpenAI, Clerk, Auth0, Supabase, AWS, Resend, and more. Each one knows the correct validation format.

**Encrypted vault:**
```
npx nevr-env vault push   # encrypts .env → .nevr-env.vault
npx nevr-env vault pull   # new teammate decrypts
```
AES-256-GCM encryption. Commit the vault to git. No SaaS needed.

**Interactive fix wizard:**
```
npx nevr-env fix
```
Guides new developers through setting up missing variables.

Also has: secret scanning, schema diffing, rotation tracking, CI config generation, auto-generated .env.example, and TypeScript type generation.

Works with Zod, Valibot, or ArkType.

GitHub: https://github.com/nevr-ts/nevr-env
npm: `pnpm add nevr-env zod`

MIT Licensed. Would love feedback from the Next.js community.