AI control plane governance gaps in financial services firms

At a glance

What this is: Stacklok argues that financial services firms need an AI control plane because AI agents and MCP deployments are already creating governance and audit gaps in production.

Why it matters: For IAM, IGA, PAM, and security teams, the issue is whether agent and workload identity can be attributed, constrained, and audited well enough to satisfy regulated operations at scale.

By the numbers:

• One insurance conglomerate with 146 subsidiaries found MCP deployments spreading across business units with no policy in place.
• A cybersecurity firm with roughly 8,000 employees discovered distributed teams building agents independently, with almost no cross-team visibility.

👉 Read Stacklok's buyer's guide for AI control plane governance in financial services

Context

AI control plane governance is the layer that determines whether agent actions can be attributed, constrained, and audited across production systems. In financial services, that matters because AI agents and MCP servers are reaching regulated data and workflows before policy, logging, and approval boundaries are in place.

The operational gap is not just technical sprawl. When tool calls are logged against a shared service account instead of the initiating user or agent, the audit trail breaks, and the regulatory problem becomes immediate for IAM, IGA, PAM, and control owners.

For teams evaluating MCP deployments, the question is no longer whether agents will spread. It is whether identity passthrough, runtime policy enforcement, and observability are strong enough to keep distributed experimentation from becoming unmanaged production risk.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do shared service accounts create audit problems for AI control planes?

A: Shared service accounts collapse the link between action and actor. In regulated environments, that breaks segregation of duties, makes investigations slower, and weakens evidence for compliance reviews. The practical test is simple: if an auditor cannot tell which human or agent triggered the tool call, the control plane is not governance-ready.

Q: What do security teams get wrong about discoverability for MCP deployments?

A: They often treat discoverability as a catalogue problem instead of an adoption problem. A registry only helps if it is easier to use than the shadow path. Security teams need frictionless onboarding, automatic configuration, and clear ownership so the sanctioned route becomes the default operating model.

Q: Who is accountable when an AI agent accesses regulated data improperly?

A: Accountability sits with the teams that govern the agent's identity, the data classification, and the policy that allowed the access path. If those controls are disconnected, no single owner can explain why the access existed or why it was not removed sooner. Shared context is what makes accountability traceable.

Technical breakdown

Why identity passthrough is the hardest control plane problem

Identity passthrough means downstream systems can see who or what triggered a tool call instead of only seeing a shared service principal. In MCP and agentic workflows, that usually requires token exchange, workload identity, and an audit path that survives hops across tools and services. Without it, attribution collapses at the exact moment investigators need to answer who acted, under what authority, and against which data. This is not just a logging issue. It is the identity boundary that determines whether an AI control plane can support regulated operations.

Practical implication: require per-user or per-agent identity propagation before approving production MCP use.

How runtime policy enforcement differs from static approvals

Static approval lists do not scale when agents and servers are created across multiple business units, environments, and legal entities. A usable control plane needs declarative policy that is version-controlled and enforced at runtime, so access decisions follow the workload as it changes. That matters because redeployment-based governance creates delay, and delay is where shadow integrations harden. Runtime enforcement is the difference between policy as documentation and policy as an operational control.

Practical implication: validate that policy changes can take effect without redeployment or manual code changes.

Why observability and discoverability determine governance quality

Discoverability tells you what exists. Observability tells you what those agents and MCP servers actually did. In financial services, both matter because a hidden server is already a governance failure, while a visible server without telemetry is still an audit risk. The article’s emphasis on SIEM-ready logs, OpenTelemetry-native traces, and a curated registry reflects a basic truth: if developers can route around the sanctioned path, governance loses before it starts.

Practical implication: make the governed path easier than the shadow path and require telemetry exports into existing monitoring.

NHI Mgmt Group analysis

AI control plane sprawl is an identity governance problem before it is a platform problem. The article shows that teams can deploy MCP servers and agents faster than policy can catch up, especially across subsidiaries and distributed development groups. That creates a governance gap in ownership, auditability, and enforcement that sits squarely inside IAM and IGA scope, not outside it. The practitioner conclusion is that platform selection only matters after the firm defines who is accountable for every agent action.

Identity passthrough is the control plane’s most important trust boundary. Downstream systems that only see a shared service account cannot support attribution, segregation of duties, or defensible audit trails. In regulated environments, that failure is more than operational inconvenience because it obscures which human or agent initiated the action. The practitioner conclusion is that any AI control plane without end-to-end identity propagation is structurally incomplete.

