What You're Actually Granting When You Connect an AI Agent to Your Hosting

Connecting Cursor, VS Code, or Claude Code to the MCP server gives your AI agent 22 tools: 8 that only read, and 14 that change something — 13 of which are flagged destructive. That framing is useful but incomplete, and the incomplete part matters. "Read-only" describes whether a tool changes state, not how sensitive the data it returns is. Two of the read-only tools hand your agent working credentials: one returns every environment variable your app holds, and one returns a git URL with push access embedded in it. Neither modifies anything. Both are worth understanding before you paste a token into your editor's config.

The 22 tools, grouped by what they can do#

Read state (8). List your apps, read logs, read status, read environment variables, read ports, read volumes, and fetch a git deploy URL for a new or existing app.

Change configuration (10). Set the Docker image, the built image, the run command, CPU/RAM quotas, environment variables (set all, or update one), ports, and add or remove a volume. Also rename the app.

Change lifecycle (4). Start or restart, stop, execute a command inside the running container, and delete the app.

Thirteen of those fourteen are additionally marked destructive — including ones you might not expect, like setting quotas or environment variables. That's accurate rather than alarmist: changing either recreates your container, so your app goes down and comes back.

The one exception is adding a volume, which is marked as changing state but not as destructive. That's arguably understated, since attaching a volume also triggers a restart.

Notably absent: there is no tool that creates an application directly, no billing or payment tool, and nothing that touches your account or user profile. New apps come into existence by pushing to the git URL the deploy-info tool returns.

Read-only doesn't mean low-risk#

This is the part I'd want to know, and it isn't specific to this platform — it's how the annotation is defined everywhere.

jrnm_get_env_vars returns your secrets. Environment variables are where your model API key, bot token, and database password live — that's the correct place for them. A read-only tool that returns them changes nothing and still puts every credential your app holds into your agent's context window.

The git deploy-info tools return credentials too. They're read-only in the strict sense — fetching a URL doesn't modify your app. But that URL has push access embedded in it, and anything that can push can replace your running code.

So the useful mental model isn't "read-only tools are safe." It's: an agent with this connection can see your secrets and can deploy. Decide whether you're comfortable with that, rather than inferring safety from a flag.

The sharpest tool in the set#

jrnm_execute_command_in_app runs an arbitrary command inside your running container. It's marked destructive and non-idempotent, which is honest — running it twice isn't the same as running it once.

It's genuinely useful: your agent can check whether a file landed, inspect a database, or read a config without you opening a shell. It's also the tool with the widest blast radius, because "arbitrary command" means exactly that.

jrnm_delete_app deserves a specific note. Deletion is soft for a retention window, but recovering a deleted app requires an administrator — you can't undo it yourself from the panel. That makes it the one tool where an agent's mistake needs a support conversation to fix.

Keep a human in the loop#

The MCP specification is unambiguous about this, and it applies to every MCP server, not just this one: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations" (MCP spec).

The same document tells clients they should "prompt for user confirmation on sensitive operations" and "show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration."

In practice that means: leave your editor's tool-approval prompts on. The temptation to auto-approve everything is strongest exactly when you're iterating fast, which is also when a wrong app ID does the most damage.

The injection path worth knowing about#

Your agent reads your logs. Your logs contain text your users wrote — a Discord message, a webhook payload, a form submission.

That's a path from an untrusted stranger into your agent's context. An attacker doesn't need to reach your infrastructure; they need to get a string into your log output and hope your agent treats it as instructions rather than data. This isn't hypothetical in the general case, and the same shape applies to any agent that reads production data.

Two cheap mitigations:

• Don't auto-approve tools after a log read. That's the moment to be reading what your agent proposes.
• Be careful what you log. Logs you don't sanitise become agent input. Truncating user-supplied strings is good practice for readability anyway.

Practical setup#

• Use the short-lived token, not a permanent secret. The MCP config in the panel issues a revocable token rather than exposing your password. If your editor config leaks, revoking it is the fix.
• Point experiments at a staging app. An agent iterating on deploys should be restarting something nobody depends on. This is the single highest-value habit, because most agent damage is a right action on the wrong app.
• Watch what lands in shared context. If your agent reads environment variables and you later paste that conversation into an issue or a shared thread, you've leaked the secrets. Treat any transcript that touched get_env_vars as sensitive.
• Rotate on suspicion, not on proof. Revoking an MCP token and regenerating an API key takes two minutes. Establishing that nothing happened takes much longer.

FAQ#

What can an AI agent do with MCP access to my hosting?#

Read your apps, logs, status, environment variables, ports and volumes; change image, command, quotas, env vars, ports and volumes; start, stop, restart, run commands in the container, and delete the app.

Can my agent see my API keys?#

Yes. Reading environment variables is a read-only tool, and environment variables are where secrets live.

Can it create a new app?#

Not directly — there's no create tool. It fetches a git deploy URL, and pushing to that URL creates the app.

Can it spend money or change my billing?#

No. There are no billing, payment, or account tools in the set.

What's the most dangerous tool?#

Running an arbitrary command in a live container has the widest reach. Deleting an app is the least reversible — recovery needs an administrator.

How do I revoke access?#

The MCP config issues a short-lived token from the panel rather than using your password, so revoking or letting it expire cuts the agent off.

Wrapping up#

Giving an agent deploy access is a real convenience — no context switching, no copy-pasting URLs, logs and restarts where you're already working. It's also a genuine grant of authority, and the read-only/destructive split describes state changes rather than sensitivity, so it under-reads the risk of exactly two tools. Know that your agent can read your secrets and push your code, keep approval prompts on, point it at something disposable while you're learning what it does, and the convenience costs you very little.