Introducing Transcend Rails: Agent Policy-as-Code

Today we launched Transcend Rails, an agent policy-as-code platform that decides, in real time, what every AI agent in your company is allowed to do. It's live in production with customers across media, consumer, and healthcare.

Every enterprise scaling their agentic initiatives hits the same wall. The agents already have access. Identity tools know who they are, gateways know which systems they can reach, and the governance platform has a document saying what they should do.

The question no one can answer is the one that matters most: can this agent take this action, for this purpose, right now?

Everyone governs access. Only Transcend governs the action.

So teams pick between two bad options. Keep agents in a sandbox, where they're controlled but producing very little. Or let them loose and hope nothing goes wrong. Neither gets you to production and the board is starting to ask what the agents cost and they returned last quarter.

How Rails controls and enables your agents

Rails answers the “Can this agent take this action, for this purpose, right now?” question action-by-action in milliseconds. You write the rules once, in plain language, and every agent on any stack runs inside them. Each agent gets an accountable owner, a complete audit trail, and a kill switch. Every action is allowed, denied or escalated to a person, and an agent never approves its own action.

The more you can enforce, the more you can safely automate your agents. Denials are a cost to minimize, not the goal.

Policies are anything you can write down: spend limits, yes or no on a tool, thresholds that need a human, or fields the agent never sees. Because an agent can act through several channels, Rails applies policy at five control points:

• Inference: What goes into and comes out of the model
• Tools: Which MCP tool calls go through, with which arguments
• Network: Where the agent can send traffic
• Memory: What it keeps across sessions
• The decision API itself, which any agent or system can call directly. An MCP gateway only sees the tool calls that pass through it. An agent that goes straight to a model provider or an API is invisible to it.

Why agent policy-as-code controls enables you to scale

It starts with knowing what you're running. Rails gives you one view of every agent across your stack, including who owns it and every decision it triggers. You can bring the agents you already run under policy, whether that's a Claude or Cursor session in engineering, an agent on Bedrock or Snowflake Cortex, or a custom build. You can also provision a new agent in its own isolated runtime.

Rails is also built for the fact that three different teams have to live with it. Business and policy owners write rules in plain language. Engineers drop to Rego, the open policy language underneath, and test each policy against real agent traffic before it enforces anything. Rails also shapes what comes back through the MCP gateway, trimming tool responses to the fields the agent actually needs, which cuts MCP token usage by up to 70%. Compliance and security teams get an audit log they can actually read: every decision with the action, outcome, reason, policy version, and owner. It's built on OpenTelemetry, so gateway traces stream into the tools your security team already runs.

The fastest way to get AI agents into production is to make sure they only do what you've approved.

Built to sit on top of your stack, not replace it

Every platform you already run has some governance built in. Your identity provider knows which agents exist and what they can authenticate to. Your MCP gateway or browser controls know what they can reach. Bedrock, Snowflake Cortex, Adobe, and the model providers each govern agents inside their own walls. None of them talk to the rest.

An enterprise running agents on four platforms has four sets of controls, four audit logs and no single answer to what any one agent is allowed to do. That's the same fragmentation story Transcend has spent a decade solving for customer data, and it's the reason agent innovation, and the growth behind it, stalls.

Transcend Rails is built to be the layer across it all:

• Consuming identity from Okta or WorkOS
• Governing tool calls from Claude, Cursor and any MCP client
• Sitting in front of any model provider, and
• Governing the outbound actions of agents running inside Bedrock AgentCore, Snowflake Cortex, and Adobe Experience Platform

One policy, written once, applies to every agent on every stack, and every decision lands in one audit trail. We're the layer that makes what you've already bought work as one governed system, which is how you adopt AI faster than the teams still reconciling four dashboards.

The permissions Fortune 500s rely on, built for agents

Most vendors in this market started from identity or network access control and are now adding enforcement. Transcend started from the other end. For nearly a decade, we have applied purpose limitation, consent, and regulatory rules inside the data path of Fortune 500 companies. That engine already makes 208 billion data decisions and governs 513 million operations and agents.

A digital media company wanted agents working on production content. Their CMS offered full write access or nothing, so the agents stayed out. With Rails, one policy lets agents read content but never write it, a distinction the CMS itself can't make. Their editors now work with agents on live content, with every action in the log.

Dr. Squatch wanted Claude Desktop working across Shopify and NetSuite without handing every agent admin rights. With Rails, each agent gets its own permissions on each tool, responses that touch finance data are checked for PII before they come back, and token spend is tracked per agent and per model provider. Here's how they described it:

Rails runs on the same policy brain as Policy Engine, the decision infrastructure that answers "Can I use this data?" inside the systems that touch customer data. Rails takes it a step further, asking the question, "Can my agent do this?" - answering it for every action an agent takes in real time. Because both run on the same decision engine, an agent acting on a customer record already knows what that customer agreed to.

Both run through Sombra, Transcend's zero-trust gateway, inside your own environment and on your own keys. Transcend never sees the data it governs.

Start with the agents you already have

If you're running agents on Claude, Cursor, Bedrock, Snowflake Cortex, or your own stack, you don't need a six-month policy project to find out whether Rails helps. Point it at last week's agent traffic and see what one policy would have allowed, blocked, and escalated. The first policy is usually one sentence. The audit trail tells you what the second one should be.

There are two ways to start: book a technical session and we'll run that exercise in your stack, or join the waitlist at transcend.io/rails for a free 30-day trial, no commitment.

If you're at Snowflake World Tour Chicago this week, come find us. We're showing Rails governing Snowflake Cortex agents under one enterprise policy, and we'll be in New York on October 15 as well.

Over the next few weeks we'll go deeper on how the policy model works, what the first thirty days look like for an early customer, and how we're working with the platforms in the agent management ecosystem.