Guardrails for every AI agent your company runs.

Register an agent by its URL, attach the checks your company needs, and hand out a guarded URL in its place. Every message is checked on the way in and on the way out, and the agent’s code never changes.

Open AgentsOnRails.dev See how a request flows

POST hub.acme.dev/a/support-bot

UserMy card 4111 1111 1111 1111 was charged twice. Can you refund one?

inputPrompt injectionPass3 ms
inputPIIcard number → [CARD]Redacted6 ms
agentsupport-botPass812 ms
outputToxicityPass41 ms

AgentI found two charges on the card ending [CARD]. I’ve refunded the duplicate.

Every team ships its own agent, and its own version of the rules.

Rules get rewritten or skipped.PII filtering, prompt-injection checks and topic limits are rebuilt in each agent, slightly differently, or left out under deadline pressure.

Nobody else can check.Compliance, QA and the business owner can’t see what an agent let through, or confirm it behaves the way they asked.

From agent URL to guarded URL in four steps.

1
Register the agent
Paste its A2A base URL. AgentsOnRails.dev reads the Agent Card and fills in the name, description and skills.
2
Attach guardrails and limits
Pick guardrails and policies, set the order, add budgets and timeouts. Company-wide mandatory policies are already there.
3
Deploy a guarded URL
You get a new URL and an API key. Point your app at it instead of the agent.
4
Let people test it
Chat with the guarded agent and see, per message, which guardrails ran and what they did.

What happens to each request

Mandatory policies run first and their blocks can’t be overridden. A block at either stage stops the call, and the agent never sees a blocked input.

Your app

Input guardrailsblock, redact or warn

Your agentunchanged

Output guardrailsblock, redact or warn

Your app

Blocked input returns TASK_STATE_REJECTED with the reason

Set the rules once. Every agent follows them.

Guardrails from templates: PII, prompt injection, toxicity, topic allow and deny lists, regex, or an LLM judge with your own prompt. Each one runs on input, output or both, and blocks, redacts or warns.
Policies: Group guardrails into a named policy and attach it as one unit. Change the policy once and every agent that carries it follows.
A company baseline nobody can remove: Admins mark policies as mandatory. They attach to every existing and future agent, run first, and developers can’t detach them. Exemptions need a written reason.
Budgets and time limits: Cap tokens and cost per call and per session, set a per-call timeout and a maximum session length, and choose whether going over blocks or warns.
An effective policy you can read: Company defaults, per-agent overrides and the mandatory layer combine into one effective policy. Each agent page shows every rule and where it came from.
Audit log: Every block, redaction, warning and limit hit is recorded with its rule id and config version. Filter by agent, rule or action.
A testing chat for non-developers: Business owners and QA chat with the guarded agent and see the trace for each message, then flag answers that miss the requirements.
Shared injection signatures: Your own list of prompt-injection patterns, used by the prompt-injection guardrail on all your agents.

Your app changes one URL.

Agents and the hub both speak the open A2A 1.0 protocol. The guarded URL serves the same Agent Card and accepts the same SendMessage call as the agent behind it, so any A2A client switches over without code changes.

A blocked call comes back as an ordinary rejected task with the reason. The trace rides along in metadata, and clients that don’t know about it ignore it.

- AGENT_URL=https://support-bot.internal.acme.dev
+ AGENT_URL=https://hub.acme.dev/a/support-bot
+ AGENT_API_KEY=ghk_••••••••••••

{
  "jsonrpc": "2.0",
  "id": "req-1",
  "result": {
    "task": {
      "contextId": "ctx-42",
      "status": {
        "state": "TASK_STATE_REJECTED",
        "message": {
          "role": "ROLE_AGENT",
          "parts": [{ "text": "Blocked by guardrail …" }]
        }
      },
      "metadata": {
        "agentsOnRails": {
          "blocked": true,
          "stage": "input",
          "trace": [ … ]
        }
      }
    }
  }
}

Your own private workspace.

Every account is separate, down to the database: each record carries its owner, and row-level security only ever returns your own.

Sign up in a minute
Use your email, GitHub or Google. Nobody shares a login, and there are no guest sessions.
Everything is yours alone
Agents, guardrails, MCP servers, signatures, sessions and the audit log belong to your account. Other users never see them.
A demo agent from the start
Every new account gets the demo support agent and a starter set of guardrails, so the first test chat takes one click.

Your first five minutes.

Each agent gets its own workspace that walks you through setup, one step at a time.

Follow along in the app

1
Register an agent
Paste an A2A agent URL. The hub reads its Agent Card and opens the agent's setup.
AgentsRegister agent
2
Attach guardrails
Pick checks from the library and put them in the order they should run.
AgentGuardrails
3
Test the pipeline
Send a message or pick a scenario. The trace shows which guardrails passed, redacted or blocked.
AgentTest
4
Go live with a key
Create a gateway key and point callers at the guarded URL.
AgentGo live

Guardrails for every AI agent your company runs.

Every team ships its own agent, and its own version of the rules.

From agent URL to guarded URL in four steps.

Register the agent

Attach guardrails and limits

Deploy a guarded URL

Let people test it

What happens to each request

Set the rules once. Every agent follows them.

Your app changes one URL.

Your own private workspace.

Sign up in a minute

Everything is yours alone

A demo agent from the start

Your first five minutes.

Register an agent

Attach guardrails

Test the pipeline

Go live with a key

Put your first agent behind a guarded URL.