AI governance and risk, backed by runtime enforcement
The enforcement layer AI governance is missing.
Every GRC tool produces paper compliance. Rinox produces the evidence automatically because it was in the path when the agent acted.
The gap
Paper compliance
A GRC tool records that a control should exist. It holds the policy document, the attestation, and the review date. It has no view of what an AI agent did on Tuesday at 14:02.
Machine speed, no record
An AI agent with a real credential calls any tool the key allows, in any order, faster than a person can watch. The only record is whatever the downstream tool happened to log, under the shared service account it was given.
Evidence from the path
Rinox sits in the path. Each action is checked before it happens and the decision is written to a tamper-evident chain as it is made. The evidence is produced by the control itself, attributed to the agent, the device, and the person, and it cites the requirement it was enforcing.
What Rinox enforces at runtime
Every governance claim on this page points to a control that operates in the action path. Six of them, one per IRON primitive.
Every action is attributed
Each action arrives bound to a scoped identity: the agent, its sub-agent, the device, and the human it acts for. The agent carries a Rinox-scoped token, never a raw credential, so the attribution cannot be forged by holding a key.
Deny by default, down to the argument
An agent may use only the tools its policy names. An allowed tool can still be refused on its arguments: a path outside the workspace, a host off the list, a destructive statement matched by pattern.
Session caps stop runaway use
Per-tool limits on calls and bytes per session. A looping agent or a bulk pull stops at the cap even when every individual call was allowed.
Dangerous chains are denied as chains
Read a sensitive file, then post to an external host: each step allowed, the chain denied, optionally within a time window. This is the rule a per-call filter cannot express.
Anomalous behavior is escalated
An action that is unusual for this agent (a new tool, a new transition, drift from the declared task) is escalated to warn, hold for a human, or block. Escalation only: a deny never becomes an allow.
Every decision is on the chain
Allow, warn, step-up, or block, each verdict is appended to a hash-chained ledger as it is made, with the policy that produced it. Held actions wait for a named approver and record who decided.
On managed devices Rinox also locks read-only paths at the operating system, launches governed agents under an OS sandbox that can write only where policy allows, and governs desktop AI applications by executable: deny, sandbox, or flag.
IRON, the audit and assurance standard for AI usage
IRON is the standard Rinox policies are written in and the standard its verdicts are evidence against. It is deny by default: an agent may do nothing its policy does not allow. Each primitive answers a question an auditor asks, and each verdict records which primitive answered it.
| Primitive | The question it answers | What Rinox enforces |
|---|---|---|
| Identify | Who acted, on which device, for which person? | Scoped identity per agent and sub-agent; device and user attribution on every record. |
| Constrain | Was this tool, with these arguments, permitted? | Deny-by-default allow rules with prefix, list, and pattern constraints on arguments. |
| Limit | Did the agent do more than a session should? | Calls-per-session and bytes-per-session caps per tool. |
| Sequence | Was this a dangerous chain of individually allowed steps? | Ordered chain denial with an optional time window. |
| Context | Was this action anomalous for this agent at the time? | Behavioral baseline per agent; escalation on anomaly. |
| Attest | Can every decision be proven after the fact? | Hash-chained ledger entry per verdict; verifiable, archivable, exportable. |
The governance block
Every IRON policy also states why it exists: a display name, the risk owner, a rationale in plain language, and the requirements it traces to (framework, clause or control id, title). That block is copied onto every decision recorded under the policy. An evidence record therefore cites the requirement it was enforcing and the person accountable for it, not only the rule that fired. A clause id that has not been confirmed is shown as pending rather than invented.
Evidence, not attestations
Every decision is recorded as it is made. Nothing is reconstructed later from someone else's logs.
What each record carries
- Timestamp
- The human actor, where the source reports one
- The agent, and the harness or client it ran in
- The device it ran on
- The attempted action and its arguments
- The decision, and the would-be decision under enforce
- The policy that fired, its version, and its risk owner
- The requirement the policy traces to
- The IRON primitive behind each reason
How it holds up
- Hash-chained: each record carries the hash of the one before it, so any edit breaks the chain.
- Verifiable from genesis, across live and archived records.
- Optionally anchored with a signature, so a full re-forge is detectable too.
- Exportable as CSV and JSON, and as a verifiable evidence package with a control crosswalk.
- Policy changes and administrative actions are recorded on their own chains.
- Retention and data residency are explicit configuration.
Framework context
Rinox maps its evidence to, and supports control objectives under, the frameworks a risk function is measured against. It does not certify anyone, and no policy makes an organization compliant.
ISO/IEC 42001
AI management system: evidence that AI usage controls exist, operate, and are reviewed.
NIST AI RMF
Govern, map, measure, manage: operating records for the measure and manage functions.
EU AI Act
Logging, human oversight, and traceability obligations for AI systems in scope.
UAE and Saudi regulators
NCA, SDAIA, and UAE AI policy expectations for controlled, auditable AI use, with in-region and air-gapped deployment.
Clause-level mappings are confirmed per engagement with your compliance team. Rinox produces technical evidence for a control; whether that control satisfies a specific clause is a judgement your auditor makes.
How it works
Five components. The agent talks to Rinox exactly as it would talk to the tool.
- 1
Endpoint agent
Enrolls a device with a tenant, pulls centrally authored and signed policy, and supervises the local enforcement point. Fails static offline; denies by default before its first policy.
- 2
Inline proxy
The enforcement point in the action path. Speaks MCP over stdio and HTTP, and plain HTTP for API tools. Normalizes each call to one action schema.
- 3
Decision point
Evaluates the action against the IRON policy and the agent's behavioral context. Returns the verdict and the reasons, tagged by primitive.
- 4
Ledger
Appends every decision to the hash-chained audit ledger before the call proceeds. Per tenant, verifiable, exportable.
- 5
Control plane
Where policy is authored, modes are switched, held actions are approved, over-permission is reviewed, and evidence is exported.
Shadow first, enforce when ready
Shadow mode forwards every call and records the would-be verdict, so you see what your agents do and what would have been stopped, with no blocking risk. When you trust the verdicts, switch the mode: warn, step-up, or enforce, globally or per policy. Fail behavior (open or closed) is explicit configuration, never an implicit default.
The agent never holds the key
Rinox holds the downstream credentials and issues the agent a scoped token. On an allowed action the proxy brokers the real credential at forward time. An agent that tries to route around the proxy has nothing to authenticate with. For a hard guarantee, network lockdown templates make Rinox the only route to the tools.
Deployment
Hosted, multi-tenant
Every record is tenant-scoped and isolation is enforced at the database layer by row-level security across the control plane, ledger, policies, and secrets. Tenant onboarding and clean offboarding are first-class operations.
Single-tenant
The same components on infrastructure you control: container images, a Helm chart, a hardened systemd unit, and a compose stack.
Air-gapped and on-premises
The decision point, policy store, ledger, and secret store run with no cloud dependency in the data path. An offline bundle installs and verifies with no network, for the regulated and in-region case.