Dora Noda"Restart the PostgreSQL database container immediately." That is not a horror story from a postmortem. It is one of the advertised example prompts of coolify-anythingllm-mcp, a new open-source MCP server that connects an AnythingLLM chat window directly to a self-hosted Coolify instance — so an AI agent can list your apps, read your logs, and trigger deploys, restarts, and rollbacks from plain English. The prompts hit the real Coolify /api/v1 with your real API token. The README's own disclaimer puts it plainly: the authors are not responsible for server downtime, data loss, or accidental resource deletion caused by your AI model.
This is the moment agent-operated infrastructure stops being a conference talk and starts being a side project with four commits and an MIT license. The question is no longer whether agents will drive deploys — it is what that costs in the three currencies every deploy system must pay in: scope (what the agent is allowed to touch), attribution (who decided, and where that decision is recorded), and reversibility (how you undo it). Here is the threat model, up front:
| Agent power | What it touches | Bound it needs | Bridge status |
|---|---|---|---|
| Deploy | App containers, live traffic | Scoped deploy-only authority, per-request identity | One shared API token, no policy layer |
| Scale | Replica counts, resource limits | Same scoping; previous state recorded | Same token reaches any exposed endpoint |
| Restart | Running containers — including Postgres | Human confirmation for stateful services | Advertised as a one-line prompt |
| Rollback | Live traffic, again | A tested, one-step undo path | Rollback-as-redeploy; no dedicated endpoint |
| Delete | Everything, permanently | Separate approval, soft-delete or backup | Same credential as read-only tools |
| Read logs | App output, possibly secrets | Sensitive-log redaction, least privilege | Token needs elevated read for logs |
The rest of this post prices each row. None of it is an argument against agent-operated infrastructure — it is the bill of materials for doing it without learning these lessons from a 3 a.m. page.
What the bridge actually wires together
The architecture is three hops. AnythingLLM acts as the agent and chat UI, with the bridge registered as a custom MCP server. MCP over stdio carries tool calls from the agent to the bridge process. The bridge translates those calls into Coolify API requests against /api/v1, authenticated by a single COOLIFY_API_TOKEN read from environment variables. AnythingLLM's documented MCP support makes the client side genuinely plug-and-play: point it at the server entrypoint and the agent gains infrastructure tools next to its document tools.
Notice what is missing from that path: a policy layer. There is no component that asks "is this tool call allowed for this user, on this app, at this time?" The bridge proxies agent intent to raw API calls, and the only credential in the building is the one token in the .env file. Every trust boundary in the system collapses to a single question — what can that token do? — asked once, at setup, and never again.
This shape inherits two risks the wider MCP ecosystem already paid for in 2026. Unauthenticated or over-exposed MCP bridges are a known incident class: July's Ruflo flaw exposed bridge HTTP endpoints without authentication, letting network attackers invoke shell tools and read provider keys. And Microsoft's June warning established that tool descriptions themselves are agent supply chain — instructions and data mix in the model's working memory, so whoever defines the tools steers the agent as surely as whoever wrote its system prompt.
Cost 1: authority without scope
Coolify's API authorization docs instruct operators to select correct permissions when creating a token, and community API references document the ladder: read-only as the default, read:sensitive and view:sensitive above it, and a full-access * wildcard at the top. Multiple references agree that deployments and management operations need the wildcard. That ladder is the entire scoping story — and the bridge climbs straight to the top rung on day one, because a bridge that can deploy, restart, and roll back cannot do its job on a read-only token.
The result is ambient authority. The token that lists your applications is the same token that deletes them. A read-only-intent tool ("check container status") and a destructive tool ("restart the database") draw on one undifferentiated credential, so the blast radius of any tool is the blast radius of the whole API surface the token can reach. Least privilege is not partially implemented here; the design has exactly one privilege level, and it is "everything the token allows."
That makes every tool definition load-bearing. A single over-permissive tool — a delete helper with no confirmation parameter, a restart tool that accepts any container name including stateful ones — becomes an implicit delete permission, and the tool-poisoning class Microsoft warned about means a compromised or merely sloppy tool description can steer the agent toward using it. Fleet-wide audits are already counting the damage in bulk: the State of MCP Security 2026 report flagged 307 destructive-scope tools and 106 tool-poisoning cases across the servers it scanned. Permission enforcement on this surface is also still young upstream: a 2026 Coolify PR had to correct wrong permission middleware on API creation endpoints, the kind of fix that reminds you scopes are only as good as their enforcement.
A scoped design would look different: read tools on a read-only token, deploy tools on a deploy-scoped credential, destructive tools behind a separate approval — never one wildcard token shared by the whole toolset. The bridge's README calls environment-variable credentials "secure by design," but where a secret lives was never the risk. What the secret can do is.
Cost 2: action without attribution
When the agent restarts your database at 2 p.m. on a Tuesday, two records of that event exist, and neither is sufficient. Coolify sees an API call authenticated by one token — the same token behind every other call the bridge ever made. Which app, which action, what time: yes. Why: no. The why — the user prompt, the agent's plan, the tool arguments it chose — lives in AnythingLLM chat history, a conversational artifact that was never designed to be an audit log. Chat scrolls, sessions end, workspaces get deleted, and the reasoning trace of an agent run is not queryable the way a deploy log is.
An agent deploy that you can defend — to your team, your customers, or an auditor — needs a record with, at minimum:
| Field | Why it matters |
|---|---|
| Identity | Which human (or scheduled job) authorized this run, not just which token |
| Prompt and plan | The instruction and the agent's stated steps, so the decision is reviewable |
| Tool, target, arguments | Exactly what ran against what — the equivalent of a deploy diff |
| Result and rollback pointer | Success or failure, plus how to undo it |
And that record must survive the agent session. Tying attribution to a chat transcript means the audit trail has the durability of a browser tab. A serious agent-deploy path writes every mutating call to an append-only log outside the agent loop — the same way CI systems keep build history independent of whoever clicked "merge." The bridge has no such log because it has no such layer; it forwards calls and forgets them.
Cost 3: power without reversibility
Every power in the threat-model table needs an undo story. Scored honestly:
| Operation | Undo story | Verdict |
|---|---|---|
| Deploy | Re-deploy the previous image or tag | Workable, but it is a second deploy, not an undo |
| Scale | Restore the previous count — if anyone recorded it | Reversible only with memory the bridge does not keep |
| Postgres / stateful restart | The container comes back; in-flight transactions and connections do not | The README's own example prompt, disclaimed against data loss |
| Rollback | Re-deploy older artifact; community MCP docs note Coolify exposes no dedicated rollback REST endpoint | Rollback-as-redeploy: works until the old image is gone |
| Delete | Restore from backup, if a backup exists and you know what was deleted | Effectively final |
Two rows deserve emphasis. First, the Postgres restart is not a hypothetical I invented to scare you — it is the bridge's third advertised example prompt, sitting two screenfuls above a disclaimer that disavows responsibility for data loss. Restarting stateless web containers from chat is a party trick; restarting stateful containers from chat is a data-loss vector wearing a party trick's clothes. The bridge draws no distinction between the two.
Second, rollback-as-redeploy is strictly weaker than a real undo. A dedicated rollback path pins the known-good artifact, verifies health, and keeps the forward path intact. Re-deploying an old tag through the same agent loop that caused the problem replays every risk in that loop — the same ambient token, the same unattributed decision, the same missing confirmation — and silently fails if the old image was pruned. Rollback that depends on the thing that broke you is not a safety net.
The minimum bar for an agent-facing deploy server
None of this requires inventing new technology. It requires treating an MCP deploy server as production infrastructure instead of a demo. Five requirements, scored against the bridge:
| # | Requirement | Bridge |
|---|---|---|
| 1 | Scoped tools, not a raw API proxy: each tool carries only the authority its job needs | ❌ One wildcard token for everything |
| 2 | Per-request identity: every mutating call attributable to a human or job, not a shared secret | ❌ Single static token in .env |
| 3 | Human-in-the-loop on mutation: deploys, restarts, and deletes confirm before they run | ⚠️ Recommended in the disclaimer, not enforced by the server |
| 4 | Append-only audit trail outside the agent session | ❌ No log layer at all |
| 5 | Tested rollback path that does not depend on the agent loop | ❌ Rollback-as-redeploy through the same tools |
Five rows, zero full passes — and that is fine for what the project is: an experiment whose own documentation says "experimental" and "enable confirmations." The scorecard matters because this exact shape — chat UI, MCP bridge, one API token — is about to be replicated across every self-hosted platform with an API. Each copy inherits the same five gaps unless its authors price them deliberately. Note the bridge's youth as a signal, not a slur: a four-commit repo whose README documents a Node entrypoint while the tree ships Python files is moving fast, and fast-moving agent infrastructure is precisely what needs the checklist most.
Scoped deploy authority or nothing
The arc here is familiar. Every platform goes through a phase where the demo — look, the agent deployed it from chat — outruns the control plane the demo needs. Dashboards went through it, chatops went through it, and now agent bridges are going through it. The good news is the fix is a design choice, not a research problem: scope each tool's authority, attribute every mutation to an identity, log outside the session, confirm before destruction, and keep an undo path that works when the agent is the thing that failed.
For anyone building the self-hosted version of this future, the principle compresses to one line: a platform's MCP server should ship scoped deploy authority by default, not the full API surface behind one token. Agents deserve infrastructure context — the bridge's core insight is right, and giving an agent the state of your fleet really is a game-changer. But "the agent can see production" and "the agent can act on production with a single shared credential and no audit trail" are very different sentences, and only the first one is ready to ship today.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators there too, which is exactly why deploy authority needs scoping before it needs a chat box. Star the repo on GitHub or deploy your first app today.
