Why Are Enterprises Building Their Own AI Agents? Security Risks and the Case for In-House Control

As AI Agent tools rapidly proliferate across enterprise and personal use cases, a critical question has moved to the forefront: when we hand over control of our computers, servers, and account credentials to a third-party AI application, how serious are the risks? Drawing on a technical deep-dive shared by a Bilibili creator on "enterprise-grade in-house AI Agents," this article explores why a growing number of companies are abandoning third-party products in favor of building their own highly customized intelligent agent platforms.

The Security Risks of Third-Party AI Agents Are Hard to Ignore

The creator opens with a sharp real-world concern: directly using AI Agent tools provided by third-party vendors carries significant data security risks.

According to the creator, China's Ministry of Industry and Information Technology (MIIT) previously issued a security warning targeting a category of AI Agent tools, citing multiple vulnerabilities. Even more telling, real-world tests posted online have shown that these tools — when granted excessive permissions — can read and expose account balances, WeChat red packet details, and even confidential internal company information.

Industry Context: The MIIT's security warning against AI Agent tools reflects a broader push by Chinese regulators to strengthen AI security governance. Since 2023, agencies including the Cyberspace Administration of China and the MIIT have issued policy documents such as the Interim Measures for the Management of Generative AI Services, setting explicit requirements around data security, algorithmic transparency, and user privacy protection. For action-capable tools like AI Agents, regulatory scrutiny focuses especially on: cross-border data transfer risks (whether user operation logs are uploaded to overseas servers), excessive permission requests (whether sensitive information is accessed without clearly informing users), and supply chain security (whether third-party plugins/Skills have been properly security-reviewed). Enterprises that overlook these compliance requirements risk regulatory penalties and data sovereignty concerns.

The underlying logic isn't hard to grasp. An AI Agent is an AI system capable of perceiving its environment, autonomously planning, and executing multi-step tasks. Its core distinction from a traditional chatbot lies in its tool-calling capability — it can operate browsers, execute code, read and write files, call APIs, and more. This capability relies on underlying tool-calling frameworks (such as Function Calling or the ReAct framework), where the agent uses LLM reasoning to decide which tools to invoke and in what order. Herein lies the danger: the more powerful the agent, the greater the potential damage if it's misused or exploited — especially when adversarial prompt injection attacks trick the agent into performing unintended actions, something enterprise users often have little visibility into.

For companies handling sensitive data, handing over these operational permissions to an uncontrollable third-party black box is, in effect, a gamble. This is the crux of the entire discussion.

The Core Logic Behind Building AI Agents In-House

Faced with these security risks, a compelling direction is emerging: the more common enterprise need going forward will likely be to develop a dedicated internal AI Agent system, rather than relying on third-party products.

The advantages of building in-house are clear:

• Data stays inside the network: All sensitive operations and data are processed within the enterprise's internal environment, fundamentally eliminating the risk of information leaking to third parties.
• Full functional control: Enterprises can add or remove capabilities at any time based on actual business needs, unconstrained by a third-party vendor's product roadmap.
• Granular permission management: Enterprises can autonomously decide what the AI Agent can access and operate, keeping risk within acceptable bounds.

In essence, building in-house means taking control back into your own hands. For mid-to-large enterprises, or for industries with strict data security requirements (such as finance and government), this is almost an inevitable choice.

Low-Cost Feature Expansion Through the Skill Modular Architecture

So, would extending the capabilities of an in-house AI Agent be overly complex? The answer is: as long as the underlying architecture is solid, adding features is actually quite straightforward — the key is adding Skill modules.

A Skill module is essentially a packaged tool function for an AI Agent, a design philosophy rooted in microservices architecture and plugin-based systems. In technical terms, each Skill typically comprises three elements: a functional description (helping the LLM understand when to invoke the Skill), an input/output schema definition, and the actual execution logic. Mainstream agent frameworks such as LangChain, AutoGen, and LlamaIndex all provide standardized Skill/Tool interface specifications. The engineering value of this modular design is significant: Skills are highly decoupled, can be developed, tested, and deployed independently, and adhere to the Single Responsibility Principle. Giving an agent a new capability simply requires mounting the corresponding Skill — the engineering flexibility is exceptional.

Parallel Development Across Teams

Once the underlying framework is in place, feature development can be distributed across different business teams. Each team develops the Skills they need independently, without interference or redundant effort. Enterprises can build an internal Skill Registry on top of this foundation to centrally manage versioning, permission declarations, and security audit records — dramatically reducing the management overhead of large-scale collaborative development. This model aligns naturally with enterprise agile workflows and can significantly accelerate feature iteration.

Reusing the Open-Source Skill Ecosystem

For teams that lack the bandwidth to build certain general-purpose features from scratch, there's another path: finding well-vetted, open-source Skill libraries from the community.

One important caveat: when adopting external Skills, always evaluate their security carefully — prioritize open-source resources that are demonstrably safe for servers and come from trusted sources. Deploying these Skills on your own servers still allows you to call them directly. This effectively creates a hybrid model of in-house framework + open-source ecosystem, ensuring core controllability while leveraging the efficiency gains that community ecosystems offer.

Conclusion: Enterprise AI Agent Deployment Is Undergoing a Paradigm Shift

Taken together, enterprise AI Agent deployment is evolving from "off-the-shelf third-party products" toward "self-controlled internal intelligent agent platforms."

This shift is driven by two forces: first, the hard requirement of security and regulatory compliance — the MIIT's warning and the vulnerabilities exposed in real-world tests both validate the risks of third-party black boxes; second, the low-cost extensibility enabled by Skill modular architecture, which makes "building your own AI Agent" far more accessible than it once seemed.

Of course, building in-house isn't without barriers — constructing a stable underlying framework, establishing a Skill security review process, and organizing team collaboration all require meaningful technical investment. But for enterprises that take data sovereignty seriously, the direction of this path is becoming increasingly clear.

Security Note: Whether building in-house or using third-party tools, the Principle of Least Privilege (PoLP) remains the first line of defense for AI Agent security. This principle — rooted in traditional information security — requires that any program be granted only the minimum permissions necessary to complete its task. In AI Agent engineering practice, this means: creating isolated agent sandboxes for different business scenarios, restricting access to specific directories or API endpoints; introducing human-in-the-loop approval steps for high-risk actions such as financial operations or data deletion to prevent irreversible automated outcomes; and implementing comprehensive operation log auditing that records the full context of every Skill invocation as a basis for post-incident tracing and anomaly detection. The fewer permissions granted to an agent, the smaller its potential attack surface.

Key Takeaways