A Hallucinated Answer Is the Bank's Official Position

The objection was never that the technology did not work. A customer-facing agent in banking is a different category of risk: an onboarding agent processes a document, a monitoring agent flags a transaction, but a conversational agent speaks in the bank's voice and can act on the account. Three exposures follow, and the risk function could articulate all three.

• A hallucinated answer is the bank's official position. Ask whether a fee applies and the customer reasonably treats the reply as the bank's word. That is unfair-and-deceptive-practices exposure, and it does not matter that a model produced it.
• A session that crosses wires leaks a customer's data. In a shared-runtime chatbot, isolation between two conversations is a property of the application code. Application code has bugs. The control the risk function wanted was structural.
• An action outside policy moves real money. This is the one that ended both prior evaluations.
• Every vendor answered the same way. The agent is instructed not to, the prompt constrains it, the model is fine-tuned, there is a policy layer. Every one of those is a request made of a model, not a control.
• An agent asked nicely is an agent that can still do it. A jailbroken, manipulated, or simply confused agent that is asked not to execute an unauthorized transfer is an agent that can execute one.
• The answer does not live in the prompt. Every vendor in the market owns the conversation and rents the runtime, so none of them could answer the question. It lives in the layer underneath, which they did not control.

CreateOS owns both. We build the agents and we own the infrastructure they run on, which is what let us convert each of the risk function's three exposures from a request made of a model into a control enforced by the machine.

• Unauthorized action: impossible in the kernel. The only agent permitted to touch core banking runs with egress allowlisted in the kernel. It reaches the sanctioned core-banking APIs the bank approved and nothing else. There is no path to any other system, so a hallucinating or manipulated agent cannot execute an unauthorized transfer. Not told not to. Cannot.
• Cross-customer leakage: impossible by construction. Every session runs in its own micro-VM with its own guest kernel, destroyed when the conversation ends. The isolation is a property of the hardware boundary, not of the application code above it.
• Hallucination: designed out by separation of duties. The answering agent works strictly from the bank's grounded content and cannot act. The acting agent cannot compose an answer. Compromising one does not compose into a compromise of the bank.
• Irreversible actions carry a second gate. Explicit customer confirmation, and where the bank chooses, a named human.
• The kill switch is the VM lifecycle. A misbehaving agent or problematic intent is suspended instantly, with no waiting for a deployment.
• Everything is written as it happens. Every interaction, answer, and action goes to the audit log, serving as both the compliance record and the bank's dispute defence.
• Proven in the order the risk function asked for. Read-only on real traffic first, so grounded accuracy and session isolation were demonstrated before the agent could move a dollar. Transactional intents followed one at a time, each egress-gated and confirmation-gated.

The control plane and storage run inside the bank's own infrastructure and region, so conversation content never leaves the boundary. CreateOS is SOC 2 Type II and ISO 27001 certified, which mattered because card and payment intents were in scope from the start.

The programme went live, which is the outcome that matters and the one a dashboard will not show.

• Zero unauthorized actions. Not zero observed. Zero possible, because the path does not exist.
• Zero cross-customer data leakage. A structural property of the deployment, not a metric the bank has to watch.
• Grounded answers only, 100% logged and replayable. No ungrounded generation on factual account or product questions, which removes the unfair-and-deceptive-practices exposure at its source rather than monitoring for it afterwards.
• $7.5M to $10M a year that had been worth nothing twice. Containment 30% to 60%, deflecting 1.5 million contacts a year, with handle time on assisted contacts down 20%. The case existed before CreateOS and the risk function could veto it, and did.
• Safety is the gate the cost case passes through. Not a feature alongside it. In a customer-facing banking deployment the buyer who can say no is not the one who wants the savings, so answering the CRO's question is what unlocked the CFO's.

What the risk function signed off on