Trust and security
A smaller thing to trust.
IVAI OS is designed so that a mistaken or manipulated model does not become a mistaken outcome. This page sets out where authority sits, how people stay in control, and how data is intended to be handled.
§ 01
The model is a component, not the system.
A model receives context and returns a proposal. Whether that proposal is permitted, and whether it is carried out, are decided elsewhere.
This changes the threat model usefully. A confused or manipulated model produces a proposal that still has to satisfy policy, permission, scope and limits before anything happens — and after it happens, the result is confirmed from the application's own records by something that did not perform the action.
Content encountered in an interface is treated as untrusted input rather than instruction. The design goal is specific and testable: injected content should be able to stop the system, and should not be able to make it act.
Two design rules
A model proposes; it does not execute.
A model does not confirm its own result.
Least privilege by construction
A workflow is intended to act under a scoped identity holding only the permissions that workflow needs, with permission checked at the moment of action rather than only at the start. Credentials are held outside the model boundary.
§ 02
People stay in control.
Oversight that never blocks anything is not oversight. The controls below are intended to remain meaningful in daily use, not only on paper.
- Authority is human
- Sensitive actions are designed to require an approval bound to a person with the standing to give it, covering a specific scope and set of values, and valid for a limited time.
- Reasons are traceable
- The justification presented for review is tied to the rule that produced the proposal, rather than to text generated alongside it.
- Override is always available
- A supervisor can decline a proposal, reverse a decision, intervene, or stop the workflow entirely.
- Approval behaviour is monitored
- Approval rate and review time are treated as safety indicators. A queue approaching total approval means the control has stopped working.
- Escalation is agreed in advance
- Which cases reach a person, who that person is, and what they may decide, are settled before a workflow runs rather than improvised during an exception.
§ 03
Limits and stop controls.
Judging each action in isolation is not enough — a sequence of individually reasonable actions can still add up to an unacceptable outcome.
Operational limits
Configured per workflow, per customer and per period. Examples:
- Maximum actions in a given period.
- Maximum cumulative financial value.
- Maximum number of affected end customers.
- Maximum consecutive failures before suspension.
- Automatic suspension when behaviour shifts unexpectedly.
Stop mechanisms
- A stop control available at all times.
- Automatic suspension when a limit is crossed.
- Pause at the level of a single workflow or an entire tenant.
- A defined recovery plan agreed before a workflow goes live.
- A named escalation path with named roles.
§ 04
Data and evidence.
Collected narrowly
The intent is to keep only what establishes the inputs, the decision, the authority, the action and the confirmed result — not everything the system observed.
Sensitive values removed early
Sensitive categories are designed to be removed before a record is written, rather than cleaned up afterwards.
Separated per customer
Records for one organisation are intended to be isolated from another's, with separate keys, separate permissions and independent retention.
Access is not implied by operation
Running a workflow, reviewing its decisions, opening records, exporting them and deleting them are designed as separate permissions.
Retention is bounded
Set against purpose, applicable law and the engagement, with secure destruction at the end of the retention period.
Deployment location is contractual
Where a deployment runs and where its data is held are settled in the engagement agreement, in line with the customer's own regulatory position.
§ 05
Responsible use of AI.
IVAI OS is not a model. Its responsible-AI position is therefore about something narrower and more checkable: where authority sits, and who is accountable for a result.
Accountability stays with people. Authority is exercised by someone with the standing to exercise it, escalation paths are agreed in advance, and responsibility for the process, the policy, the systems and the exceptions is allocated in writing before a workflow operates.
Confidence is treated as something to be measured against real outcomes rather than taken from a model's own score, and a model version is treated as part of an approved configuration rather than something that changes quietly.
Alignment, stated precisely
The design is informed by published national AI ethics principles and data protection requirements. Alignment with a framework is not the same as assessment against it, and IVAI OS does not describe itself as certified.
§ 06
This website.
- No JavaScript is served, and there are no cookies or browser storage.
- No analytics scripts, tag managers, advertising pixels or embedded third-party content.
- Every asset is served from this domain.
- No forms and no server-side application.
- A strict content security policy and a full set of security response headers.
Reporting a security issue
Reports about this website are welcome at admin@ivaios.com.