Podlodka AI Engineers Club · August 4, 2026
Adopting AI in a large fintech
Choosing an agent stack by data, authority, risk, and platform maturity. Alexander Polomodov · T-Bank
/ Podlodka AI · Agent stack for 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
An open client, a local model, and an internal MCP answer different questions
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
Documentation confirms capabilities, not the security of a particular deployment
What we can actually observe
OpenCode and Codex are open clients
Codex supports custom providers
Claude is available through several paths
What does not follow
The model is local and open
Tool use is identical across endpoints
The sandbox is enabled and sufficient
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 different points on the data and authority axes
Maximum control and a quick local start are two different operating 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
Authority can remain inside even when a frontier model performs the planning
2 · Owned harness + API
Owned process and tool layer
Frontier quality without owned GPUs
A gateway filters secrets
7 · Planner + executor
Only a typed plan leaves the perimeter
Credentials stay inside
Policy checks business invariants
Separate the vendor client from corporate authority — or delegate the entire stack
4 · Agent + internal gateway
Strong UX and a current model
Capabilities belong to the company
OBO, policy, and trace at the gateway
5 · Full SaaS
Shortest time to pilot
Tenant, connectors, retention
High control-plane lock-in
Routing needs mature evals; a user-built stack needs corporate boundaries
6 · Multi-model router
Price, quality, latency, region
Safe fallback by data class
Evals for every route
8 · User agent + SaaS/MCP
Fast personal workflow
Shadow tokens and supply chain
Registry, scopes, test tenant
The same property changes with scale, contract, model, and team maturity
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 that enforces the required boundaries — not maximum autonomy
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 specialised, one is the next stage, and two remain sandboxed
Fast adoption cannot offset an opaque path of data, tokens, and upgrades
5 · Full SaaS
Isolated low-risk pilot
Enterprise tenant and log export
Exit plan before connection
8 · Personal stack
Test tenant only
No work data or authority
Registry for MCP and versions
Locality buys autonomy at the cost of GPUs, compatibility, upgrades, and on-call operations
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
An external model proposes a typed plan; an internal executor verifies and applies it
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
2 / 4 are the core paths
6 follows private evals
1 / 3 close restricted contours
7 controls high-risk execution
5 / 8 stay sandboxed
Own the paths of data, authority, and verification