Where Agentic AI Controls Actually Run: FINOS AIGF v2.0 and the Service-Mesh Control Plane

I want to make an architectural argument that I deliberately didn’t make in last week’s piece on the joint-agency GenAI-from-MRM carve-out, because the regulatory point and the engineering point are easier to read separately. Here is the engineering follow-up.

The premise is short. Three separate regulators have, in the last six months, named specific controls they expect firms to have in place around agentic AI:

FINRA in the December 2025 AROR named four consideration areas: monitoring agent access and data handling, defining human-in-the-loop oversight, tracking and logging agent actions, and implementing guardrails to constrain agent behaviour.
The PRA’s SS1/23 Principle 1 requires firms to define the model boundary, including the components around the model — exactly the surface area agentic systems extend.
EIOPA’s August 2025 Opinion, paragraph 3.35, requires resilience against adversarial inputs and data poisoning for insurance AI within its scope (i.e. non-prohibited, non-high-risk under the AI Act).

Different jurisdictions, different sectors, three different documents. They want roughly the same things: identity, isolation, observability, policy enforcement, and durable evidence of all of it.

The question almost nobody on FS LinkedIn is asking is where those controls actually run in production. The default answer the industry has reached for is “in the agent” — wrap the LLM with a Python guardrail layer, hand-roll some prompt-level restrictions, log to the application’s own observability stack. That answer doesn’t scale, and more importantly it doesn’t satisfy any of the three regulatory expectations consistently. It satisfies them inside one application boundary, while leaving the supply-chain, tool-chain, and multi-agent boundaries that FINOS AIGF v2.0 named explicitly more or less unguarded.

The argument I want to make is that those controls belong at the control-plane layer, not in the agent — and that the FINOS AI Governance Framework v2.0 risks and mitigations describe, almost in parallel, what the service-mesh community has been building for microservices for ten years.

What FINOS AIGF v2.0 added

Some background, in case you don’t follow this closely. FINOS — the Fintech Open Source Foundation — publishes an AI Governance Framework consisting of a risk catalogue and a mitigation catalogue, designed for the financial-services use case. Version 2.0, published November 2025, added six agentic-specific risks (ri-24 through ri-29) and six matching mitigations (mi-18 through mi-23) to the existing framework. Each risk is mapped to OWASP LLM Top 10, NIST AI RMF, MITRE ATLAS, and ISO 42001 controls where applicable; each mitigation is mapped to NIST SP 800-53r5 controls.

The three new risks that carry the architectural argument I want to make are:

ri-26: MCP Server Supply Chain Compromise. The Model Context Protocol — the open standard for letting LLMs reach external tools and data sources — creates a new dependency surface. Agents typically rely on multiple MCP servers, often operated by third parties, for things like market data, regulatory information, KYC verification, or internal business logic. A compromised MCP server can systematically influence agent decision-making in real time, across many transactions, in a way that traditional supply-chain attacks targeting static dependencies cannot.

ri-25: Tool Chain Manipulation and Injection. This is the evolution of prompt injection that practitioners haven’t fully internalised. Traditional prompt injection manipulates text output. Tool chain manipulation targets the agent’s decision about which tool to call, with what parameters, in what sequence. The output is a payment, a database write, a customer notification — not just a misleading paragraph. The attack surface is the agent’s tool-selection logic, which sits between the LLM and the API layer, and which most teams have not yet treated as security-critical.

ri-28: Multi-Agent Trust Boundary Violations. When firms deploy multiple agents that coordinate — a customer-service agent that hands off to a risk-assessment agent that queries a compliance agent — the trust boundary between agents matters in ways the single-agent threat model didn’t have to consider. A compromise in a low-privilege agent can propagate to higher-privilege agents through shared communication channels, shared context, or contaminated state. The framework’s term is cascading compromise; in operational terms, blast radius gets bigger fast.

