
Adopting AI in a large fintech
Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank

Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank
Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank
Open clients, local models, and MCP differ
Open source ≠ local inference
Self-hosted ≠ safe actions
Internal MCP ≠ narrow privileges
External API ≠ a leak by default
Governability appears only with identity and technically enforced execution boundaries
These properties do not imply one another and must be assessed separately
Each axis has its own data path, cost, failure point, and lock-in
Docs confirm capabilities, not deployment security
Observed
Open clients: OpenCode and Codex
Codex supports custom providers
Claude has multiple delivery paths
Not implied
Local, open model
Equal tool use
Sufficient sandbox
The model gateway governs data routing; the tool gateway governs authority and effect
Architectural patterns with different trade-offs in control, speed, and operations
Not a ranking but eight combinations of the data path and the authority path
Two local modes
1 · Autonomous stack
Air gap and pinned versions
Full operational ownership
GPU, serving, evals, updates
3 · Client + local model
Ready-made UX and tool loop
Evals prove compatibility
The workstation remains the boundary
Frontier planning; authority stays inside
2 · Owned harness
Owned process and tools
Frontier quality without owned GPUs
A gateway filters secrets
7 · Planner + executor
Only a typed plan leaves
Credentials stay inside
Policy checks business invariants
Separate vendor UX from corporate authority
4 · Agent + internal gateway
Strong UX and current model
Capabilities stay internal
OBO, policy, trace at gateway
5 · Full SaaS
Shortest time to pilot
Tenant, connectors, retention
High control-plane lock-in
Routing needs evals; user stacks need boundaries
6 · Multi-model router
Price, quality, latency, region
Safe fallback by data class
Evals for every route
8 · User stack
Fast personal workflow
Shadow tokens, supply chain
Registry, scopes, test tenant
Properties depend on deployment context
Air gap requires configuration 1
A fast pilot points to 5
Enterprise actions point to 4
High risk points to 7
A threat model from user intent to the actual system change
Each boundary adds a leakage channel, confused deputy, or goal substitution
An issue, email, README, or log becomes another control channel
Label external data
Filter results and errors
Narrow subsequent capabilities
Test repeated attacks
The model proposes an action; permission to execute it is checked outside the model
Start with the allowed data path, then the cost of action and operational ownership
Three questions quickly narrow eight configurations to an admissible set
Choose the smallest configuration enforcing required boundaries
Pilot · 4 / 5 — One repo, read-only or PR
Enterprise platform · 4 → 6 — Gateway and evals first
Regulated environment · 1 / 7 — Fail closed, OBO, sandbox
Multiple clients and models can operate around owned model and tool gateways
Testing eight configurations against scale, risk, and installed platform capabilities
A local tool quickly becomes shared software-delivery infrastructure
10,000+ — Engineers — Thousands of repositories and stacks
55M+ — Customers — The blast radius keeps growing
regulated — Environment — Data, money, and 24/7
The model gateway, MCP/tool gateway, company context, and agent mode already define boundaries
Data, authority, resilience, and the supply chain must be governed together
Threat model, security policy, supplier trust, and human validation of high-risk automatic actions
Data and authority decide admissibility; operations and evidence decide fitness
Two become core, three stay specialized, one is the next stage, and two remain sandboxed
Fast adoption cannot offset opacity
5 · Full SaaS
Isolated low-risk pilot
Enterprise tenant, exported logs
Exit plan before connection
8 · Personal stack
Test tenant only
No work data or authority
MCP/version registry
Locality trades GPUs and operations for autonomy
1 · Autonomous stack
Real air gap
Complete operational control
Highest ownership cost
3 · Client + local model
Sensitive local code
Compatibility through evals
The workstation remains a boundary
External plan; internal executor verifies and applies
External planner
Allowed context only
A plan without credentials
Versioned schema
Internal executor
OBO and policy-as-code
Dry run and idempotency
Human validation for high risk
Strategic owned agents and managed mass-market UX converge on one corporate control plane
Routing follows data class, quality, price, and availability without changing policy through hidden fallback
Vendors, standards, regulation
OpenCode · Codex · Claude Code
GLM-5 · GigaChat API
MCP authorization · NIST · OWASP
Bank of Russia · personal data · bank secrecy
2 / 4 are the core paths
6 follows private evals
1 / 3 cover restricted environments
7 controls high-risk execution
5 is an isolated pilot, 8 a sandbox
Own the paths of data, authority, and verification