2026-09-11

Enterprise AI Is a Supply Chain: Why Every Request Needs a Security Boundary

SecurityEnterprise AIArchitectureAI Agents

🇬🇧 English | 🇨🇳 中文

Date: 2026-09-11
Author: Limina Engineering Team

English

Enterprise AI is often sold as a model-selection problem: choose a capable model, connect an API key, then let the agent work. That picture is dangerously incomplete.

A production request crosses a supply chain. It can touch a model provider, a gateway, identity systems, a knowledge source, a tool server, and eventually a real business system. Each layer can see data, influence instructions, or widen what an agent is able to do. An endpoint is not a trust boundary merely because it has HTTPS.

That is why AI security at Limina Labs starts before a model produces a token.

Procurement Is a Security Decision

Cheap shared keys and opaque relay chains are not infrastructure. They are unpriced trust dependencies.

Recent research, "Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain", showed the underlying problem: an intermediary that terminates a model request can inspect prompts and credentials, and can potentially alter a returned tool call before an agent executes it. The model may be behaving correctly; the system around it may not be.

We treat supplier selection as part of our security architecture. We procure enterprise-grade services that can be assessed and held accountable. Data handling, identity controls, regional requirements, auditability, incident response, and the actual request path matter as much as model capability or token price.

This is not a claim that a contract makes a system invulnerable. It is a refusal to build critical workflows on infrastructure whose custody and operational controls cannot be inspected.

Every Request Has to Earn Its Way In

The dangerous assumption in agent systems is that every request should be passed to the model unchanged. It should not.

At Limina Labs, each request enters a security-analysis stage before model execution. That layer evaluates the request against the task and its authorization boundary: sensitive data exposure, suspicious or conflicting instructions, attempted privilege expansion, and requests for tools or actions outside the permitted scope.

The outcome is not always “send.” Depending on policy, a request can be minimized, redacted, blocked, or escalated for review.

This distinction matters. Prompt instructions are probabilistic. A request-security layer is deterministic. It does not ask the model to remember a safety rule while it is trying to complete a task; it decides which data and capabilities are available before the model starts reasoning.

Models Suggest. Systems Authorize.

Even a clean request path does not turn a model into a trusted operator. Models can be wrong, manipulated by untrusted content, or persuaded to take a shortcut. Tool output and MCP responses can be wrong too.

The architecture therefore has to keep authority outside the model:

  1. The model proposes an action. It does not receive blanket authority to execute it.
  2. Policy evaluates the action. Access to data, tools, networks, and business systems is checked independently of the model's reasoning.
  3. High-impact actions are constrained. Sensitive writes, external communication, installations, production changes, and irreversible operations require stricter controls or review.
  4. The system retains evidence. Security decisions and consequential actions must be traceable so incidents can be contained rather than guessed at.

This is not friction for its own sake. It is what lets automation operate in real enterprise workflows without silently becoming an uncontrolled privileged user.

Security Is the Product Boundary

The question for enterprise AI is not whether a model can complete a demo. It is whether the system can remain controllable when the request is adversarial, the context is wrong, a supplier fails, or an agent reaches for a tool it should not have.

Limina Labs is built around that question. Enterprise procurement reduces unnecessary trust. Request-level security analysis narrows what enters the model. Deterministic controls constrain what leaves it.

Useful AI needs capability. Trusted AI needs boundaries.

中文

企业 AI 常被包装成一个模型选型问题：选一个足够强的模型，接上 API Key，再让智能体开始工作。这种理解危险地不完整。

一条生产请求会穿过一整条供应链：模型提供商、网关、身份系统、知识库、工具服务器，最终抵达真实的业务系统。每一层都可能看到数据、影响指令，或扩大智能体能够做的事。一个有 HTTPS 的 endpoint，并不天然构成信任边界。

因此，Limina Labs 的 AI 安全从模型产生第一个 token 之前就开始。

采购本身就是安全决策

低价共享 Key 和不透明的中转链路不是基础设施，而是未被计价的信任依赖。

近期论文 《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》 揭示了根本问题：一个终止模型请求的中间层可以看到提示词和凭证，也可能在智能体执行前篡改模型返回的工具调用。模型本身可能行为正确，但它周围的系统未必如此。

我们将供应商选择视为安全架构的一部分。Limina Labs 采购可被评估、可被追责的企业级服务。数据处理、身份控制、区域要求、审计能力、事故响应，以及请求实际经过的路径，与模型能力和 token 价格同样重要。

这并不意味着一份合同能让系统无懈可击。它意味着我们拒绝把关键业务流程建立在无法检查其托管边界和运营控制的基础设施上。

每一个 Request 都必须先通过安全边界

智能体系统中最危险的假设，是任何 request 都应原样交给模型。事实并非如此。

在 Limina Labs，每一个 request 在进入模型执行前都会经过安全分析。该层根据任务及其授权边界评估请求：敏感数据暴露、可疑或冲突的指令、试图扩大权限的行为，以及超出允许范围的工具或操作请求。

结果并不总是“发送”。根据策略，一个 request 可以被最小化、脱敏、拦截，或升级至人工审核。

这一区别非常重要。提示词指令是概率性的；request 安全层是确定性的。它不会要求模型在努力完成任务时“记住”某条安全规则，而是在模型开始推理前决定它能看到哪些数据、拥有何种能力。

模型负责建议，系统负责授权

即使请求路径干净，模型也不应被当作可信操作者。模型可能出错，可能被不可信内容操纵，也可能为了完成任务选择捷径。工具输出和 MCP 响应同样可能不可信。

因此，权限必须留在模型之外：

  1. 模型提出动作建议。 它不拥有默认、无限制的执行权。
  2. 策略独立评估动作。 对数据、工具、网络和业务系统的访问，不依赖模型自己的推理来判断。
  3. 高影响动作受到约束。 敏感写入、对外通信、软件安装、生产变更和不可逆操作，需要更严格的控制或人工审核。
  4. 系统保留证据。 安全决策与关键动作必须可追溯，发生事故时才能控制影响，而不是靠猜测排查。

这不是为了摩擦而制造摩擦。正是这套结构，让自动化可以进入真实企业流程，而不会悄悄变成一个不受控制的高权限用户。

安全就是产品边界

企业 AI 的问题不是模型能否完成一个演示，而是当 request 带有对抗性、上下文有误、供应商失效，或智能体尝试调用不应拥有的工具时，系统是否仍然可控。

Limina Labs 围绕这个问题构建。企业级采购减少不必要的信任；request 级安全分析收紧进入模型的内容；确定性控制约束模型输出能够造成的影响。

有用的 AI 需要能力。值得信任的 AI 需要边界。