Introduction
Learn what AuthRail does and follow one example from an organisational rule to a checked AI action.
An AI support assistant can read a conversation, suggest a reply and ask a tool to change a customer's account. Giving it a useful model is one part of the work. Your team also needs to decide which changes it may request, when a person should review them and how to check what happened.
AuthRail is a workspace for governing how your organisation uses AI. It helps you organise the duties you follow, document the practices your teams use, review proof that those practices work and check actions in connected AI applications.
You can start with the organisation's governance work. Installing an SDK comes later, when you connect an application.
Follow one support-team example
Suppose your support team wants a person to review sensitive account changes before its AI assistant can make them. The team needs a clear practice, a way to apply it and records it can review afterward.
1. Understand the duties you need to meet
A Framework groups duties your organisation follows, such as obligations from a regulation or standard. In AuthRail, you choose a Framework, explain where it applies and review the duties relevant to your organisation.
For the support team, one applicable duty might concern human oversight. That gives the team a reason to establish and check its review process. The Frameworks guide shows how to start that work.
2. Describe what people should do
A Policy states the organisation's expectation: sensitive account changes need human review. A Control describes the practice that fulfils it: who reviews the request, what they inspect and how the application waits for their decision.
The same Policy and Control can support several Frameworks. You maintain the practice once rather than writing a different copy for each obligation.

3. Check that the practice works
A Test describes a repeatable check. For example: inspect the support team's sensitive changes for a month and check whether each has the required review. Evidence is the material reviewed to support the conclusion, such as the request list and approval records.
Readiness shows how that reviewed work supports the Framework's applicable duties and what still needs attention. A missing record or failed check stays visible; a percentage is not legal certification.
4. Apply the rule inside an AI application
Runtime connects reviewed rules to an application's actual tools. Those rules are called Rails. They can check a request before a tool runs and check its result before information returns to the agent.
For the support assistant, Runtime can require approval before the protected account-change function continues. Your application keeps the provider credentials and performs the operation. AuthRail records the decisions and the application's execution reports so the team can investigate them afterward.
Runtime has two modes. Observe shows what the rules would decide while the application continues. Enforce makes the connected protected path require permission before it runs. The developer must place the check at the real tool and keep the agent from reaching its credentials another way.
Start with your organisation's work
Begin with Frameworks and scope, then follow the governance guides through Policies, Controls and proof. You will have a clear account of what your team expects, how it operates and what supports that account.
After that, How Runtime works explains the application connection. The Runtime walkthrough shows a sample request, the running sidecar and the resulting AuthRail records.
More about decisions, execution and proof
An allowed decision says that a request met the checked rules. An execution report says what the application reported about its attempt. Looking up the provider's own record can establish whether an external change happened. These are different questions, and AuthRail keeps their records separate.
An Action brings together a Runtime request's checks, approval and execution reports. Activity Records describe meaningful activity for review. A signed record helps establish integrity; it does not independently prove an external effect or certify compliance.
Runtime records can support a Control's Test or Evidence review when that review defines which requests and outcomes qualify. They do not automatically make a Framework obligation ready.