AI governance for people, systems and actions
AI governance,
from accountability
to evidence.
Manage AI systems, risks, controls, approvals and evidence. Rinox supports human oversight and enforces technical policies on supported agent action paths.
From intended use to reviewed evidence
Define the system
Purpose, owners and versioned scope
Make accountable decisions
Requirements, risks and independent review
Describe the control
Implementation, responsibility and evidence method
Review the evidence
Source, scope, result and validity
Recording a control does not prove it operates. Keep the decision and its supporting evidence distinct.
Start with the system.
Purpose, owners and versioned scope
- Purpose
- Customer support assistant
- Owner
- System owner
- Version
- 1.0
01Governance
Govern AI systems and the controls around them
Agents, models, chatbots and purchased AI services need accountable owners, risk decisions and review evidence. Human, organizational and contractual controls belong alongside technical policies.
Systems, risks and ownership
Register AI use cases and components, assign owners, record individual risks, and document treatment and acceptance decisions. Keep supplier facts and incident records available for review.
Controls and accountable review
Record technical, process, organizational and contractual controls with tests and evidence links. Agent lifecycle workflows support approvals, exceptions and attestations with named decision makers.
Runtime controls and evidence
On supported agent paths, Rinox evaluates actions against policy and records the decisions in a hash-chained ledger. Active enforcement can block or hold an action; shadow mode records what the policy would decide.
Available workflows and enabled features depend on the deployment. Qualified source content, Arabic review and customer acceptance remain explicit gates. Agree the exact system journey, evidence method and supported scope for each pilot.
02Evidence
Human review and runtime evidence
Attestations, control tests and runtime observations answer different governance questions. Keep their owners, collection methods, scope and review context visible. Runtime records establish what Rinox observed on its supported paths.
Runtime record context
- Timestamp
- The human actor, where the source reports one
- The agent, and the harness or client it ran in
- The device, where the integration supplies it
- The attempted action and its arguments
- The decision, and the would-be decision under enforce
- The policy reference and recorded version
- The risk owner and requirement references, when supplied
- The IRON primitive behind each reason
Integrity and interpretation
- Hash chains link recorded entries; trusted signed checkpoints help detect rewritten history.
- Chain verification requires the relevant live and archived records.
- Integrity checks do not establish unobserved activity, complete history or freshness by themselves.
- CSV, JSON and evidence packages support export and control mappings.
- Policy changes and administrative actions are recorded on their own chains.
- A shadow verdict is not a prevented action; an allow decision is not proof of execution success.
03Framework context
Framework context
Rinox includes reference mappings and control-authoring tools. Source editions, applicability, evidence requirements and review status must be established for the customer's scope. A catalog entry does not establish full framework coverage.
ISO/IEC 42001
Reference mappings for AI management system controls. Organizational responsibilities and human review remain part of the governance work.
NIST AI RMF
References for organizing AI risks, controls, monitoring and review evidence.
EU AI Act
References for risk management, logging and oversight. Applicability and control sufficiency require review for the specific system and role.
Saudi requirements
English and Arabic control authoring for Saudi sources, including PDPL, SDAIA and NCA references. Framework content and source versions require qualified review.
Qualified review of the selected requirements and evidence is part of each engagement. Saudi framework content remains unverified until that review is recorded. Rinox does not certify an organization or guarantee regulator or auditor acceptance.
04Runtime controls
What Rinox enforces at runtime
Technical controls apply to supported action paths connected to Rinox. The configured mode determines whether a verdict is observed or enforced. Human and organizational controls use accountable workflows and reviewed evidence.
01IdentifyScoped action identity
Actions on supported paths carry an agent identity and, where supplied by the integration, device and human attribution. Credential brokering lets an agent use a Rinox-scoped token while Rinox holds the downstream key.
02ConstrainDeny 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.
03LimitSession 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.
04SequenceDangerous chains are denied as chains
Policies can deny an observed sequence, such as reading a sensitive file followed by sending data externally, optionally within a time window. Sequence checks apply to the actions Rinox receives.
05ContextAnomalous 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.
06AttestRecorded decisions and approvals
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.
Supported endpoint profiles also provide path guards, sandboxed launch and executable controls. Available enforcement depends on the operating system, integration and setup. Activity outside those boundaries is not established by these records.
05Technical policy
IRON, the Rinox technical policy format
IRON defines permissions for supported agent actions. Policy evaluation denies unless an action is allowed; active enforcement applies that decision. The six primitives describe the decision and its reasons. IRON is one implementation of a technical control within the broader governance program.
Explore the six IRON primitives
| Primitive | The question it answers | What Rinox enforces |
|---|---|---|
| Identify | Which agent acted, and what attribution is available? | Scoped agent identity with device and human attribution where the source supplies it. |
| 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 recorded decisions be checked for integrity? | Hash-chained verdict records, signed checkpoints, archives and exports. |
The governance block
Policies can include a display name, risk owner, plain-language rationale and requirement references. That context is recorded with the policy decision when provided. A mapping records the intended relationship; its applicability and sufficiency still need review. Unconfirmed clause references remain pending.
06Supported action paths
How runtime enforcement works
Connect supported agent tools through the runtime components below. Registering a non-agent AI use case does not require installing the endpoint agent.
- 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 format.
- 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
Manage governance records, runtime policies, held-action approvals, reviews and evidence exports.
Shadow first, enforce when ready
Shadow mode records would-be policy verdicts without applying policy blocks. Transport, authentication and configured failure handling still apply. When ready, enable active enforcement globally or per policy. Fail behavior is explicit configuration. Always distinguish observed decisions from confirmed effects.
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.
07Deployment
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 can run locally without cloud dependencies in the data path. Offline packaging is available. Installation, evidence verification and residency need acceptance for the chosen deployment profile.
AI governance