Your AI agent can now set up secrets, without ever seeing them

AI agents write a lot of my code now. And sooner or later every one of them hits the same wall: the app needs a database URL, a Stripe key, an API token. So the agent asks you to paste it into the chat, or it opens your .env file and reads it.

Both are bad. A key pasted into a chat lives in that conversation forever. A key the agent reads can end up in a log, a commit, a screenshot or a prompt somewhere else. I've leaked enough .env files myself to know how that ends.

So today Nionx Cloud gets a connection for AI agents. Your agent can set up projects and say which secrets the app needs. It can check which ones are ready. And when a value is missing, it asks you to type it into Nionx. It never sees the value. Not once, not by accident, not with any setting.

Connect it in one command

Nionx speaks MCP, the protocol agents like Claude Code, Cursor and others use to talk to outside tools. In Claude Code it's one line:

claude mcp add --transport http nionx https://api.nionx.cloud/mcp

Other agents that support remote MCP servers with sign-in work the same way: give them https://api.nionx.cloud/mcp. There are no keys to copy. The first time the agent uses Nionx, your browser opens, you sign in, and you see an approval screen.

You decide what it can do

The approval screen shows three things.

• Which tool is asking. Agents register themselves and pick their own name, so the screen also shows where it will send you back to (for Claude Code, a local address on your own computer). Only allow it if you just started connecting it yourself.
• Which workspace. The agent works in one workspace you pick, never all of them.
• Which permissions. Grouped by area, each with a level you slide between.

The permissions are:

• Projects and environments: None, Read (see them) or Edit (also create new ones). It never deletes or renames anything.
• Secrets: None, Read (see names and which ones are set or missing) or Edit (also define new secrets by name, without values).
• Secret values: None or Ask (send you a one-time link to type a value in). There is no “Read”. It doesn't exist, so you can't turn it on by mistake.

If you lower a level, the agent doesn't just get told “no”. The tools behind it disappear from its connection completely.

What the agent can do

With everything allowed, an agent gets these tools:

• list_projects and list_environments: what exists in the workspace.
• create_project and create_environment: a new project starts with development, staging and production.
• list_secrets and secret_status: names, and whether each one is set, not set, revoked or missing.
• require_secrets: make sure an environment has these secrets defined. It creates the missing ones, without values.
• request_secret_value: ask you for one value.

Your role still applies. If you're a viewer in a workspace, your agent is a viewer too: it can look, but defining secrets or creating projects fails, exactly like it would for you in the dashboard. The plan limits apply the same way.

How a value gets in without the agent seeing it

This is the part I care about most. Say the agent is adding payments to your app:

You:   Add Stripe checkout to the shop.

Agent: I need STRIPE_SECRET_KEY in production. I've defined it
       in Nionx. Open this link and paste your key there:
       https://dash.nionx.cloud/set/nx_set_...

You:   (open the link, paste the key, click Save value)

Agent: STRIPE_SECRET_KEY is set. Continuing with checkout.

Behind that:

• The agent calls request_secret_value and gets back a link. Nothing else.
• The link opens a page on dash.nionx.cloud that shows the workspace, project, environment, the secret's name, and which tool asked.
• You type the value there. It goes from your browser to Nionx, gets encrypted and is stored as a new version, like any value you set in the dashboard.
• The agent checks with secret_status and sees one word: set.

The link is careful too:

• It works once. After you save, it's dead.
• It expires after 15 minutes.
• It only works for you. Someone else who gets the link, even signed in to their own Nionx account, sees “This link no longer works”.
• Nionx stores only a fingerprint of it (a SHA-256 hash), the same way it handles API tokens.

One honest note: the agent can still ask you to paste a key into the chat. Nionx can't stop a model from typing a sentence. What it does is make the right path the easy one: the agent gets clear instructions to never ask for values in chat, and a link to give you instead. If an agent ever asks you to paste a secret, don't.

You stay in control

Every connected tool shows up under Account → Connections: its name, where it connects from, when you connected it, when it was last used, its workspace and its permissions.

Click Revoke and it stops on its very next request. Not in an hour when its token expires: every single request checks that the connection still exists.

And everything an agent changes is in the audit log as you, with the tool's name:

Created project Shop via Claude Code
Created STRIPE_SECRET_KEY in shop / production via Claude Code
Asked for a value for STRIPE_SECRET_KEY in shop / production via Claude Code
Set STRIPE_SECRET_KEY to version 1 in shop / production, asked for by Claude Code

Under the hood

For the people who want to check my work:

• Connecting uses OAuth 2.1 with PKCE, like signing in with Google. Agents register themselves (dynamic client registration), so there's nothing to set up first.
• Access tokens are bound to https://api.nionx.cloud/mcp and last an hour. The agent refreshes them quietly in the background until you revoke it.
• The tokens hold only the permissions you allowed. The server checks the token, your connection, your membership in the workspace and your role on every tool call.
• The code that serves the agent has no way to decrypt anything. It reads names and status from the database, never the encrypted values table.
• There are automated tests for all of this, including one that sets a value through a link and checks that the value appears nowhere: not in the tool's answers, not in the API's response, not in the audit log.

What's next

The connection is the first half. The second is the nionx command-line tool: it signs in with the same approval screen, links a folder to a project, and starts your app with its secrets loaded, without ever writing a .env file. After that come proper docs and a setup guide written for agents to read themselves. It's all on the roadmap.

Nionx Cloud is still in closed beta, so use test values only, not your real production keys. If you have an invite, connect your agent and try to make it leak a secret. If you manage it, I really want to know.

Benji