The other three new risks (ri-24 Agent Action Authorization Bypass, ri-27 Agent State Persistence Poisoning, ri-29 Agent-Mediated Credential Discovery and Harvesting) are real and worth a separate post, but the three above are the ones whose mitigations describe the architectural pattern most directly.

The mitigations all describe the same control point

If you read mi-19, mi-20, and mi-22 alongside each other, what jumps out is that they don’t describe three different controls. They describe one architectural pattern applied to three risks.

mi-20: MCP Server Security Governance asks for supply-chain verification, secure communication channels, data integrity validation, and continuous monitoring of MCP servers. In implementation terms, that means mutual TLS or OAuth 2.1 + PKCE between the agent and any MCP server it consumes, signed and verified MCP server identities, request and response inspection, and observability of every server-side interaction. None of this is something the LLM or the application code does well. All of it is something a sidecar proxy or a per-request policy decision point does naturally.

mi-19: Tool Chain Validation and Sanitization asks for validation of tool selection decisions, sanitization of API parameters, and safe sequencing of tool calls. In implementation terms, that means a policy engine that sees every tool call before it leaves the agent boundary, evaluates it against the firm’s authorised tool catalogue and parameter schemas, and either allows or denies — with an audit log either way. Again, this is not a thing the LLM should be trusted to enforce on itself; it’s a request-path concern, and it belongs at the proxy.

mi-22: Multi-Agent Isolation and Segmentation asks for security boundaries between agents that prevent cross-agent compromise, limit blast radius, and maintain trust boundaries. In implementation terms, that means agent-to-agent communication runs over identity-aware channels with explicit allow-policies, not over shared queues or implicit trust; that workloads are segmented at the network layer; and that one agent’s compromise terminates at its boundary rather than leaking through into the next one.

Three different framework risks. One control architecture. Identity at every hop, policy at every request, segmentation at every boundary, observability of all of it.

What the service-mesh community has been doing

The pattern above is service mesh. It is, almost line for line, what mTLS, SPIFFE/SPIRE, Envoy proxy filters, and OPA-style policy decisions have been doing for microservices since around 2018. The vocabulary is different — “MCP server” rather than “downstream service”, “tool call” rather than “RPC”, “agent” rather than “workload” — but the topology, the threat model, and the control surface are recognisably the same.

In a service mesh, every workload has a strong cryptographic identity, every connection between workloads is authenticated and encrypted by default, every request is subject to a policy decision at the proxy, and every interaction is observable. The control plane is where you configure those decisions; the data plane is where they’re enforced. Application code does not need to be aware of any of it. That is, deliberately, the design point.

Apply the same model to agents:

The agent has an identity. So does every MCP server. So does every tool. mTLS or OAuth 2.1 + PKCE between them, mediated by the proxy, gets you mi-20 by construction.
Every tool invocation passes through a policy decision at the proxy. The proxy consults the firm’s authorised tool catalogue, the agent’s privilege scope, and any contextual restrictions. That is mi-19, and crucially it is also FINRA’s “guardrails to constrain or restrict AI agent behaviors, actions or decisions” — running in a place where it is enforceable, observable, and testable.
Inter-agent communication goes through the same mesh, with explicit allow-policies between agent identities and no implicit trust. That is mi-22, and it also satisfies SS1/23 Principle 1’s requirement that the model boundary be defined and bounded.
Every request and response is captured with a structured trace, including the agent identity, the tool called, the parameters, the policy decision, and the outcome. That is FINRA’s “tracking and logging AI agent actions and decisions”, it is 17a-3/4 evidence, and it is the artefact a model validator looks at to assess outcome consistency under SS1/23 Principle 4.

Notice what we did not have to do. We did not have to invent a separate AI-specific policy framework. We did not have to put the regulatory burden inside each agent’s prompt or inside the LLM provider’s vendor-managed guardrails. We did not have to choose between FINRA-compliance, PRA-compliance, and EIOPA-compliance; the same architectural layer satisfies all three because they’re asking for the same five primitives.

