We gave Claude deploy access to production. The hard part was choosing what to forbid.
Quick follow up to my origin story post from earlier this week. A few people asked about the MCP part, so here is how it actually works and what we learned building it.
The flow from the user side is almost embarrassingly short. You finish your code in Claude or Cursor. You say deploy this. About two minutes later you get a working link back: server provisioned, SSL in place, environment configured as part of the deploy. Then the part I personally use most: you change something, say update it, and the same link refreshes. No terminal, no dashboard, no context switch.
Why bother? Because the place where people write code with AI is a chat window, and every step that forces them out of it loses users. For technical folks that step is friction. For people like me, and I can't code, that step is fear. The dashboard is where I start guessing. The chat is where I already know what to say.
But here is the part that turned out to be the actual work. Giving an AI agent the power to deploy is easy. Deciding what it must never be able to do took longer than the integration itself. And honestly, the line ended up in a different place than I expected.
What the agent can do, the full project lifecycle:
- create and deploy a project
- redeploy and update it
- add and remove custom domains
- work with project files
What it can never touch, by design:
- billing and subscription (read only, the write tools simply don't exist)
- the account itself
On top of that, every action is rate limited and every single one lands in an audit log. And every deploy coming through MCP goes through the same security scanning as a manual upload, before the agent even gets the project. The line is not deploy versus delete. The line is money versus everything else.
The thing that surprised us most: first deploys get the applause, but updates carry the product. Watching usage, the loop of tweak, update, check the link is where people actually live. An agent that can only deploy once would be a demo. The boring update path is the feature.
We are in open beta, and this whole thing is still being shaped by whoever shows up and breaks it. Which brings me to the question I'm genuinely curious about: if you build with AI tools, where is your personal line? What would you happily let an agent do to your production, and what stays human only?
the money vs everything else line is good, but reading this thread, almost everyone's axis is some version of harm to you. billing, account, the infra stuff you'd notice yourself. the boundary i'd add is harm to people who aren't in the room. the agent can deploy, that's fine, but the code it ships can quietly leave an endpoint open and the log on your end still shows a clean deploy. nothing happened from your side. your users find out, you don't. so my personal line is any action where the damage lands on someone who can't veto it in the moment. honestly the scan-on-every-deploy is carrying more of that than the forbid list is.
“The dashboard is where I start guessing. The chat is where I already know what to say.” — that’s the clearest articulation of why MCP matters for non-technical users I’ve seen. Worth putting on the landing page.
The billing boundary is the right call, and the reasoning — money vs. everything else — is a cleaner mental model than the usual “destructive vs. non-destructive” framing people default to. Deletion is recoverable. An unexpected charge at 2am is a relationship problem.
To your question: my personal line is anything that touches external parties without a confirmation step. Deploying my own project, yes. Sending an email, posting publicly, charging someone — those get a human in the loop regardless of how confident the agent sounds. The failure mode isn’t the agent being wrong, it’s the agent being wrong loudly.
Curious whether you’ve seen any patterns in where beta users are drawing their own lines — or whether most people just accept the defaults without thinking about it until something surprises them.
This is the right question. As someone who built an entire SaaS with AI assistance, the "what to forbid" list is more important than the "what to allow" list.
My rule: AI can write code, can run tests, can suggest database migrations. AI cannot deploy to production, cannot touch billing, cannot send emails to users.
The scary part isn't the AI making a mistake — it's the AI making a subtle mistake that looks correct. Defense in depth, not trust.
I had the same trust wobble watching agents touch prod, the scary part isnt the first deploy, its the sleepy update when nobody rereads the scope. Some teams keep a Notion runbook, some wire a plain audit trail page, I built PrivacyForge because the user-facing policy and permission story drifts right when new MCP actions or vendors get added. I'd put the forbidden actions and rollback promise in the same place users see the deploy button, tbh.
The "money vs everything else" line is clean, but I think the sharper axis is reversible vs irreversible. Billing is irreversible — but so is removing a custom domain (DNS propagation) or wiping project files, and both already sit inside what the agent can do. On my own small backend, the only actions that ever truly worried me were the ones I couldn't undo in 30 seconds, money attached or not. Your "the write tools simply don't exist" instinct is the real win though — a capability you never grant beats a forbid-rule you have to enforce every time. So maybe it's less about what to forbid and more about what's cheaply reversible. Where's your reversible line?
The “first deploy is the demo, the 12th update is the real trust test” point is really strong.
I think I’d be comfortable with an agent deploying only if three things are true:
For me the scary part is not “can it deploy?” but “can I understand what changed fast enough when something breaks?”
So maybe the boundary is less about deploy vs no deploy, and more about reversible vs irreversible actions.
The strongest point here is that first deploys are the demo, but updates are the habit.
A lot of AI deployment products will probably over-position around “ship from chat,” but the real trust problem is what happens on the 12th update, when the user is moving fast and the agent has enough power to create damage.
So I think the sharper frame is less “Claude can deploy to production” and more “Claude can keep updating production safely inside strict boundaries.”
That also makes the forbidden list more important than the feature list.
For me, money, account ownership, customer data, and destructive infra actions stay human-only. Deploy/update can be agentic if the rollback, audit log, permission boundary, and scan layer are obvious enough that the user does not have to trust the agent blindly.