If you've been on X or Hacker News in the last day, you probably saw the post about an AI agent deleting a production database. This is the new reality we live in where we hand our AI agents control of everything.

It’s a bit like that whole “Son of Anton” thing from a certain TV show where the AI goes rogue, and deletes all the code. Except this time, it’s taken the data with it too.

Anyway, we had a customer whose database was hosted on Railway, and at the center of the post, was this command:

curl -X POST https://backboard.railway.app/graphql/v2 \
  -H "Authorization: Bearer [token]" \
  -d '{"query":"mutation { volumeDelete(volumeId: \"3d2c42fb-...\") }"}'

The request was authenticated, and our API honored it the same way it would for a CLI command or a CI pipeline. The difference is that it came from an AI agent. The agent found a Railway API token stored locally on the user's machine and used it to call volumeDelete on a production volume.

We’ve since recovered the database, and the customer is back up with all their data.

The bitter irony is….we built a lot of primitives for this already. The agent just skipped past them by going directly to that legacy endpoint. Let’s talk about the how it happened, and how to move quickly and safely with agents on Railway.

Delayed deletes - now in the Railway API

Our API has always worked as follows: you authenticate, you call a mutation, the mutation runs. That's the contract CI pipelines and deploy scripts have relied on, and it's also the contract the agent in this case ended up using. It found a long-lived token on disk, hit the GraphQL endpoint, and got the same answer a CI job would have.

Until this week, calling volumeDelete on the API ran the deletion immediately, with no way to undo it. Meanwhile, the dashboard had a 48-hour window for the same action.

We’ve since updated the API to match; all deletes now soft delete for 48 hours. Instant undo, a primitive available everywhere in the product, exists now in the API.

Our philosophy has always been one of safety, where every action is undo-able. We’ve aligned our API to this standard, so this issue can’t happen moving forward.

Setting granular token permissions

Railway has four layers to authenticate against the API today, from broadest to narrowest:

• Account scoped tokens give you access to everything in your account, across every workspace you're part of.
• Workspace scoped tokens are scoped to a single workspace, which is the right choice for team CI/CD.
• Project scoped tokens go narrower again, tied to a single project, scope-able down to the environment.
• OAuth is the fourth layer, designed for third-party apps acting on behalf of a user with granular permissions the user has explicitly granted. This is for the “Login with Railway” experience.

Sadly in this week's situation, the token was provisioned with account scoped access, the maximum access possible. The right scope existed, but the flow didn't make it obvious which one to pick, and the path of least resistance produced a token with more access than the work required. We’re going to take another look at the user experience here, so it’s obvious which level of access each token provides.

Backups on backups

Railway has two mechanisms of backups; if a user configures backups, their backups are stored at the interval configured in the dashboard.

Additionally, regardless of whether the user configures a backup, Railway maintains “disaster backups” in case of hardware failure, natural disaster, datacenter failure, etc. These backups are stored offsite, so even in disaster scenarios, data is secured.

Sadly, the legacy API pathway the agent called performed a cascading delete on the model, making the backups look unavailable in the UI. We’ve since remediated this issue by additionally delaying the delete on the backups themselves.

Let’s try that again - safely

The Railway team has been thinking about AI safety - we're making sure that we don’t have any unintended consequences like before.

AI agents have been building on Railway for a while now, and the way they use the platform looks very different from how a human does. They move faster, they take more turns, and the connection between what an agent is asked to do and what it actually does is looser.

A human running a CLI command knows why they're running it.

An agent is working from an interpretation of a task, and that interpretation can drift. The agent in that situation wasn't told to delete a database. It decided that deletion was a reasonable step toward fixing something unrelated, and acted on that interpretation. A next word predictor machine is going to do what a next word predictor does.

As a result, there's also no real sense of blast radius.

A human knows that "production" and "staging" mean different things, even when the API treats them the same. An agent often doesn't, or has a model of it that's wrong. It can call a destructive endpoint without registering that the volume on the other end is the thing keeping a business running. And when something does go wrong, the recovery instinct isn't there. A human who realizes they've made a mistake stops and asks for help. An agent that makes a mistake tends to keep going, sometimes making things worse while trying to fix the first one.

