Governing AI Across Engineering and Customer Operations at a Global Fintech
The Starting Position
Most AI governance programs are built around a single risk model. Either the primary concern is customer-facing staff pasting sensitive data into consumer AI tools, or it’s developers using AI coding assistants with access to proprietary systems and source code. Both are legitimate concerns. Organizations that operate at scale across both functions tend to find that tools designed for one surface leave the other largely unaddressed.
This mobile payments business sits clearly in that position. It provides financial services to customers across multiple markets, including populations with limited access to traditional banking infrastructure. It processes transactions, manages accounts, and provides customer support for a user base where the underlying data carries genuine personal and financial sensitivity. Two distinct workforce populations interact with AI tools in materially different ways: the customer support teams who handle live account and transaction data, and the engineering teams who build and maintain the systems those customers depend on.
The security team's existing controls, web filtering and basic data loss prevention, had been designed for neither use case at the prompt level. Before the proof of value, the team's honest assessment was that they did not know what was actually happening.
Two Risk Surfaces, Two Threat Models
Understanding why a single-surface governance approach falls short here requires looking at what each group actually does with AI.
Customer support agents handle queries about account balances, transaction disputes, identity verification status, and in some cases KYC documentation that customers have submitted. When those agents use AI tools to help draft responses, summarize account histories, or navigate complex cases, the prompts they write contain real customer data: names, account identifiers, transaction details, and in some cases sensitive personal information shared during onboarding. The risk is clear: this data reaching a platform without appropriate data handling agreements, particularly one operating under terms that permit model training on user inputs.
Engineers work with a different category of sensitive material. Source code, internal API structures, infrastructure configurations, system architecture, and the proprietary logic of the payment platform all flow through development workflows. Developers using AI coding assistants in the browser and in their integrated development environments regularly work with this material in context. The risk is equally clear: proprietary technical IP being submitted to external AI tools with no visibility or control over what happens to that information.
Neither of these risk surfaces was visible to the web filtering layer in place. Both were significant.
What Two Weeks Revealed
Harmonic was deployed via browser extension for the broader workforce and, for the engineering team, via the MCP Gateway to cover agentic AI workflows and AI integrations in development tooling. The combination was designed to give complete coverage across both surfaces within the proof of value window.
The customer support findings confirmed the team’s hypothesis. Sensitive customer data (personal and financial information drawn from live account contexts) appeared in AI prompts across multiple platforms. A meaningful portion of that usage was occurring on tools without the data processing agreements that a payments business operating in regulated markets requires. Some of it was on personal account tiers of platforms where the organization held enterprise licenses, removing the contractual protections the enterprise tier provides.
The engineering findings revealed a different but equally material picture. Source code fragments, internal system identifiers, infrastructure-related content, and proprietary technical descriptions appeared in AI prompts and in the context sent to AI tools through MCP connections. The MCP Gateway surfaced interactions with tools and data sources that no browser-based control would have reached. These were agentic workflows (AI systems with active access to internal resources) operating entirely outside the existing visibility perimeter.
Customer PII and financial data detected across support team AI usage on multiple platforms
Source code and internal system content detected in engineering AI workflows and MCP connections
Over 70% of AI tools in active use operating without enterprise data protection agreements
Why Browser Coverage Alone Was Not Sufficient
For the customer support population, browser-based monitoring was the right tool. The risk was in what agents were typing into browser-based AI interfaces, and that is exactly what browser extension monitoring captures.
For the engineering population, the picture was different. Developers in 2025 and 2026 increasingly work with AI through mechanisms that a browser extension cannot see: IDE-integrated coding assistants that communicate with AI models directly, MCP clients that connect local development environments to external AI systems, and agentic workflows that combine multiple tools and data sources. These interactions do not pass through the browser in any form that a browser extension intercepts.
The MCP Gateway addresses this directly. It operates as the control point for agentic AI connections, providing visibility into which tools and servers are being accessed, what data is flowing through those connections, and the ability to apply policy controls at the point where the AI agent interacts with internal systems. In the engineering environment at this organization, it surfaced a category of AI activity that had been entirely invisible.
Comprehensive Governance in Practice
The decision to deploy both the Harmonic browser extension and the MCP gateway was driven by the proof of value findings. Each addressed a distinct surface; together they covered the full risk profile the deployment had uncovered.
For customer operations, controls were calibrated to the specific data categories most prevalent in the findings: payment account information, transaction data, identity verification content, and personal financial details. Interventions were deployed as user-facing guidance for most categories: staff are shown in real time when a prompt contains data that should not reach the platform they are using, with suggestions for how to accomplish the same task without including identifying information. For the highest-sensitivity categories, harder controls were applied at the platform level.
For engineering, the MCP Gateway established a clear perimeter around agentic AI connections. A defined set of approved external AI tools and MCP servers was specified; connections outside that set were blocked. For approved connections, prompt-level monitoring gave the security team visibility into what was flowing through developer AI workflows, with policy controls applied to the content categories of highest concern: source code, internal system identifiers, and infrastructure configuration.
The two deployments share a single management interface, giving the security team a unified view of AI usage across both populations. The alerts, policies, and reporting that had previously covered neither surface now covered both.
The Outcome
Within the two-week proof of value, the security team moved from a position of assumed risk to a documented one. They now had a specific account of which tools were in use, which data categories were being submitted, and what the gap between the existing control framework and the actual risk profile looked like. Both surfaces had been measured. Both were now governed.
For a payments business operating in markets where customers have placed their financial lives in the organization's hands, governing what happens to their data inside AI tools is not a future-state concern. It is a current obligation.
To find out more or discuss how this could apply to your organization, visit harmonic.security or get in touch with the team directly.
