Proposal: intent verification layer before destructive agent operations

[Rodrigo-Ichaso]

Background

On April 24, 2026 an AI agent deleted a production database on Railway in 9 seconds. The agent confessed it "guessed instead of verifying."

That incident directly motivated building IRL.

The gap

railway-skills gives agents powerful capabilities — deploy, release, environment config, recovery. But there's no layer that asks *should this

What IRL adds

Intent Record Language is a pre-execution layer. Before any destructive operation the agent emits a structured record:

• operation_type: delete / deploy / env-change…
• target_resource: exact service or DB
• goal: declared intent in natural language
• risk_level: LOW / MED / HIGH / CRIT
• reversible: boolean
• verdict: ALLOW / LOG+ALLOW / GATE / DENY

A deterministic engine evaluates it. The Railway incident scores CRIT + irreversible → auto-denied.

Relevance to railway-skills

A verify_intent skill could wrap any destructive railway-skill call before execution. Zero changes to existing skills — just a guard layer.

Demo → https://rodrigo-ichaso.github.io/irl/demo.html
Spec → https://rodrigo-ichaso.github.io/irl/spec.html
MCP discussion → modelcontextprotocol/modelcontextprotocol#2693

Open to feedback or collaboration.

[IgorGanapolsky]

Your intent-verification proposal is exactly the layer we built at ThumbGate (which, by coincidence, runs on Railway). npx thumbgate init installs a PreToolUse hook that blocks destructive agent ops after one 👎. If a ThumbGate-Railway skill plug would shortcut what you're proposing, happy to ship one this week as a demo — just say which destructive-op classes matter most to your team.

[Ram9199]

I am collecting real-world incidents around AI agents with production/cloud authority.

For the Railway database deletion incident that motivated this proposal, what controls changed afterward in practice - scoped tokens, manual approval, read-only/staging credentials, audit logs, Docker/VM isolation, provider-side confirmations, or stopping agents from touching Railway resources? Did existing controls feel sufficient?

Not asking about any product. I am trying to identify repeated behavior changes after agent-authority incidents.