# Rinox

> Rinox is 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.

Site: https://rinox.io
Contact: support@rinox.io

## What Rinox is

Rinox is AI governance and risk software backed by runtime enforcement. It sits inline in the action path of an AI agent (an agent is any AI system that can call tools, read data, or trigger effects), evaluates each action against a deny-by-default policy before it happens, and returns one of four verdicts: allow, warn, step-up (hold for a human), or block. Every verdict is written to a hash-chained audit ledger as it is made, so the evidence of how AI usage was governed is produced by the control itself, not reconstructed after the fact.

The same engine runs in two postures. Shadow mode forwards every action and records the would-be verdict, so an organization can see what its agents do and what would have been stopped, with no blocking risk. Enforce mode makes the verdict take effect. The switch between them is configuration, global or per policy.

## Who it is for

- Chief information security officers and heads of AI risk who are asked what their AI agents are allowed to do, what they actually did, and what stopped them.
- Compliance, GRC, and internal audit teams who need evidence of AI usage controls operating, not a policy document that says they should.
- Platform and security engineering teams who have to make that evidence real without rewriting the agents.

## What Rinox enforces at runtime

Every governance claim Rinox makes points to a control that operates in the action path:

- Deny-by-default policy. An agent may do only what its policy allows. Everything else is blocked.
- Argument constraints. An allowed tool can still be refused on its arguments: a path prefix, an allowed host list, a pattern that denies destructive statements.
- Session limits. Per-tool caps on calls and bytes per session, so a runaway loop or a bulk pull stops even when each call is individually allowed.
- Sequence denial. An ordered chain of individually allowed steps (read a sensitive path, then post externally) is denied as a chain, optionally within a time window.
- Behavioral context escalation. An action that is anomalous for that agent (unusual tool, unusual transition, off-task) is escalated to warn, step-up, or block. Escalation only: a deny is never turned into an allow.
- Step-up approval. A held action waits for a named human to approve or deny it, and the decision is recorded with who made it.
- OS guard and sandbox. On managed devices, read-only paths are locked at the operating system and a governed agent can be launched under an OS sandbox that can write only where policy allows.
- Process governance. An AI application can be denied, sandboxed, or flagged by which executable it is, which covers desktop agents that speak neither MCP nor a hook.
- Credential brokering. The agent carries a Rinox-scoped token, never the raw downstream key. The real credential is supplied at forward time only for an allowed action.
- Hash-chained ledger. Every decision is appended to a tamper-evident chain that can be verified from genesis, archived, anchored, and exported.

## 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 and built from six primitives, each answering a question an auditor asks:

1. Identify. Who is this agent, on which device, for which human, and which sub-agent?
2. Constrain. Is this tool allowed, with these arguments?
3. Limit. Has this agent done too much this session?
4. Sequence. Is this a dangerous chain of individually allowed steps?
5. Context. Is this action anomalous for this agent right now?
6. Attest. Is every decision provable after the fact?

Every IRON policy also carries a governance block: a display name, a 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, so an evidence record cites the requirement it was enforcing, not just the rule that fired. Where a clause id has not been confirmed it is shown as pending rather than invented.

## The evidence Rinox produces

Every decision is recorded with: timestamp, the human actor where known, the agent and the harness or client it ran in, the device, the attempted action and its arguments, the decision and the would-be decision, the policy that fired and its version, the IRON primitive that produced each reason, the requirement the policy traces to, and the risk owner. Records are hash-chained and exportable as CSV and JSON, and a verifiable evidence package with a control crosswalk can be produced on demand. Policy changes and administrative actions are recorded on separate hash-chained audit chains.

## Framework context

Rinox maps its evidence to, and supports control objectives under, ISO/IEC 42001, the NIST AI Risk Management Framework, and the EU AI Act, as well as the UAE and Saudi regulatory context (NCA, SDAIA, and UAE AI policy). It also produces technical evidence relevant to SOC 2, ISO/IEC 27001, NIST SP 800-53, HIPAA, PCI DSS, SOX, and GDPR control objectives. Rinox does not certify anyone and no policy makes an organization compliant. Clause-level mappings are confirmed per engagement.

## Deployment

- Hosted, multi-tenant. Every record is tenant-scoped and isolation is enforced at the database layer by row-level security.
- Single-tenant. The same components on infrastructure the customer controls.
- Air-gapped and on-premises. The decision point, policy store, ledger, and secret store all run with no cloud dependency in the data path, from an offline bundle.

Agents connect by a configuration change (point the MCP client at the Rinox proxy) or through the endpoint agent, which enrolls a device with a tenant, pulls centrally authored and signed policy, supervises the local enforcement point, and ships the local ledger to the tenant chain. Forced topology (network lockdown so Rinox is the only route to the tools) is available when configuration alone is not enough.

## Contact

support@rinox.io