TL;DR: Financial services firms are already deploying AI agents and MCP servers into production before governance catches up, creating audit, policy, and regulatory exposure, according to Stacklok. The core issue is that shared-service execution, shadow integrations, and runtime policy gaps break attributable identity and control assumptions before firms can scale safely.
At a glance
What this is: Stacklok argues that AI control plane governance for MCP deployments is lagging production adoption in financial services, leaving audit trails, policy enforcement, and discoverability exposed.
Why it matters: IAM, NHI, and agent governance teams need to treat AI control plane design as a compliance and attribution problem, not just an integration layer, because runtime identity and audit gaps become hard to retrofit once developers spread shadow deployments.
Context
AI control plane governance is the set of controls that decides how AI agents and MCP servers authenticate, which policies they must follow at runtime, and how their actions are attributed for audit and compliance. In financial services, that governance layer is becoming critical because regulated processes and customer data are being touched before the operating model is defined.
Stacklok says firms are seeing MCP servers and AI agents spread across teams, subsidiaries, and infrastructure models with little central visibility. The immediate problem is not only technical sprawl. It is that the firm cannot prove who acted, which policy applied, or whether the deployment path was approved before regulated activity began.
The article frames the buyer's guide as a way to narrow vendor evaluation around governance, runtime policy, observability, and deployment flexibility. For IAM and security leaders, the useful question is whether a control plane preserves attributable identity and enforceable policy across the environments where financial services actually operate.
Key questions
Q: What breaks when MCP governance is added after deployment?
A: Retrofitting control usually means unwinding over-broad credentials, rebuilding approval logic, and rediscovering where sensitive data can flow. By then, connector decisions are already embedded in operations, which makes remediation slower, more disruptive, and harder to evidence for auditors and counsel.
Q: Why do ungoverned AI control planes create regulatory risk in financial services?
A: Because the control plane sits between an AI action and a regulated business process. If it cannot prove who initiated the action, which policy applied, and whether the deployment path was approved, the firm may fail audit expectations under the FCA, SEC, or PRA and expose accountable leaders to personal scrutiny.
Q: How do security teams know whether AI traffic controls are actually working?
A: They should look for evidence that policy decisions are consistent across prompts, responses, and tool calls, and that every block, mask, or alert can be traced back to a specific interaction. If the team can only report request volume, then it is measuring transport, not control effectiveness.
Q: When should firms prioritise AI control plane governance over broader platform rollout?
A: Before production scale. If the firm already has regulated records, customer data, or multiple legal entities in scope, attribution and runtime policy have to come first because every week of delay increases the amount of shadow infrastructure that later has to be cleaned up.
Technical breakdown
Why identity passthrough is the hardest control plane requirement
Identity and audit passthrough means the downstream system sees the real user or agent behind a tool call, rather than a shared service principal. That sounds simple, but in MCP and agent workflows it requires token exchange, workload identity, and consistent propagation across every hop in the chain. Without that, the control plane can log activity but still fail attribution, which is a material difference in regulated environments. Shared accounts flatten accountability and make the audit trail look complete when it is not. For financial services, the problem is less about logging volume and more about whether the logged identity is legally and operationally meaningful.
Practical implication: enforce identity passthrough end to end so tool calls remain attributable to the originating user or agent.
Why runtime policy matters more than static approval
An AI control plane only governs behaviour if policy is evaluated at runtime, not just at deployment time. Static approvals break down when teams add new MCP servers, change tool bindings, or spin up new legal entities without revisiting the rule set. Declarative, version-controlled policy lets security and compliance teams change authorization logic without forcing redeployment, which is essential when the environment moves faster than release cycles. In financial services, policy lag is its own risk surface because shadow integrations often harden before anyone notices them. The control plane needs to be a live enforcement layer, not a configuration archive.
Practical implication: require runtime policy enforcement that can change without redeployment.
Why observability and discoverability are governance controls, not extras
Discoverability and observability are often treated as operational conveniences, but in this context they are governance controls. A curated registry reduces shadow IT by making the approved path easy to find, while SIEM-ready logs and OpenTelemetry traces make inspection possible after the fact. If developers route around the official path because it is slow or opaque, governance fails before a policy ever fires. For firms with multi-cloud, on-premises, and air-gapped environments, the control plane must expose the same activity model everywhere. Otherwise, the organisation gets fragmented evidence and fragmented accountability.
Practical implication: centralise the approved AI path and feed control plane telemetry into existing security monitoring.
Threat narrative
Attacker objective: The immediate objective is to use ungoverned AI and MCP access paths to execute actions in regulated environments without clear attribution or enforceable policy.
- Entry occurs when teams or individual developers stand up MCP servers because no policy blocks them, creating unofficial paths into regulated workflows. Credentialed access then lands in shared service accounts, which hides the initiating user or agent from downstream systems. Policy and visibility gaps allow shadow integrations to persist and multiply across business units and legal entities. Impact emerges as broken audit trails, regulatory exposure, and expensive retrofit work once the sprawl is embedded in developer workflows.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI control plane governance is now an identity governance problem, not just an infrastructure problem. When an MCP deployment touches customer data or regulated records, the main question is no longer whether the tooling works, but whether the firm can attribute action to the right user, agent, or workload. That moves the topic directly into IAM, NHI, and audit design. The practitioners who own identity need to treat the control plane as part of the access layer, not a separate orchestration concern.
Shared service accounts create auditability debt the moment they mask the origin of an action. A downstream data warehouse or regulated system that records only the service principal has lost the evidence needed for supervision, investigation, and accountability. That is not a logging shortfall alone. It is a governance failure because the organisation can no longer prove who initiated the activity or which policy was in force at the time.
Governed AI adoption will increasingly depend on runtime enforcement, not platform promises. The article’s sequencing advice is significant because firms do not buy a control plane in the abstract. They buy a way to contain a specific failure mode, whether that is audit passthrough, policy drift, or developer circumvention. The market is moving toward control planes that act like identity enforcement layers for AI execution paths, and procurement will need to reflect that shift.
Curated registries and developer-friendly defaults are now part of shadow AI containment. If the sanctioned path is harder than the unsanctioned one, developers will route around governance every time. That is the same behavioural pattern identity teams have seen for years with access request friction and unmanaged local admin workarounds. The implication is simple: discovery, usability, and policy need to be designed together.
Runtime policy without redeployment is becoming the dividing line between toy deployments and regulated operations. In financial services, the control plane must absorb change in the same cadence as business and regulatory requirements. If a firm cannot alter policy in place, it will accumulate exceptions, then compensating controls, then governance debt. Practitioners should evaluate AI control planes as living enforcement systems, not static gateways.
From our research library:
- 40 percent of financial and software companies have already deployed agentic AI systems, and deployments are expected to double by 2028.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Identity passthrough will become the gatekeeping control for regulated AI operations. Once AI agents are allowed to touch customer data or regulated records, the firm needs a way to preserve the original actor through every tool invocation. Without that, audit and accountability collapse into shared-account logging, which is too weak for supervisory review.
Shadow integrations are a lifecycle problem, not just a discovery problem. The article shows that once developers can stand up MCP servers independently, unmanaged paths harden quickly. Governance teams should treat onboarding, policy publication, and registry adoption as a single operating model rather than three separate tasks.
AI control plane governance will sit closer to IAM and NHI programme ownership than to pure platform engineering. The right evaluation question is whether the platform can enforce identity, policy, and observability together across the environments the firm actually runs, not whether it merely connects an agent to a tool.
For practitioners
- Implement identity passthrough for every tool call Require OAuth token exchange, workload identity, or equivalent propagation so downstream systems can see the originating user or agent instead of a shared service principal.
- Enforce runtime policy changes without redeployment Insist on declarative, version-controlled policies that can be updated centrally when legal entities, MCP servers, or approval rules change.
- Make the approved AI path the easiest path Use a curated registry, self-service onboarding, and automatic configuration so developers do not create shadow integrations outside governance.
- Send AI control plane telemetry into your SIEM Require audit logs and traces to export in formats your monitoring stack already consumes so reviews can be tied to existing detection and compliance workflows.
- Test vendor fit against your deployment reality Check that the platform works across multi-cloud Kubernetes, on-premises infrastructure, and air-gapped environments before you commit to the evaluation shortlist.
Key takeaways
- AI agents and MCP servers can enter production before governance catches up, which turns identity attribution and audit evidence into immediate control-plane concerns.
- The article shows that shadow integrations, shared accounts, and uneven policy enforcement can embed quickly across financial services organisations.
- Firms need runtime policy, identity passthrough, and SIEM-ready observability before broad AI scale is possible without governance debt.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on AI control plane abuse through shared identities and weak authorization boundaries. |
| Recommendation — Treat MCP governance as identity and privilege enforcement for agent actions and prevent shared-account attribution loss. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Identity passthrough and workload authentication are central to preventing shared-service attribution failures. |
| NHI-10 — Human Use of NHI | The article shows developers standing up MCP paths that blur who actually triggered regulated tool calls. | |
| Recommendation — Enforce authenticated identity propagation so downstream systems can bind actions to the originating actor. Prohibit shared credentials that hide the initiating human behind a service principal. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The buyer's guide is fundamentally about runtime authorization and attributable access decisions. |
| Recommendation — Map AI control-plane access to PR.AA-05 and require authorization at execution time. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Shadow integrations and shared principals create paths for credential reuse and movement across regulated systems. |
| Recommendation — Model MCP sprawl as credential access and lateral movement risk in your detection and response work. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article's core issue is cloud identity governance across multi-cloud and hybrid deployments. |
| Recommendation — Apply IAM domain controls to require attributable identity and centralized policy enforcement for AI workloads. | ||
Key terms
- Atlas Control Plane: The Atlas control plane is the administrative layer for managing MongoDB Atlas resources such as database users, IP access lists, and cluster settings. When exposed to AI agents, it expands risk beyond data access into infrastructure and identity changes. That makes prompt injection and overbroad permissions much more dangerous.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org