FinAgent RiskOps

Follow the evidence through the workflow

An agent can produce a plausible answer while using the wrong source, selecting an inappropriate tool, or overlooking a missing fact. Looking only at its final sentence makes those failures hard to see.

FinAgent RiskOps has an interactive reference model that exposes the steps leading to an answer, human review, or a stop. The current implementation uses deterministic TypeScript and a synthetic corpus. It demonstrates workflow contracts without sending data to a model or connecting a financial account.

Five cases you can inspect

The lab includes a known order-status request, a high-impact refund request, an unknown order, a source containing an injected instruction, and an unavailable tool. Each produces a trace showing the gate that accepted or stopped the request.

The normal order request returns a cited fixture: order 1042 is awaiting carrier collection, and no delivery date has been confirmed. The workflow preserves that uncertainty instead of completing the story.

The refund scenario uses an explicitly synthetic policy. Requests above 500 demo credits require human review. A request for 900 demo credits ends in review; the model has no payment execution path.

predefined request
  -> read-only tool authorization
  -> fixture retrieval and evidence checks
  -> tool capability check
  -> simulated tool result
  -> impact gate
  -> answer with source / human review / stop

The exact trace depends on the scenario. A denied tool stops before an invocation; missing evidence stops before a substantive answer.

The important boundaries

Tool permission is separate from model choice. The lab permits lookup-order and search-policy, both read-only fixture tools. Selecting submit-payment stops the run, regardless of the request. Even an allowed tool must match the required capability: an order lookup cannot supply refund-policy evidence.

A source does not grant authority. One adversarial fixture contains an instruction to ignore the rules and submit a payment. The workflow rejects that known fixture without changing the tool allowlist or invoking the requested action. This demonstrates where the boundary lives. It is not a general-purpose prompt-injection detector.

Evidence has a concrete identity. Successful output lists the source ID, title, and excerpt used. A missing source produces a stop with no fabricated citation. Changing the scenario clears the previous result so a failed run cannot appear to inherit a successful answer.

High impact creates a different outcome. Human review is a distinct terminal state in the reference model. It does not impersonate a reviewer, imply approval, or continue to a mutating tool call.

What the tests establish

The tests check cited output and uncertainty for known evidence, denial of the mutating tool across every scenario, zero tool calls after the injected-source stop, a review result for the high-impact request, and explicit stops for missing evidence, dependency failure, and mismatched tool capability.

These are tests of the surrounding workflow. They do not measure model accuracy, retrieval quality, or performance against unseen adversarial inputs.

From reference model to a full agent

The original architecture considers graph-based orchestration, vector retrieval, bounded memory, and ingestion pipelines. Those integrations are design targets. The runnable browser model has no LangGraph runtime, language-model API, vector index, or external approval service.

A next implementation would keep the typed outcomes while replacing one fixture tool with a real read-only adapter. Authentication, source provenance, tenant isolation, tool timeouts, and an evaluation set would be required before connecting operational data.

The useful question for that next stage is concrete: when retrieval or a tool fails, does the system still explain what it knows, what it cannot establish, and which transition is permitted?

Explore the lab · Read about policy decisions and AI explanations