Product · Control layer
FinGuard
The action gateway
Agents fail in ordinary ways. A write is repeated after a timeout, a retry turns into a storm, a long job loses track of what it already did. Each one lands in a system of record. FinGuard sits between agents and your enterprise systems and decides whether each specific action should happen now. Agents never hold the real credentials. Every write is journaled, and a repeat returns the stored result instead of writing twice.
Illustrative: an agent sends a batch of 43 emails, then loses track after its context is compacted and sends the same request again. FinGuard recognises the repeat and returns the first result, so nothing is sent twice.
Where it sits
The action gateway of FinAI OS
FinGuard governs the action: the moment an agent's call becomes a change in a CRM, ERP, ticketing system or internal API. It fronts REST, SOAP, JSON-RPC and MCP, and deploys on its own with PostgreSQL. Other gateways decide whether a prompt is safe or whether a tool can be reached. FinGuard decides whether this exact write should happen now, and whether it already has. FinGuard and FinSAFE have no build dependency on each other: FinGuard governs the action, and FinSAFE contains the process that runs it. To make FinGuard the route for every action, it holds the credentials your systems accept, and FinSAFE's network allowlist can make FinGuard the only system an agent can reach. FinAI OS is designed to connect its server agents, desktop agents and skills to FinGuard directly.
Sold on its own or integrated with the other FinAI OS products.
Capabilities
What FinGuard does
Five controls between an agent and a system of record. They work with the agents you already run, without changes to agent code.
- 1
Exactly-once writes
An idempotency ledger records each write. A repeat with the same key gets the stored response back instead of a second write. An attempt that timed out is verified before it is retried.
- 2
Credentials agents never hold
The enterprise credential is rotated so that FinGuard is its only holder. Agents get a FinGuard-scoped identity, and FinGuard injects the real secret from your vault only when an action is allowed. An agent that goes around FinGuard has nothing the target system will accept.
- 3
Dry runs and human approval for high-risk actions
A high-risk action can be run as a dry run first, with risk checks, and held as a pending action until a person approves or rejects it through FinGuard's approval API. The agent can't approve its own request.
- 4
Retry budgets and circuit breaking
Each action has a retry budget, and a failing target system trips a circuit breaker, so one bad dependency can't turn an agent into a retry storm.
- 5
A tamper-evident audit trail
A hash-chained journal covers every allow and deny, and a built-in verify check shows whether anything in it was changed afterwards.
Standalone · better with
Useful alone. Stronger in the stack.
FinGuard is built to be deployed first, in front of the agents you already run. Policies and journals written for it keep working unchanged as other FinAI OS products are added.
FinGuard alone
FinGuard on its own: an action gateway for the agents you already run
- No other FinAI OS product required
- No change to agent code
- Fronts REST, SOAP, JSON-RPC and MCP
- Connects to your identity provider (OIDC JWT) and your vault
- Cloud-native containers, on-prem or in your private cloud, with just PostgreSQL alongside
Better with
Give FinGuard the credentials your systems accept, and the platform's agents have one route to them. The platform is designed to connect its agents and the skills they install to FinGuard directly.
FinDesk is designed so its local agents reach your enterprise systems through the same FinGuard gateway as server agents.
FinGuard decides whether an action should happen; FinSAFE contains how it runs. You can set FinSAFE's network allowlist so FinGuard is the only place an agent can reach.
In the wealth solution
FinGuard in Personal Wealth Agents
Scopes of action, licensed-advisor approval for out-of-policy actions, and a hash-chained audit trail. Suitability is judged by your own models and rules, not by FinGuard.
Client app and licensed advisor console shown on the solution page.
Deploy with FDE
Governed writes, one system at a time
Forward Deployed Engineers put FinGuard in front of your first protected system alongside your security and platform teams, and plan your exit from the first day.
Talk to FDE- Step 1
Assess
Put FinGuard in front of your first system of record, review what agents send in the audit trail, and replay policy changes against recorded traffic before you enforce them.
- Step 2
Ground
Connect your identity provider and vault, rotate the first service credential, and onboard the first system.
- Step 3
Hand over
Turn on approvals and policies, verify the audit trail, and hand over the runbook.
Next step
Let agents act on your systems of record, under your rules
Talk with a Forward Deployed Engineer about FinGuard on its own or as part of FinAI OS.