Not Just Governing Other MCP Servers - Governing Its Own
When Claude, ChatGPT or Slack pulls Fintra context over the Model Context Protocol, every call takes the same policy path as a human action: 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 you can verify().
Illustrative product view
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
- 1
Authenticate
The client completes OAuth 2.1 + PKCE; the call arrives with a scoped, short-lived token rather than a shared key.
- 2
Check
Tenancy and entitlement are verified per call - right tenant, licensed tool - before any context is returned.
- 3
Decide
A policy-decision-point mirror returns a verdict and an Action Trust Score, so the call carries a real decision object.
- 4
Record
The outcome is appended to a hash-chained TrustLedger; verify() walks the chain to prove nothing was altered.
- 5
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.
Frequently asked questions
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 going
Try the calculator
Stay in the loop
One practical finance briefing a week - new guides, checklists, and benchmarks.
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.
Talk to us