From Prototype to Production: The Architecture Behind Secure & Governed AI Agents

从原型到生产：安全与受控 AI 智能体的架构解析

Building the responsible AI, security, and governance layers required for enterprise-ready agents 构建企业级智能体所需的负责任 AI、安全与治理层

Partha Sarkar | Aug 18, 2026 | 15 min read

A common question I often get asked is if LLMs and coding assistants can build the application in a few hours, which used to take weeks manually, why will it still be a couple of months before we can go live? 我经常被问到一个问题：如果大语言模型（LLM）和编程助手能在几小时内构建出过去需要数周手动完成的应用程序，为什么我们还需要几个月才能正式上线？

There are several reasons for this, primary among them being infra and data readiness, but also building responsible AI — model & agent governance, security, transparency, explainability, etc. Building these governance controls, and rigorously testing them using realistic golden test datasets, takes time to convince the stakeholders that the application is ready for production. 造成这种情况的原因有很多，其中最主要的是基础设施和数据的就绪程度，但同样重要的是构建负责任的 AI——包括模型与智能体治理、安全性、透明度、可解释性等。构建这些治理控制措施，并使用真实的“黄金测试数据集”进行严格测试，需要时间来向利益相关者证明该应用程序已准备好投入生产。

In this article, we’ll move beyond the “hello world” of AI agents. We’ll explore the architecture required to build a hardened, production-ready Agentic AI system. We’ll look at a purpose-built experimental environment using a mock corporate HR Assistant, and explain how to implement robust defenses including multi-level Access Control (ACL), execution tracing, vector store integrity checks, and Human-in-the-Loop (HITL) workflows. 在本文中，我们将超越 AI 智能体的“Hello World”阶段。我们将探讨构建一个稳健、可投入生产的智能体 AI 系统所需的架构。我们将通过一个模拟的企业人力资源助手实验环境，解释如何实现包括多级访问控制 (ACL)、执行追踪、向量数据库完整性检查以及人机协同 (HITL) 工作流在内的强大防御机制。

The objective is not to demonstrate every aspect of the Responsible AI framework. As is the case with everything AI, this is an extensive and rapidly evolving field. The goal is to appreciate that while building a functional AI agent today is remarkably easy, deploying that same agent into a production enterprise environment presents a distinctly different, much harder problem. So let’s begin. 本文的目标并非展示负责任 AI 框架的方方面面。正如 AI 领域的一切事物一样，这是一个广泛且快速发展的领域。我们的目标是让大家认识到：虽然今天构建一个功能性的 AI 智能体非常容易，但将其部署到生产级企业环境中却是一个截然不同且困难得多的问题。那么，让我们开始吧。

Why do we need all these controls?

为什么我们需要所有这些控制措施？

Traditional software development has always had a set of well-defined proven testing gates — unit, functional, integration, security, and user acceptance being widely followed. So what is different about an AI application that it requires another layer of testing to define and measure adherence to an organisation’s policies, guardrails and controls? 传统的软件开发一直拥有一套定义明确且经过验证的测试门禁——单元测试、功能测试、集成测试、安全测试和用户验收测试已被广泛遵循。那么，AI 应用程序有何不同，以至于需要额外的一层测试来定义和衡量其对组织政策、护栏和控制措施的遵守情况呢？

The difference is that while in traditional software, the application logic is deterministic, it is not so in agentic systems. The core execution engine is a Large Language Model—a probabilistic text predictor. In traditional software, you can write and test “If user.role != “admin”, the update button is disabled.” Once this condition passes in testing, you can be assured it will behave the same in production. 区别在于，传统软件的应用程序逻辑是确定性的，而智能体系统则不然。其核心执行引擎是大语言模型——一个概率性的文本预测器。在传统软件中，你可以编写并测试“如果用户角色不是管理员，则禁用更新按钮”。一旦该条件通过测试，你就可以确信它在生产环境中也会表现一致。

In contrast, you cannot simply tell an LLM, “Unless the user is admin, do not allow updates to the data” and expect it to work 100% of the time. Even with LLM settings such as temperature = 0, one cannot be certain that it will always be followed without exception. In addition, malicious techniques such as jailbreaks, sycophancy (where the model agrees with the user regardless of instructions), and indirect injections (malicious instructions hidden in documents) will sometimes override prompt-level instructions. 相比之下，你不能简单地告诉 LLM：“除非用户是管理员，否则不允许更新数据”，并期望它能 100% 准确执行。即使将 LLM 的温度参数（temperature）设置为 0，也无法保证它能毫无例外地始终遵循指令。此外，诸如越狱、谄媚（模型不顾指令盲目迎合用户）以及间接注入（隐藏在文档中的恶意指令）等恶意技术，有时会覆盖提示词层面的指令。

To make an agent production-ready, we must adopt Defense in Depth. We cannot rely on the LLM to govern itself. Instead, we must build deterministic safety rails around the non-deterministic core. 为了使智能体达到生产就绪状态，我们必须采用纵深防御策略。我们不能依赖 LLM 进行自我治理。相反，我们必须在非确定性的核心周围构建确定性的安全护栏。

