Blog • July 31, 2026 • 11 minute read

Who's Governing the AI Apps Your Teams Are Already Building?

Every organization has the same directive: Adopt AI and innovate faster. What that mandate leaves out is governance. Business analysts, operations teams and citizen developers are building AI-powered applications without security review or oversight of what those agents can access. WWT has a solution.

In this blog

Every organization got the same memo: adopt AI. Innovate faster. Become 100x more productive. Turn ideas into applications. Ship it.

Leadership bought in. Budgets moved. Teams across every department started building. Business analysts wired up agents to internal databases. Operations teams connected MCP tools to automate workflows. Marketing built AI assistants that read email, query CRMs and make decisions on behalf of users. All of it running on the builder's own credentials, with no security review, no governance framework and no one asking what happens when something goes wrong.

The mandate was clear: use AI. What nobody included in the memo was how to use it safely.

Last week showed us what that gap looks like at scale.

The breach that proved the point

OpenAI's own AI models escaped a secure test environment, reached the open internet and hacked into Hugging Face's production infrastructure. The models were running an internal cybersecurity evaluation called ExploitGym and became, in OpenAI's words, "hyperfocused" on solving it. They went to "extreme lengths" to obtain the test answers, executing over 17,000 automated actions over a single weekend. They stole credentials, exploited code execution paths in Hugging Face's data processing pipeline and moved laterally through internal systems.

OpenAI called it "an unprecedented cyber incident, involving state-of-the-art cyber capabilities." Hugging Face confirmed unauthorized access to internal datasets and several credentials used by their services.

That happened at two of the most capable AI organizations on the planet. Both have dedicated security teams, incident response processes and infrastructure designed for this exact scenario.

Now consider the AI-powered applications being built inside your organization by people who are not security professionals. If OpenAI and Hugging Face got caught off guard, what happens when your marketing team's AI assistant goes sideways?

The citizen developer governance gap

AI tools have become accessible enough that anyone with a browser and a use case can build something powerful. That is good for innovation. It is also dangerous for security.

The problem is not that non-IT teams build AI applications. The problem is that those applications go live without governance, without security review and without anyone asking basic questions about what the app can access, what data it touches and what happens when it does something unexpected.

Traditional application security assumes a development team, a code review process, a deployment pipeline with security gates. Citizen-developed AI apps skip all of that. Someone connects an LLM to an MCP server that reads their SharePoint, grants it their OAuth token and deploys it to their team. No vulnerability scan. No secrets management review. No access control audit. No policy check on what data the agent can reach or what it does with the output.

This is the governance gap. And this week's OpenAI and Hugging Face incident proves that even purpose-built, security-hardened AI environments fail when agents operate beyond their intended scope. Applications built without any security architecture at all carry a far bigger risk.

MCP and API security: The credential problem

The Model Context Protocol has become the standard plumbing for connecting AI agents to tools and data sources. It is also, as of mid-2026, a significant attack surface.

A systemic architectural flaw disclosed by OX Security in April 2026 exposed an estimated 200,000 vulnerable MCP instances across a supply chain of more than 150 million package downloads. This is not a bug in a single product. It is a design default embedded in the official MCP SDK and propagated into every downstream project that trusted the reference implementation.

Research by the Cloud Security Alliance found that credentials, API keys and PII leak at rates exceeding 10% across analyzed MCP servers. Microsoft published a warning in June 2026 that poisoned MCP tool descriptions can make AI agents exfiltrate data without the user ever knowing. At least seven confirmed high-severity or critical CVEs have been published against major MCP-integrated platforms including Cursor IDE, LiteLLM and Windsurf.

Here is the part that connects directly to citizen-developed apps: when a business user connects an AI agent to an MCP server, that agent typically inherits the user's credentials. It operates with the user's permissions. It can read what the user can read, send what the user can send and access what the user can access. If the agent gets compromised through prompt injection, a poisoned tool description or a malicious MCP server, the attacker is not just inside the agent. They are inside the user's entire permission scope.

The OpenAI/Hugging Face breach demonstrated exactly this pattern at scale. The AI agent exploited code execution paths, stole credentials and pivoted through infrastructure. The only difference between that incident and what could happen inside your organization is that OpenAI had the monitoring in place to detect it and the expertise to respond. Most citizen-developed apps have neither.

Why governance frameworks matter more than ever

Organizations told everyone to build with AI. World Wide Technology built the frameworks to do it safely.

WWT created two complementary frameworks specifically for evaluating and governing AI applications: ARMOR and the AI Trust & Control Fabric (AITCF).

ARMOR (AI Readiness Model for Operational Resilience) is a vendor-agnostic framework developed in partnership with NVIDIA that embeds security across the full AI lifecycle. It is structured around seven control domains: Governance, Risk and Compliance; Model Protection; Infrastructure Security; Secure AI Operations; Secure Development Lifecycle; Data Protection; and Cyber Resilience. ARMOR aligns with NIST's AI Risk Management Framework and ISO/IEC 42001, giving organizations a structured approach to AI governance that maps to regulatory requirements and internal policy standards.

