Can an admin's CLI session be limited to specific environments?

Product Discussions Secrets Management
1

I’m an admin on our Infisical project, and I’m also a developer on the Node.js app it serves. I’d like your advice on limiting what my own CLI session can access.

The situation:
As an admin, I need full access in the dashboard to manage secrets across all environments (local, staging, prod). But for day-to-day development, I only need the CLI to read the local environment so I can run infisical run --env=local -- npm run dev.

The problem is that infisical login gives the CLI my full admin permissions. I run AI coding agents (e.g. Claude Code, Cursor) in the same terminal, and they can use that session to run infisical secrets --env=prod or infisical export and read every environment I have access to, including through prompt injection. I don’t want my CLI session to have the same reach as my dashboard session.

My questions:

  1. Is there a way to scope a user’s CLI login to specific environments or a reduced role, while keeping full admin access in the dashboard?
  2. Can CLI access to sensitive environments require re-authentication or MFA per request, or be disabled for user sessions entirely?
  3. If not, what’s your recommended pattern for admins in this position?
2

I think the risky part here is that the AI agent can use the same credentials as your admin account, not just that it can run CLI commands.

Even if the CLI asked for confirmation before accessing production, I’d still be a bit uncomfortable having admin credentials available in the same environment as an agent.

Maybe the safer approach is a separate machine identity that can only read the local environment, while keeping your admin login completely outside the development shell.

I’m not entirely sure how Infisical handles credential storage for different login methods, though. Would using a machine identity also prevent the agent from accessing any existing admin session on that machine?

That seems like an important detail before treating the setup as isolated.

3

Hey Paul, this is a really good question. You’re correct about the risk:

  1. Scoping a user CLI login is currently not possible. A user login gets your full project role, whether you’re in the dashboard or the CLI.

  2. MFA or re-auth per request: Not for CLI reads. On Pro or Enterprise you can drop your standing prod access and use Access Requests to get temporary, approved access when you need it.

The recommended pattern is to not stay logged in as yourself in the terminal where your agents run. Create a machine identity whose role can only read local, and run the app with it:

export INFISICAL_TOKEN=$(infisical login --method=universal-auth
–client-id= --client-secret= --silent --plain)
infisical run --env=local --projectId= – npm run dev

Run infisical logout in that terminal first. After that, any prod read from that shell gets a 403, including one from a prompt-injected agent.

This said to work with agents and broker access to their credentials, that is, give them no environment variables you can use Agent Vault, which is built into Infisical. You put the services (upstream hosts or MCPs) the agent needs in an access bundle and launch the agent through a time-bound session:

infisical agent-vault run --access-bundle= – claude

A proxy adds the real credentials to the agent’s outbound requests, so the agent can call the APIs but never sees the keys. Every request is logged. Agent Vault is still best suited where agents are isolated on a separate box, since agents are quite sneaky.

https://youtu.be/md2PwumM1Eg?si=a5tCUQ61TI_-i62D ← here’s a video on AV. Happy to answer any further questions as well :slight_smile: Thanks!

4

Ok. Thanks for the response.