None of this is a knock on agents or the people building with them. Railway used to be a platform mostly used by engineers. That's still a big part of who's here, but it's not the whole picture anymore. A lot of the people shipping on Railway today are coming in through an agent, and they span a much wider range of experience than the platform was originally designed for. The assumptions the API was built on are getting stretched as a result.

The good news is we don't have to start from scratch. Railway already has a lot of guardrails built into the product. The dashboard, the CLI, the canvas, most of the surfaces a person actually clicks through on a given day are designed to make destructive actions hard to do by accident, and easy to undo when they happen.

While agents tend to work with the API and MCP, these protections are the foundation we're building on. Here's what's already in place:

Built-in guardrails

As it stands: Project deletion is reversible by default.

When you delete a project, you have to confirm it, and then it gets scheduled for deletion with a 48-hour grace period. If you change your mind, you can undo it from the dashboard. Our volume deletions work the same way. The actual deletion is scheduled for 48 hours. The data isn't gone the moment you click the button.

Undo volume deletion

Staged changes batch up modifications to your project so you can review a diff before anything actually ships. Add a service, change a variable, remove a database, none of it takes effect until you hit deploy. You can discard individual changes from the changeset before applying them.

Staged changes - get a reviewable diff of the changes you’ll make to your infrastructure

Environments let you separate production from staging from preview, so an action in one doesn't reach into another. It’s also possible for admins to mark environments as restricted. Non-admin members can still see that the environment exists and trigger deployments via git push, but they can't view variables, logs, metrics, or configurations inside it.

Create isolated environments

For teams, there's another layer on top: Guardrails. Workspace admins can turn on Guardrails to disable certain actions for non-admin members across every project in the workspace. The two policies live today are restricting public Railway domain generation and restricting public TCP proxies.

The pattern across all of this is the same: make the destructive thing slow, make the recoverable thing fast, and put the actual point of no return as far away from a single click as possible.

The other half of the work is giving agents better places to be in the first place. Most of our recent work has gone into building paths that fit how agents actually work.

Building surfaces for agents

Railway Agent

The Railway Agent is a chat-based assistant built directly into the Railway dashboard (It’s also exposed in the CLI). It can manage services, diagnose failing deployments, and open pull requests to fix issues in your code.

It works off a specific set of tools and has comprehensive safety mechanisms built in. All destructive operations are staged for user review before deployment. Additionally, the agent includes an eval harness that continuously tests behavior against real-world test cases to prevent regressions and ensure safety.

Railway Agent

Railway CLI

The Railway CLI has been the surface humans have used to script and automate Railway for years, and it's increasingly the surface agents are using too. Most coding agents tend to know how to use a CLI without needing a schema dump. We've been investing in making ours more agent-friendly, with clearer command structure, better output formats, and tighter feedback for the kinds of multi-step workflows agents tend to run.

Railway MCP Server

The Railway Remote MCP Server at mcp.railway.com is the integration layer between Railway and AI tools. Any MCP-compatible client (Claude Code, Cursor, Codex, GitHub Copilot, and others) can connect, authenticate through your Railway account in the browser, and start managing projects without any tokens on disk. Tokens are short-lived. You pick which workspaces and projects the client gets access to when you consent. There’s a specific set of predefined tools, so it’s not possible for an agent to go rogue.

Railway Agent Skills

If the CLI and the remote MCP are about providing tools for agents, the Railway Agent skills are about teaching the agent how Railway works: what a service is, what an environment is, what to check before deploying, which command to use for which task. When you ask Claude Code, Cursor, or Codex to "deploy to Railway", the agent picks up the skill and follows it. It gives the agent a model of the platform instead of leaving it to guess from a raw API.

Where this goes

Railway spent its first five years building for engineers. The next stretch is about building a platform that holds up for the much wider range of people now coming online through agents, including people who are letting the agent do most of the work, and including the agents themselves.

That means a few things in practice. Destructive actions should have undo paths. Tokens should have scopes that match the task. The surfaces agents use should be the ones we've designed for them, not a raw API endpoint accessed via a token sitting in a config file. None of this is finished. The situation this week is one of the data points we're using to figure out what to make safer next.

If something on Railway gets in your way, drop us a line on Central Station. You can also reach out to any of the Railway team members on X or LinkedIn, we’d love to hear from you.