Setting Up the Experiment

设置实验

To demonstrate these concepts, let’s build an HR Policy Assistant. This is an agentic RAG system designed to answer employee questions and take actions (like submitting leave requests or updating salaries). To test the system’s resilience, let’s implement three distinct user personas: 为了演示这些概念，我们来构建一个人力资源政策助手。这是一个智能体 RAG（检索增强生成）系统，旨在回答员工问题并执行操作（如提交请假申请或更新薪资）。为了测试系统的弹性，我们设置了三种不同的用户角色：

• Admin (System Administrator): Highest clearance (acl_level=2). Has access to highly confidential employee directory data. Authorized to take all actions. 管理员（系统管理员）： 最高权限（acl_level=2）。可访问高度机密的员工名录数据，获准执行所有操作。
• Bob (HR Manager): Elevated clearance (acl_level=1). Can read HR documents and initiate high-risk workflows. Bob（人力资源经理）： 较高权限（acl_level=1）。可阅读人力资源文档并启动高风险工作流。
• Alice (Employee): Standard clearance (acl_level=0). Can only read public company policies. No permission to update data. Alice（员工）： 标准权限（acl_level=0）。仅可阅读公司公开政策，无权更新数据。

The Agentic RAI Architecture

智能体负责任 AI (RAI) 架构

Below is the high-level architecture of the HR Agent. Note that the LLM is completely isolated from direct user input and direct database access. The core architecture components are as follows: 以下是人力资源智能体的高层架构。请注意，LLM 与用户的直接输入和数据库的直接访问是完全隔离的。核心架构组件如下：

The Safety Pre-Filter

安全预过滤器

The pre-filter is the very first gate every user query must pass through. It runs before any LLM call, any retrieval or policy evaluation. The pre-filter will typically be implemented using a fast and cost-effective LLM such as gemini flash or GPT mini versions, and performs the following functions: 预过滤器是每个用户查询必须通过的第一道关卡。它在任何 LLM 调用、检索或政策评估之前运行。预过滤器通常使用快速且经济高效的 LLM（如 Gemini Flash 或 GPT Mini 版本）实现，并执行以下功能：

• Direct Injection Blocking: It scans the raw user input for known attack patterns — phrases like “ignore all previous instructions”, “you are now DAN”, “pretend you have no restrictions”, or “print your system prompt”. It uses semantic LLM classification to catch zero-day jailbreaks and sophisticated linguistic tricks. 直接注入拦截： 它扫描原始用户输入以查找已知的攻击模式——例如“忽略之前的所有指令”、“你现在是 DAN”、“假装你没有任何限制”或“打印你的系统提示词”。它利用语义 LLM 分类来捕获零日越狱攻击和复杂的语言技巧。

If the query is deemed safe, the classifier outputs a structured JSON response containing preliminary risk scores and extracted intents that the downstream Policy Engine can leverage. 如果查询被认为是安全的，分类器会输出一个结构化的 JSON 响应，其中包含初步风险评分和提取的意图，供下游的政策引擎使用。

Policy Engine and Autonomy Classifier

政策引擎与自主性分类器

A key feature of agentic systems is that they can operate autonomously. And that carries significant risks for high-impact tasks related to data modification. The purpose of this is to enforce the principle of Minimal Privilege by Default — if the engine cannot confidently determine an action to be safe, it escalates rather than executes. 智能体系统的一个关键特性是它们可以自主运行。这对于涉及数据修改的高影响任务带来了重大风险。其目的是强制执行“默认最小权限”原则——如果引擎无法确信某项操作是安全的，它会选择升级处理而不是直接执行。

In this demo, there are the following three tiers into which a query is classified: 在此演示中，查询被分为以下三个层级：

Tier	Description	Example
AUTONOMOUS	Safe to retrieve and respond, fully automated	“What is the vacation policy?”
SUPERVISED	Action permitted, but logged with enhanced audit trail	“Submit a leave request”
REQUIRES_HITL	High-risk write-action, must pause for human approval	“Update Bob’s salary to $200,000”

层级	描述	示例
自主 (AUTONOMOUS)	可安全检索并响应，完全自动化	“休假政策是什么？”
受监督 (SUPERVISED)	允许操作，但需记录增强审计追踪	“提交请假申请”
需人工介入 (REQUIRES_HITL)	高风险写入操作，必须暂停等待人工审批	“将 Bob 的薪资更新为 20 万美元”

Access Control Lists (ACL) and Hierarchical Enforcement

访问控制列表 (ACL) 与分层执行

The ACL layer operates in two phases: ACL 层分两个阶段运行：

• Phase 1 — Document-Level ACL (Vector Database Pre-filter): During embedding, each document chunk is seeded with the permitted ACL levels in its metadata. When the Retrieval Agent queries ChromaDB, it doesn’t… 第一阶段——文档级 ACL（向量数据库预过滤器）： 在嵌入过程中，每个文档块的元数据中都会植入允许的 ACL 级别。当检索智能体查询 ChromaDB 时，它不会……