The Agent Proposes a Posting and Cannot Make One

• Client. Mid-size commercial bank, ~1.8M transactions per month across card, ACH, wire, real-time rails, and nostro/vostro accounts
• The blocker. Not accuracy. Permission. No prior vendor could say what an autonomous agent could and could not touch.
• What CreateOS built. A six-agent reconciliation crew whose posting authority is constrained in the kernel, below the model
• Unauthorized postings. Zero, and structurally impossible rather than merely absent
• Segregation of duties. Preserved. No agent both decides and executes above threshold.
• Audit coverage. 100% of matches, exceptions, and postings, logged with rationale and replayable
• Certification. SOC 2 Type II and ISO 27001

This pattern is routinely misdiagnosed as a technology problem. Every vendor that came through the door could demonstrate an agent investigating a break and proposing a resolution, and several did it well. The models were not the issue. The demos worked. Then the deck reached the second line of defence.

• The question was what it can touch, not what it should. Not what the policy says. What can it touch if it is wrong, if it is manipulated, if it does something nobody anticipated on a Tuesday at 2am with no human watching.
• Every vendor answered with a statement about intent. The agent is instructed to post only through approved paths. It has guardrails. It has a system prompt. It is monitored and anomalies are flagged.
• Internal audit does not buy intent, it buys constraint. Which is why every one of those answers ended the conversation rather than advancing it.
• The stakes are categorically different here. An agent that summarises a document badly produces a bad summary. An agent with write access to the general ledger and initiation rights on payment rails misstates the books if it is wrong, and moves money if it is compromised.
• Reconciliation ingests untrusted files continuously. Counterparty statements, rail settlement files, correspondent bank reports, arriving from parties the bank does not control into a system with authority to post.
• The CISO reached the obvious conclusion. Ledger write access plus a continuous feed of untrusted external documents is an extraordinarily attractive target. One successfully injected instruction inside a counterparty statement, and the agent's own credentials do the work.
• So the projects died and the function stayed manual. For another year, with 126 analysts still on exception duty.

CreateOS answered the question, and we answered it in the only place the answer is worth anything.

Not in the prompt. Not in the application layer. In the kernel.

• Egress is allowlisted in the kernel. The resolution agent can reach the sanctioned ledger endpoint and the sanctioned payment paths. That is the entire list. It cannot reach anything else, not because it was instructed not to, but because from inside that micro-VM the rest of the network does not exist.
• This inverts the usual posture for AI safety. Conventional agent safety puts the constraint above the model, in instructions the model reads and is expected to honour. Every prompt-injection attack ever written attacks that assumption, because instructions a model reads are instructions an attacker can write.
• The constraint sits below the model. The agent cannot read it, reason about it, be persuaded to circumvent it, or even perceive it. A fully compromised agent actively trying to post a fraudulent adjustment fails, not because it is caught, but because the packet has nowhere to go.
• Per-VM kernel isolation on untrusted files. Every run and investigation executes in its own guest kernel, so a malicious counterparty file is contained to a disposable machine destroyed when the investigation completes. The worst-case blast radius is one exception.
• The kill path is the VM lifecycle. A misbehaving agent is not asked to stop. It is suspended instantly at the hypervisor.
• Deterministic matching, structurally separated from reasoning. We refused, against some client curiosity about improving the match rate, to let probabilistic reasoning near the match itself. A guessed match is a misstated book. Judgment is confined to investigating and explaining exceptions.
• Segregation of duties enforced by architecture. The agent that investigates a break is not the agent that posts the resolution, and postings above threshold route to a named human who signs. The same separation a bank demands between analyst and approver, as an architectural property rather than a procedural one.

Reproducibility as a control.

One configured reconciliation environment, templated, running every cycle identically. Consistency is auditable. Drift is not. A process that behaves slightly differently each month is a process an auditor cannot rely on, regardless of how good its output looks.

Full self-hosting.

Control plane and storage inside the bank's own region and boundary. Ledger and payment data never leave. The reconciliation process remains the bank's to control, inspect, and audit.

Complete, replayable audit trail.

Every match, every exception, every investigation, every posting, logged with its rationale as it happens. Not a summary. The chain. An external auditor can replay any decision the system made and see why it made it.

CreateOS is SOC 2 Type II and ISO 27001 certified. The information security review was a process rather than a fight.

Internal audit did not accept the architecture on description. They asked us to walk three scenarios. We include them here because they are the conversation that actually closed this deal.

Scenario one: the agent is simply wrong.

The investigation agent misreads a break and proposes an incorrect adjustment. This is not exotic. It will happen, and any vendor claiming otherwise is not worth listening to.