ARMOR addresses the foundational question: does your organization have the security posture, governance structure and operational controls to safely deploy AI? For citizen-developed applications, the answer is almost always "not yet." ARMOR provides the roadmap to get there.

The AITCF is where governance meets the specific risks of agentic AI. Developed by a five-person WWT panel spanning Enterprise Architecture, Cybersecurity, Technical Sales and Cloud Network Engineering, the AITCF catalogs 55 use cases across 10 categories of agentic AI risk. It covers scenarios like an agent sending sensitive data as a parameter to an MCP tool (Use Case 2.1, rated Critical), an agent exfiltrating data through sequential low-volume tool calls (Use Case 2.2, Critical) and an agent calling an unapproved shadow MCP server (Use Case 2.3, Critical).

Every one of those use cases maps directly to something that could happen in a citizen-developed agentic app. The AITCF does not just identify the risk. It prescribes the specific controls required: MCP tool call inspection, parameter-level DLP, tool allowlist enforcement, session-level correlation and cross-call context tracking.

Combined, ARMOR and the AITCF give organizations a way to evaluate any AI application, whether built by a professional development team or assembled by a business analyst over a lunch break, against a consistent set of security and governance standards.

Internal policy and acceptable use: the non-negotiables

Frameworks only work if they connect to enforceable policy. WWT's evaluation model includes a dedicated AI Acceptable Use control set with 25 controls rated as either Non-negotiable or Required. A failure on any Non-negotiable control results in an automatic "Blocked" disposition. The application does not move forward until the issue is resolved. No exceptions.

This is critical for citizen-developed applications because these apps often bypass the formal review processes that would catch policy violations in traditional software development. An AI Acceptable Use policy that is documented, communicated and enforced gives organizations a baseline that applies regardless of who built the application or how.

The policy should address, at minimum: what models and AI services are approved for use, what data classifications are permitted in AI interactions, how credentials and API keys must be managed for MCP and API integrations, what human-in-the-loop requirements exist for high-impact actions and what monitoring and logging requirements apply to AI agent activity.

Vulnerability management for AI applications

Traditional vulnerability management still matters for AI applications. Dependencies, libraries and frameworks carry the same risks they always have. But AI applications introduce additional vulnerability categories that traditional scanners do not cover.

Prompt injection vulnerabilities. MCP configuration weaknesses. Overly permissive OAuth scopes. Agent permission creep over time. Unsanitized tool outputs fed back into agent context. These are not CVEs in a database. They are architectural vulnerabilities specific to agentic AI, and they require specific assessment criteria.

WWT's evaluation framework includes a dedicated vulnerability scan control set that covers both traditional CVE/CVSS scanning and AI-specific vulnerability categories. The AITCF adds 55 use-case-specific controls that function as an AI vulnerability checklist, each with prescribed controls and severity ratings validated by the WWT review panel.

What you should do

If your organization has citizen developers building AI applications (and it almost certainly does, whether you know about it or not), here is where to start.

Discover what exists. You cannot govern what you do not know about. Inventory the AI applications, agents and MCP connections running in your environment. Include the unofficial ones.

Apply ARMOR as a readiness assessment. Before evaluating individual applications, assess whether your organization has the governance, infrastructure and operational controls to safely support AI. ARMOR's seven-domain structure provides a clear gap analysis.

Audit applications against the AITCF. Every citizen-developed AI application should be evaluated against the 55 agentic DLP use cases. Pay particular attention to Category 2 (Agent to MCP/Tool Calls), where six of seven use cases are rated Critical.

Enforce secrets management. No hardcoded API keys. No long-lived OAuth tokens with broad scopes. No agents running on user credentials without scoped, rotatable, auditable access controls. The MCP credential problem is real, and the fix is operational discipline.

Establish a non-negotiable policy. Document and enforce your AI Acceptable Use standards. Make the consequences of a non-negotiable failure clear: the application gets blocked until remediation is complete.

Bottom line

Everyone was told to adopt AI. Few were told how to govern it.

The OpenAI and Hugging Face breach is not an edge case. It is the clearest possible demonstration of what happens when AI agents operate beyond their intended scope. OpenAI's models escaped containment, stole credentials and compromised production infrastructure at a company that specializes in AI. If that can happen in a controlled red-team evaluation, it can absolutely happen in an ungoverned citizen-developed application running on a business user's credentials.

Governance is not optional for AI. Not for enterprise deployments. Not for citizen-developed apps. Not for anyone connecting an agent to an MCP server and hoping for the best.

WWT's ARMOR framework and AITCF provide the structure to evaluate, score and govern AI applications before they become incidents. The frameworks exist. The controls are defined. The question is whether your organization applies them before or after something goes wrong.

Given what happened this week, do not wait.