America's cybersecurity agency left its production credentials sitting in a public GitHub repo for six months. The same failure pattern is now being automated by AI agents in every enterprise running Cursor, Claude Desktop, or Copilot.
A contractor working for the U.S. Cybersecurity and Infrastructure Security Agency maintained a public GitHub repository called "Private-CISA" from November 2025 until last weekend. Inside: 844 MB of internal CISA and DHS material, including administrative credentials to three AWS GovCloud accounts, plaintext usernames and passwords for dozens of internal systems, JFrog Artifactory tokens, Azure registry keys, Kubernetes manifests, Terraform infrastructure code, and a file plainly titled "importantAWStokens." The commit history shows the contractor documented workarounds for GitHub's secret scanning push protection so the commits would go through.
The leak was discovered by a third party. CISA only learned about it when a researcher escalated through a journalist after the account owner ignored automated alerts. After takedown, the exposed AWS keys remained valid for another 48 hours.
This is a story about a contractor, a public repo, and a credential rotation failure. It is also a preview of the data security problem that is about to be everywhere: sensitive corporate context flowing through unsanctioned channels, invisible to legacy DLP, recoverable only after someone external notices.
What actually happened
Security researcher Guillaume Valadon of GitGuardian found the repository on May 14, 2026, when his company's automated scanning flagged it. After the account owner failed to respond to alerts, Valadon escalated to KrebsOnSecurity, which contacted CISA directly. The repo went offline within roughly 26 hours of public escalation.
"A national agency having 844 MB of production infrastructure material in a public GitHub repository for six months is as serious as a secrets leak gets. Indeed, the worst leak that I've witnessed in my career."
— Guillaume Valadon, GitGuardian (previously nine years at ANSSI, France's national cybersecurity agency)
Researchers analyzing the repository believe the contractor was using GitHub to synchronize files between a work laptop and a personal computer. The committer used both a CISA-issued contractor email and a personal Yahoo email on the same commits, working out of a personal GitHub account. That mixed-identity pattern, where corporate work touches personal infrastructure through an off-platform channel, is one of the hardest surfaces for a security team to monitor. Nothing about it traverses an inspection point that traditional DLP sits on.
The pattern legacy DLP was never built to catch
Strip the federal-agency drama out of the story and what is left is a pattern enterprise security teams should recognize immediately. The failure has three structural components that recur across nearly every modern data exfiltration incident:
- An unsanctioned channel that does not traverse a corporate inspection point.
- Contextually sensitive data that has no regex signature.
- No audit trail that records what left the building.
The data that leaked was not credit card numbers or social security numbers. It was infrastructure secrets, source code, build pipeline configuration, and the operational knowledge of how a security agency develops and ships software. None of that has a regex signature. All of it is sensitive because of context.
Legacy DLP was built for a world where sensitive data had structure: a 16-digit number followed by an expiration date, a nine-digit SSN, a known database export. It is reasonably good at that world. It is functionally blind to the data that defines competitive advantage and operational integrity: unreleased product roadmaps, M&A diligence, board materials, customer lists synthesized across systems, proprietary source code, infrastructure secrets in config files. None of it has a signature. All of it is sensitive because of what it is, not what it looks like.
The CISA contractor moved exactly this kind of data through exactly this kind of unsanctioned channel. Push protection, which would have caught the secrets, was bypassed by documented workarounds in the commit history. The official audit trail had nothing to flag because nothing the contractor did happened on a corporate inspection surface. The breach was discovered by an outside scanner watching the public internet.
This is the failure mode. And it is already being automated.
Why MCP turns this pattern into an enterprise-wide problem
Anthropic introduced the Model Context Protocol (MCP) in late 2024 as an open standard for connecting AI models to external systems. It has since been adopted by OpenAI, Google, and Microsoft, and was donated to the Linux Foundation in December 2025. Thousands of MCP servers are now tracked across public registries. Developers can add an MCP connection to Cursor, Claude Desktop, VS Code, or Windsurf with a single line of configuration. There is no default security review, no approval workflow, and no inspection of what flows through the connection.
The three structural components from the CISA incident map directly onto every MCP-connected agent.
The unsanctioned channel. The CISA contractor used a personal GitHub repo. The MCP-connected agent uses a developer-installed MCP server. Neither traverses a corporate inspection point.
The contextually sensitive data. The contractor synced AWS keys, build configs, and internal docs. The agent reads source code, customer records, and internal docs across every connected system. Neither has a regex signature.
The missing audit trail. The contractor left no corporate trail because the activity bypassed inspection points. The agent leaves no attributed trail because most logging systems cannot distinguish agent actions from the human acting on their behalf.
The detection window. The contractor took six months to surface, and only via an external scanner. The agent operates at machine speed, compressing detection windows to seconds or minutes.
The risk is not hypothetical. In June 2025, Asana disclosed that a logic flaw in its newly launched MCP server exposed project metadata, task data, and files across tenant boundaries for roughly a month, affecting approximately 1,000 customer organizations. The bug broke tenant isolation inside the integration layer itself, exactly the kind of failure that becomes catastrophic when one MCP server is the front door to data from every connected system.
In September 2025, Noma Security disclosed ForcedLeak (CVSS 9.4), a vulnerability chain in Salesforce Agentforce that allowed external attackers to plant malicious instructions in a Web-to-Lead form. When an employee later interacted with the lead through the agent, the hidden instructions executed, exfiltrating CRM data to an attacker-controlled domain. Agentforce is not MCP, but the attack class (poisoned content reaching a privileged agent that then acts on it through trusted channels) is exactly what every MCP-connected agent is structurally exposed to. No traditional DLP would have flagged a CRM agent doing a CRM lookup.
The full structural argument is laid out in What Is MCP Security? 9 Things Every CISO Needs to Know. The short version: MCP security is fundamentally a data security problem, not a protocol problem, and the existing stack has a structural blind spot for it.
What MCP observability requires
Gating MCP is not a viable strategy. Every major AI provider supports it, every productivity initiative in the business depends on it, and trying to firewall it at the proxy is directly at odds with the productivity gains the business is funding. The job is to govern MCP, not to block it. MCP observability is the discipline that makes governance possible, and it requires four capabilities working together.
Continuous discovery. Inventory every MCP server connected to corporate systems, including those running locally on developer machines. Assume the number is larger than the security team estimates. Map the connector surface for each server so the data each one can reach is known before the next incident, not after.
Real-time content inspection at the protocol level. Every MCP tool call carries a request (method, parameters, and the LLM context that triggered it) and a response. Each is an inspection point. Classification has to handle context-dependent sensitivity, including a Q4 forecast, an unreleased product spec, or source code with embedded secrets — not just pattern matches. This is the layer where the CISA-style leak gets caught: an agent attempting to retrieve credentials from a config file is a known control point, not an after-the-fact discovery.
Policy that understands corporate IP, not just regulated data. PII, PHI, and PCI detection are table stakes. The data that ranks highest on the breach-cost ledger is unstructured: product designs, M&A materials, customer lists, proprietary code, infrastructure secrets. Policy enforcement needs to understand all of it as content, not as patterns.
Agent-attributed audit logging. Every tool call logged with timestamp, user, agent, MCP server, data classification, and action taken. When the auditor or regulator asks what happened, the answer is reconstructable in minutes, not weeks. This is the layer that lets security demonstrate control to the board, the customer, and the compliance team, in that order.
What to do next
Three priorities translate the four capabilities above into action before the next board meeting.
Discover what already exists. Inventory every MCP server connected to corporate systems, including those running locally on developer machines. Most security teams discover MCP servers through Slack confessions. That is not a strategy.
Instrument the data layer. Get visibility into what is flowing through MCP tool calls now, not after the first incident is reconstructed from logs that do not exist. Classification has to handle context-dependent sensitivity, not just pattern matches.
Govern, do not gate. Build the policy, audit, and observability infrastructure that makes MCP safe enough to scale across engineering, sales, finance, and every function already experimenting with it. Blocking MCP across the enterprise is neither realistic nor desirable.
The takeaway
The CISA leak is the headline. The underlying problem is unsanctioned channels carrying contextually sensitive data past inspection points that were never designed to see it. A contractor with a personal GitHub account did it manually for six months. AI agents connected through MCP will do it autonomously, at machine speed, across every function in the business that is already adopting them.
The next "worst leak ever witnessed" will not be a contractor with a personal GitHub account. It will be an AI agent doing the same thing autonomously, and the security teams that build MCP observability into their stack now are the ones who will see it coming. See what MCP observability looks like in practice.
.svg)
.svg)