Outcome: if the adjustment is within the bank's threshold, it posts, and it is logged with its full rationale and is caught in reconciliation review exactly as a junior analyst's error would be. If it is above threshold, it never posts at all. It routes to a human who sees the agent's reasoning and rejects it. The system is wrong at the same rate a human is wrong, with a better paper trail, and the financial exposure is bounded by the threshold the controller sets.

Scenario two: a counterparty file carries an injected instruction.

An attacker embeds instructions in a settlement file, attempting to talk the investigation agent into posting an adjustment to an account they control.

Outcome: the agent may well be persuaded. We do not claim the model is un-manipulable, because nobody can credibly claim that. It does not matter. The posting attempt is made through the resolution agent, which can reach the sanctioned ledger paths and nothing else. The attacker's account is not on the allowlist. The packet has no route. The attempt fails at the kernel, is logged, and the agent is suspended.

This is the scenario that sold the CISO, and it is the one that separates us from every vendor whose safety story is a system prompt. Their answer to prompt injection is "the model will not fall for it." Ours is "it does not matter if it does."

Scenario three: the agent is fully compromised and is attempting to exfiltrate ledger data.

Worst case. Assume total control of the agent process.

Outcome: the compromised agent sits inside a Firecracker micro-VM with its own guest kernel and an egress allowlist containing the bank's own sanctioned internal endpoints. There is no path to the internet. There is no path to any system not on the list. The data cannot leave, because the network required to carry it out does not exist from where the agent is standing. The VM is destroyed.

The honest summary we gave internal audit: we cannot promise you the agent will always be right, and we will not insult you by trying. We can promise you that when it is wrong, it cannot hurt you outside a boundary you set.

That promise, they told us, was the first one they had been offered that was actually falsifiable.

Zero unauthorized postings. Not none observed to date. Structurally unavailable, and that distinction is the entire product.

• The information security review passed. After three years of projects dying at exactly this gate, the second line approved an autonomous system with ledger write access, because for the first time the constraint on that access was demonstrable rather than asserted.
• Segregation of duties preserved intact. The controller keeps threshold-setting and sign-off, internal audit keeps inspectability, and neither had to be traded away to get automation.
• 100% audit coverage, replayable. The external auditor can reconstruct any decision the system made. In a regulated close the audit trail is the deliverable, not a byproduct, and we built it as one.
• Everything downstream became possible. The $6.0M to $8.0M off operational cost, the close from eight days to two, the $4.8M of leakage surfaced on the bank's own books: none of it was available until this was solved.
• The value was never gated on model capability. It is gated on permission to act, and permission to act is an infrastructure property. Three years of failed projects had proven the agents were never the missing piece.

Not because they are careless. Because they do not own the layer where the promise lives.

The great majority of agent companies own the prompts and rent the runtime. Their agents execute on infrastructure belonging to a cloud provider, under a shared-responsibility model, with network controls configured at the application or the VPC layer, above the workload rather than beneath it. They can constrain their agents to the extent their landlord's abstractions allow, and no further.

We own both. The agents and the substrate they run on. That is why we can allowlist egress in the kernel rather than in a config file, isolate per-VM at the hypervisor rather than per-container, and put the constraint underneath the model where the model cannot reach it.

The uncomfortable truth for this category: a security guarantee is only as strong as the lowest layer you control. Most agent vendors do not control a low enough layer to make one that a bank's second line will accept, and no amount of prompt engineering closes that gap.

It is not a better answer to the question. It is the only place the question can actually be answered.

Phase 0, weeks 1 to 2. Baseline and control mapping. Alongside the operational baseline, we map the bank's existing financial controls, sign-off thresholds, and segregation-of-duties requirements, and agree the egress allowlist with information security. The allowlist is a joint artifact, not something we hand over.

Phase 1, weeks 2 to 6. Build and integrate. Stand up the agent crew, integrate to the general ledger, payment rails, and reconciliation tooling along allowlisted paths, encode the matching rules and control thresholds, deploy self-hosted inside the boundary.

Phase 2, weeks 6 to 9. Shadow run. The agents investigate real exceptions and post nothing. Internal audit inspects the decision log against the human team's work. The control architecture is tested before it is trusted.

Phase 3, weeks 9 onward. Controlled go-live. Automated posting enabled first for the lowest-risk within-threshold exception types. Everything above threshold to a human. Full audit logging on. Scope expands as the audit record builds confidence, on internal audit's timeline rather than ours.

Success criteria, agreed up front: zero unauthorized postings, 100% audit coverage of every automated decision, segregation of duties preserved, reconciliation accuracy at or above the current process, and an information security review closed on the architecture rather than on assurances.