Fintra Feature
Not just governing other MCP servers: governing its own
Fintra MCP, Per-Call Governance
Example figures- AUTH
- OAuth 2.1 + PKCE
- per session
- VERDICT
- PDP-mirror
- + Action Trust Score
- LEDGER
- hash-chained
- verify() ✓
- Tool call: post_journal_entry
- tenancy ✓ entitlement ✓
- Action Trust Score
- 0.86: allow
- real_pep mode: blocked write
- draft withheld
- TrustLedger entry hash-chained
- verify() ok
- Providers: sandbox by default
- live is opt-in
Governs the server it ships, not only the ones you connect
Plenty of tools promise to govern the MCP servers you connect to. Fintra also governs the one it ships. Context served to an AI client is an action, so it is treated like one (checked, scored, and recorded) rather than an open read that trusts whoever holds the token.
- OAuth 2.1 with PKCE on the session: a scoped, short-lived token, not a long-lived shared secret in the client
- A per-call tenancy check (is this token valid in this tenant?) and an entitlement check (is this tool licensed for this seat?)
- A PDP-mirror verdict and an Action Trust Score attached to the call: the same decision object a human action receives
- A hash-chained TrustLedger entry with a verify() that walks the chain and detects tampering
What happens on every call
The per-call policy path
Authenticate
The client completes OAuth 2.1 + PKCE; the call arrives with a scoped, short-lived token rather than a shared key.
Check
Tenancy and entitlement are verified per call (right tenant, licensed tool) before any context is returned.
Decide
A policy-decision-point mirror returns a verdict and an Action Trust Score, so the call carries a real decision object.
Record
The outcome is appended to a hash-chained TrustLedger; verify() walks the chain to prove nothing was altered.
Enforce
In real_pep mode a deny actually blocks the call and withholds the write draft: an enforcement point, not just an observer.
Enforcement modes and the honest default
That default is on purpose. A context server that could silently execute writes against production the moment it was installed would be the opposite of governed. real_pep is something you turn on knowingly, after you have watched the verdicts run in sandbox.
Questions people ask
Does Fintra govern its own MCP server or only others?
Both, but the differentiator is its own. Every call into Fintra’s MCP context server passes OAuth 2.1 + PKCE, a per-call tenancy and entitlement check, a PDP-mirror verdict with an Action Trust Score, and a hash-chained TrustLedger entry: the same policy path a human action takes.
What does real_pep mode do?
It turns the server into a real policy-enforcement point: a deny verdict actually blocks the call and withholds the write draft instead of merely logging it. In the default sandbox mode the checks run but providers are faked, so you can watch verdicts before enforcing them.
Is the TrustLedger durable?
Not yet: it is an in-process, hash-chained ledger with a verify() that detects tampering, but it is not persisted to a durable database, so it resets on restart. The chaining and verification are real; durable storage is a known next step we state plainly.
How is authentication handled?
With OAuth 2.1 and PKCE on the session, so the client authenticates with a scoped, short-lived token rather than a long-lived shared secret, and every subsequent tool call is checked for tenancy and entitlement individually.
What is an Action Trust Score on an MCP call?
The same decision object Fintra attaches to human actions: a scored verdict from a policy-decision-point mirror that says how much to trust this specific call given who is asking, in which tenant, for which tool: recorded in the TrustLedger.
Keep reading
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
See the security depth, not the slideware
Walk the SOC engine, the governed MCP server, and the control graph live, with the honest caveats on the table, not hidden.