We do not assume the AI means well.

OS iXanagi is built around three parties. The principal is a person — the owner of the business. The agent is the AI. The instrument is OS iXanagi. The AI is there to be useful to its principal's business: it researches, summarizes and proposes. Deciding what to adopt and what to carry out always stays with a person.

No company gives a new hire it knows nothing about the keys to every room. It has them sign a fixed set of written pledges. In OS iXanagi, what an AI can do is limited to a registered list of operations. Each operation has a defined input shape and a declared kind of action — read, write internally, send, publish, move money, delete, and so on. Who the AI acts as, and whose company data it acts on, comes from the person who is signed in — not from anything the AI writes. The AI cannot expand its own permissions by claiming them.

This governs the AI's hands, not what goes on inside its head. That is why the same limits apply to a well-meaning model, a malicious one and a hijacked one alike.

Everything the AI sends out traces back to a person's approval. But if every single action needed its own sign-off, approving would become the job, people would start clicking through without checking, and quality would fall.

So approval comes in two forms. The first is approval in the moment. When the AI is about to do something that leaves the system — sending, publishing, moving money, deleting — and it is outside what has been delegated, it always asks a person to confirm before it runs. That approval covers that one action with that exact content, and it cannot be reused. The second is delegating within limits. When a person delegates a workflow, an automation or a chat a scope of actions, a budget and a time limit, the work inside that scope runs without item-by-item approval. It stops if it would go beyond the scope, the budget or the time limit, and it stops if the workflow itself changes until it is delegated again — much like handing someone a written operating procedure and trusting them with it. And issuing keys — passwords or API keys — is never left to the AI.

In short: outward actions from a chat (sending, publishing, moving money, deleting) and starting a stored flow (a workflow or an automation) always pass through your approval. The AI cannot create a standing automation on its own; only a person creates and enables one.

What the AI produces is a proposal — a piece of data. Once it is approved, the actual processing is done not by the AI but by code that follows a fixed procedure (the Runtime). The same input gives the same result, and you can trace afterward exactly what happened. The AI does not change what the processing does on a whim.

We record who asked, what the AI proposed, who approved it and what was executed. Records are added to, never overwritten. And the system does not make calls it cannot take responsibility for — legal, tax or rights questions, for example. What it shows instead is how the facts fit together, the points at issue, and a record of who made the decision.

OS iXanagi is not built around any one AI model. Calls to AI go through set connection points, and the model sits behind them as a replaceable part. You can also run it with your own vendor key.

Knowledge, decisions, and records live in your company's database, not inside a model. The meaning calculations used for search (embeddings) also run inside the OS iXanagi environment. So when you change models, what you have built does not move. The governance in Principles 1–5 is set by structure, not by the model, so it stays in place too.

One thing to know: when AI is asked to think, the content is sent to the provider of the model you chose. Where your data goes is decided by that choice. If you have conditions on where it may go — staying in your country, for example — the starting point is choosing a model that meets them. How a provider handles what it receives is governed by that provider's terms.

• Mistakes the AI makes within what it is allowed to do. Inside the operations it is permitted, an AI can still write something plausible and wrong. Structure alone cannot prevent that. That is why operations that go out need approval or a delegation, and when articles are generated, statements without grounding are marked "unverified".
• People approving without reading. An approval only means something if it is read. Delegation, which cuts the number of approvals, is also there to keep item-by-item approvals at a volume people can actually read.
• Delegating too broadly. Inside the scope and budget you delegated, nothing stops item by item. We recommend narrowing what you delegate — the actions, who it sends to, the budget and the time limit.
• Misuse by the person who holds the permissions. The AI acts with the permissions of the person who is signed in. Governing the AI cannot stop that person from misusing permissions they hold. Role-based permissions and the record help cover this.
• The quality of the AI's proposals itself. What the structure guarantees is what can be done — not whether a proposal is right.