Runtime policy without redeployment is a governance requirement, not a convenience feature. The guide correctly treats policy enforcement at scale as a runtime problem because static controls cannot keep pace with distributed agent creation. That aligns with NIST Cybersecurity Framework 2.0 expectations for enforceable access control and continuous oversight. The practitioner conclusion is that policy drift in agent infrastructure should be handled as control failure, not backlog.

Curated discoverability is what prevents shadow AI from becoming the default operating model. Developers route around painful controls, so the sanctioned path has to be easier than the unsanctioned one. The named concept here is identity control plane drift: the point at which agent deployment, identity attribution, and policy enforcement no longer move together. The practitioner conclusion is that governance teams must measure whether the approved path actually wins adoption.

Financial services will increasingly judge AI governance by evidentiary quality, not architecture diagrams. The article points toward a market where usage telemetry, per-team attribution, and SIEM-ready logging become board-level proof points. That shifts the identity programme from theoretical readiness to provable control. The practitioner conclusion is that control planes must produce evidence the first time an auditor asks for it.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why the OWASP Top 10 for Agentic Applications 2026 remains a useful next step for teams formalising runtime agent governance.

What this signals

Identity control plane drift: financial services teams should expect AI governance to fail first at attribution, then at enforcement, and only later at scale. Once developers build around the sanctioned path, the firm is managing exceptions rather than programmes, and exceptions are where regulated evidence breaks down.

The practical response is to align control plane design with existing assurance workflows, especially where NIST Cybersecurity Framework 2.0 and audit expectations already shape identity controls. If the firm cannot answer who acted, what policy applied, and where the log landed, the deployment is not ready for regulated data.

Use this moment to connect agent governance to broader identity architecture, including the Ultimate Guide to NHIs , Regulatory and Audit Perspectives and the operational patterns in OWASP Agentic AI Top 10. The near-term programme question is whether your current identity stack can produce evidence at the same speed that developers can create agents.

For practitioners

• Map identity passthrough end to end Verify that every MCP tool call can be traced back to the initiating user or agent rather than a shared service principal. Test token exchange, workload identity, and log correlation across the full request path.
• Require runtime policy enforcement Reject designs that depend on redeployment for policy changes. Confirm that access rules, tenancy boundaries, and tool permissions can be updated centrally and enforced immediately at execution time.
• Instrument the sanctioned path first Build the curated registry, self-service onboarding, and telemetry export path so developers use the governed route by default. Send logs and traces into your SIEM and observability stack in formats your auditors can query.
• Treat shadow integrations as an assurance issue Inventory MCP servers and agent workflows across business units, then reconcile them against policy, ownership, and legal-entity boundaries. Where teams have built independently, require explicit accountability before production use.
• Sequence vendor review by your strongest constraint If auditability is the blocker, start with identity passthrough and SIEM-ready export. If developer adoption is the blocker, test whether the governed path is easier than the unsanctioned one before evaluating advanced features.

Key takeaways

• Financial services AI control planes fail when identity attribution, runtime policy, and audit logging are treated as separate problems.
• The article’s evidence shows that distributed agent creation and shared-service execution quickly turn into regulatory exposure.
• Practitioners should evaluate control planes by evidentiary quality, not by feature lists or deployment claims.

Key terms

• AI Trust Control Plane: An AI trust control plane is the enforcement layer that converts governance intent into runtime decisions for identity, data, and model access. It sits between policy and execution, using context such as task, entitlement, and environment to approve, constrain, or revoke access as the system operates.
• Identity Passthrough: Identity passthrough preserves the originating user or agent identity as a request moves through tools and backend systems. It prevents everything from collapsing into a shared service account and gives security teams the traceability they need for audit, investigation, and least-privilege enforcement.
• Shadow Integration: A shadow integration is an undocumented or unmanaged connection between applications that operates outside central governance. These integrations often appear when business teams configure webhooks directly, leaving security teams without clear ownership, data-flow visibility, or retirement controls.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• A six-section capability checklist for identity, governance, runtime security, observability, developer experience, and commercial considerations.
• Specific requirements such as OAuth token exchange, SPIFFE/SPIRE workload identity, per-server container isolation, and OpenTelemetry-native tracing.
• A sequencing guide that maps the biggest concern, such as audit readiness or developer adoption, to the right evaluation starting point.
• Market guidance on where lightweight gateways, developer-tooling platforms, and cloud provider offerings fall short in financial services.

👉 Stacklok's full guide includes the capability checklist, sequencing logic, and market gaps for regulated deployments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.