Enterprise Multi-Agent Security Design: Data Security and Script Security in Practice

When building enterprise-grade multi-agent systems, security is often the critical threshold that determines whether a project can actually ship. As shared by a Bilibili creator focused on Harness Engineering (enterprise-level agent engineering) education, medium-to-large enterprises evaluating agent projects will almost universally scrutinize security isolation and data security. This isn't just a technical challenge — it's a core competency that candidates must be able to articulate clearly in interviews.

This article draws from that creator's live coding sessions to systematically break down the two major categories of agent security issues, their corresponding solutions, and a structured answer framework you can use directly in interviews.

The Two Core Security Concerns: Data Security and Script Security

Enterprise agent security can be cleanly divided into two categories: data security and script security. These two concerns deal with different objects and require different approaches. Getting this distinction clear is the starting point for understanding the entire security framework.

Data security refers to protecting enterprise data when agents access it during runtime. When your agent needs to read internal databases or access sensitive files on a server, strict permission control mechanisms must be in place. Any agent that can read internal data without well-defined permission boundaries is a potential data leak waiting to happen.

Script security is more subtle and more easily overlooked by developers. It breaks down further into two distinct scenarios, each covered below.

Two Typical Script Security Scenarios

Risk from Agent-Generated Scripts at Runtime

Modern Harness agents routinely generate scripts on the fly based on business needs. This is essentially table stakes for a mature agent — as the creator put it, if an agent can't even generate scripts dynamically, its engineering maturity is severely limited.

But this capability introduces risk: these scripts are generated by large language models, and LLM-generated code is not inherently safe. Imagine a model-generated script that reads a local file it shouldn't access, or opens a network connection to a malicious external server. These unpredictable, autonomously generated scripts represent the first category of script security risk.

Risk from Third-Party Plugins and Skills

The second category of script security comes from external dependencies. Many enterprise agents rely on plugins or Skill modules downloaded from the internet. These Skills may not be developed in-house — some developers, looking for shortcuts, download ready-made Skills, make minor modifications, and deploy them without ever auditing the full source code.

This practice introduces enormous security risk. Third-party code of unknown origin may contain malicious logic or security vulnerabilities. Once introduced into a production environment, the consequences can be severe. For medium-to-large enterprises, agents that ignore this type of supply chain security have virtually no production viability.

---

What is a Sandbox? A sandbox is an OS-level or container-level isolation mechanism that restricts a process's system call permissions, file access paths, and network egress — preventing executed code from "seeing" or "touching" the host environment's real resources. Common implementations include Linux's seccomp (secure computing mode) for filtering system calls, container technologies like Docker and gVisor, and WebAssembly runtimes. In agent systems, the key value of a sandbox is this: even if the LLM generates malicious code, that code cannot actually read sensitive files on the host or establish unauthorized network connections when running inside the sandbox — keeping potential damage contained within the isolation boundary.

Supply Chain Attacks in the Skill Ecosystem This category of risk is known in software security as a "supply chain attack." A classic example is the npm ecosystem: attackers publish packages containing data-exfiltration logic to public registries, and developers who install them unknowingly expose credentials in production. The risk structure in agent Skill ecosystems is similar: a Skill module containing a backdoor, once downloaded and run with elevated permissions, could exfiltrate sensitive data like internal API keys or database connection strings. Performing a code audit on third-party Skills — or at minimum scanning them with automated static analysis tools like Bandit or Semgrep before deployment — is a basic hygiene requirement for enterprise projects.

---

The Solution: Permission Control and Sandbox Isolation

The two categories of security problems map to two clear solution paths. The logic is straightforward.

Data security → Permission control. Use strict permission management to lock down which data, files, and resources an agent can access, enforcing hard access boundaries.

Script security → Sandbox isolation (SandBox). Whether it's a script generated by an LLM or a Skill downloaded from a third party, execute it inside an isolated sandbox environment — preventing direct contact with the host system's sensitive resources and network.

This combination — permissions for data, isolation for scripts — is the security foundation that makes advanced capabilities like self-evolving Skills and human-in-the-loop intervention possible in enterprise multi-agent systems.

Interview Answer Framework: Problems First, Then Solutions

When an interviewer asks "How does your agent handle security?", jumping straight into technical jargon is the wrong move. The framework the creator recommends is worth adopting:

1. Start by laying out the problem landscape — data security and script security as two major categories, with an explanation of the two sub-scenarios under script security;
2. Then walk through solutions one by one — permission control for data security, sandbox isolation for script security;
3. Finally, ground it in concrete technical implementation — skipping the technical details is a cop-out.

This layered "problem → solution → implementation" progression shows far more engineering maturity than diving straight into technology names.

Seeing Permission Control in Code

In real projects, permission control often manifests as large volumes of distributed, dense code. The creator showed an ongoing live project where permission-related code made up a substantial portion of the codebase.

Keywords like filesystem permission appear throughout the project code, and just the permission handling for one file backend spans from around line 100 to over line 270. This reinforces the point: real enterprise-grade permission control isn't a one-liner conditional — it's a systematic design woven through every layer of file reads and data access.

If your project uses an orchestration framework like LangGraph and involves file or data read operations, permission management logic must be explicitly implemented at the code level. Additionally, for custom file backends, whitelists and blacklists should be defined to granularly control the accessible scope.

One noteworthy engineering detail: the creator candidly mentioned hardcoding the whitelist/blacklist directly in the code for the demo project, while acknowledging that the correct approach is to extract these configurations into a separate config file for easier maintenance and adjustment. This is a practical tip worth keeping in mind.

---

LangGraph and Permission Enforcement LangGraph is a stateful multi-agent orchestration framework from the LangChain team. It defines agent collaboration flows as directed graphs (DAGs), where each node can be an agent or a tool call. For nodes involving file system or database operations, developers must explicitly validate the caller's permission context within the node function — the framework does not handle this automatically. Whitelist/blacklist rules are typically defined using path prefixes or regular expressions: whitelists specify directories permitted for read/write, while blacklists explicitly block high-risk paths like /etc or ~/.ssh. Extracting these rules into standalone config files (such as YAML or TOML) rather than hardcoding them not only lets operations teams adjust policies without touching source code, but also makes it easier to plug the rules into CI/CD pipelines for automated compliance checks.

---

Conclusion

For engineers looking to break into enterprise agent development, security design isn't optional — it's a hard currency in both your resume and interviews. Mastering the core principle of permissions for data, isolation for scripts, and being able to explain the implementation details in terms of specific frameworks and code, is what it takes to truly hold your ground in interviews and in production.