What this looks like in practice

Here’s a very compressed worked example so you can see what I’m getting at.

A bank deploys a customer-service agent that can answer balance enquiries, initiate transfers below a certain threshold, and hand off complex requests to a human associated person. The agent uses three MCP servers: a customer-record server (internal), a market-data server (third-party vendor), and a regulatory-text server (third-party, less critical). The agent also coordinates with a risk-assessment agent for transfer authorisation.

The control-plane configuration looks roughly like this. Every component — agent, MCP servers, risk-assessment agent — has a SPIFFE identity. Mutual TLS is required between any two of them. The agent’s identity is permitted to call the customer-record MCP server only with a specific OAuth scope tied to the authenticated user’s session; the proxy enforces this regardless of what the agent’s prompt says it can do. Tool invocations against the transfer API are subject to a policy that checks the notional value, the customer’s profile, and the time of day; above the threshold, the policy returns a “human approval required” decision and the proxy holds the call until the human associated person approves. Inter-agent communication between the customer-service agent and the risk-assessment agent runs over a dedicated channel with its own policy; the risk agent cannot be reached by any other agent without explicit allow.

If the third-party regulatory-text MCP server is compromised, the blast radius is bounded by the proxy’s policy on what the agent is allowed to do with information from that server. If a tool-chain manipulation attempt slips through the LLM, the proxy’s tool-call policy denies the unauthorised parameters before they reach the API. If the risk-assessment agent is compromised, segmentation contains the failure to that workload’s blast radius.

None of this requires the application code to know about regulators. None of it requires the LLM to enforce its own controls. All of it produces durable, signed evidence of every decision — which is, ultimately, what a regulator asks for under any of the three regimes.

The convergence signal

The Linux Foundation’s Agentic AI Foundation, formed in December 2025, anchors MCP, the Goose runtime, and AGENTS.md as founding contributions, with Google’s A2A protocol running as a sibling LF project. More than 150 organisations now back the A2A standard, and FS firms including Bloomberg have publicly cited MCP as foundational to their agentic AI plans. That is not a coincidence. The agentic ecosystem is converging on the same primitives the cloud-native ecosystem converged on years ago, because the threat model and the operational requirements are similar enough that the architectural answer is similar.

For FS firms specifically, the implication is concrete. The investment you have made (or, depending on the firm, are still making) in service-mesh infrastructure for microservices is not a separate budget line from your AI governance investment. It is the substrate on which agentic-AI controls run. Treating them as separate programmes is one of the more expensive mistakes I see firms about to make.

Disclosure and the shape of the argument

I work at Tetrate, which contributed the agentic reference architecture to FINOS AIGF v2.0. That disclosure matters, and I want to be precise about what it implies.

It implies that I have seen the inside of how this pattern gets implemented at financial-services firms running real agent workloads, and I am not making the argument from first principles in a vacuum. It does not imply that the argument depends on Tetrate’s specific commercial product. The architectural pattern is open standards (mTLS, SPIFFE, Envoy, OPA, MCP, OAuth 2.1) implementable by any service-mesh stack — Tetrate’s, Istio’s open-source distribution, Linkerd, Consul Connect, or a bespoke build. If the post above is read as a vendor pitch I have written it badly, because the point is the architecture, not the vendor.

If your firm is making agentic-AI architecture decisions in 2026 and FINRA’s four agentic considerations, SS1/23 Principle 1, or EIOPA paragraph 3.35 are on your list of things to satisfy, the control-plane layer is where most of the work lives. Skipping that layer and trying to do it all inside the agent is the failure mode I expect to see most of in the next eighteen months.

If you’re working on agentic-AI architecture at an FS firm and trying to map the FINRA / SS1/23 / EIOPA expectations onto a workable engineering plan, I’d be interested to compare notes. You can find me on LinkedIn or email paul@paulmerrison.io.