Huazhi Future Releases Lingyan Miaoyu Special Chapter on Security AI Capabilities: Security Architecture, Agent Governance and Evaluation for Enterprise LLM Applications

Huazhi Future (Chongqing) Technology Co., Ltd. has released the Lingyan Miaoyu Special Chapter on Security AI Capabilities, a companion special chapter to the Lingyan Miaoyu Large Language Model Application White Paper. Focusing on security for enterprise large language model applications, the chapter systematically explains the relationships among data protection, model security, agent governance, computing-resource coordination, and evaluation and audit, and provides a unified framework for technical selection, solution design, project acceptance, and ongoing operations across six chapters and two appendices.

Key Facts at a Glance

• Five capability dimensions: data protection, model security, agent governance, computing and cross-domain collaboration, and evaluation and compliance.
• Four boundaries to define: data boundary, execution boundary, result boundary, and security assurance boundary.
• Three quantum technology paths distinguished: Post-Quantum Cryptography (PQC), Quantum Key Distribution (QKD), and Quantum Random Number Generation (QRNG) — plus quantum-assisted computing, assessed separately.
• Aligned with external references: NIST's finalized post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) and OWASP guidance for agent security and prompt-injection prevention.
• Five industry scenarios: government, financial, healthcare, public safety, and industrial — each with defined control requirements and responsibility boundaries.
• Seven defined evaluation metrics: control coverage rate, risk blocking rate, false blocking rate, detection precision and recall, task-chain audit coverage, latency and recovery (RTO/RPO), and service success rate.
• Four-phase implementation roadmap: inventory and boundary definition, limited pilot, acceptance and launch, and operations and iteration.
• Honest capability boundaries: all appendix metric thresholds are explicitly marked as pending verification — not achieved performance, service commitments, or certification conclusions.

About This Special Chapter

• Document Title: Lingyan Miaoyu Special Chapter on Security AI Capabilities
• Publishing Entity: Huazhi Future (Chongqing) Technology Co., Ltd.
• Series: Special chapter of the Huazhi Future Lingyan Miaoyu Large Language Model Application White Paper
• Scope: Security architecture, agent governance, industry applications, and validation & evaluation
• Intended Readers: Government and enterprise managers, technical leads, security teams, and industry partners

Reading Guide and Executive Summary

Positioning of This Special Chapter

This special chapter focuses on the development of Lingyan Miaoyu's security capabilities for enterprise applications. It systematically explains the relationships among data protection, model security, agent governance, compute-resource coordination, and evaluation and audit, providing a unified framework for technical selection, solution design, project acceptance, and ongoing operations. It is intended for government and enterprise managers, technical leads, security teams, and industry partners.

Core Judgments

Security boundaries should cover the full lifecycle of an AI task. Beyond model outputs, retrieved data, tool permissions, execution identities, cross-domain transfers, and downstream use of results also require control. Security mechanisms should be implemented in identity, policy, and execution systems outside the model, rather than relying solely on prompt constraints.

Security development should begin with implementable and repeatable controls. Data classification, least privilege, approval of sensitive operations, and task auditing should establish the foundation, after which post-quantum cryptography and specific quantum communication technologies can be evaluated based on cryptographic migration needs. Quantum-assisted computing and cryptographic security should be assessed separately and should not be treated as substitutes for one another.

Scope and Capability Boundaries

This special chapter describes the security capability framework and engineering requirements. The specific scope of functionality is subject to product versions, project configuration, and acceptance records. Diagrams illustrate reference architectures or application scenarios and do not constitute evidence of deployed cases. No security mechanism can eliminate all risk, and model-assisted outputs still require review responsibilities aligned with business risk.

Metrics should be validated only after the samples, scenarios, environment, and statistical methods are clearly defined. The numerical values retained in the appendix are inputs for metric verification and should not be regarded as achieved product performance, service-level commitments, or certification conclusions. Industry compliance must be assessed separately in light of applicable requirements, actual data flows, and organizational controls.

Reading Path

Security Objectives and Boundaries

1.1 Risk Scope and Capabilities

After enterprises connect large language models(LLMs) to knowledge bases, business systems, and execution tools, security risks can propagate along the task chain. Malicious instructions in external documents may influence model planning, incorrect identity propagation may amplify tool permissions, and unreviewed generated outputs may enter subsequent business processes. Security design should address data, models, agents, computing resources, and organizational governance together.

[Figure 1 Security AI Capability Mind Map]

This special chapter organizes its development requirements across five capability dimensions: data protection governs the collection and flow of information; model security governs models, retrieval, and outputs; agent governance constrains real-world actions; computing and cross-domain collaboration protect the runtime environment; and evaluation and compliance establish traceable evidence and accountability.

The security scope covers text, images, audio and video, and their derived information. Technical measures should be selected according to actual data types and business risks, rather than using a single “security model” as a substitute for system-level governance.

1.2 Security Objectives and Responsibility Boundaries

Security objectives should be translated into executable rules and verifiable evidence. Business teams define the tasks that may be performed, security teams establish control policies, the platform enforces constraints during invocation and execution, and auditors use records and tests to confirm whether the controls are effective.

Four Types of Boundaries to Define

Data boundary: Encryption does not automatically mean that “data remains within the domain.” Model inputs and outputs, vector indices, logs, caches, backups, and administrative and operational access must also be managed. Cross-domain collaboration should transmit only the information necessary to complete the task and for which authorization has been granted.

Execution boundary: A model may propose an action plan, but it should not grant itself permissions. Operations such as deletion, transactions, production control, and export of sensitive information must pass independent authorization checks and business approval.

Result boundary: Signatures, hashes, and audit mechanisms can help detect whether content has been modified, but they cannot prove that a model conclusion is correct. Results involving professional judgment, individual rights, or personal safety should be subject to human review.

Security Assurance Boundary: Cryptographic protection, system security, and industry compliance are different layers of concern. Research in quantum computing, a particular algorithm, or a single test result cannot be used to infer full-system security guarantees, long-term absolute security, or comprehensive compliance.

Overall Architecture and Full-Stack Collaboration

2.1 Layered Architecture and Cross-Cutting Governance

The Lingyan Miaoyu Security AI reference architecture uses layered controls and cross-cutting governance. Data security, model security, and agent security jointly support industry applications, while the computing runtime foundation provides isolation and recovery capabilities. Cross-domain collaboration and audit governance span all layers. Quantum security, as an extension path for the cryptographic system, should be validated progressively according to deployment conditions.

[Figure 2 Security AI Full-Stack Reference Architecture]

Connections in the architecture represent security dependencies and governance relationships; they do not mean that every business request must pass through every component in a fixed sequence. Each layer should exchange identities, authorization scope, task identifiers, and audit events through clearly defined interfaces, avoiding inconsistent security semantics between upstream and downstream systems.

The items shown in the figure are reference design capabilities. The components, implementation methods, cryptographic algorithms, and service boundaries adopted by a project should be recorded in the deployment inventory.

2.2 Full-Stack Components and Control Responsibilities

Security capabilities should integrate with the computing, scheduling, model-access, and industry-agent systems described in the main white paper. The control placements shown in the table below do not mean that every product has implemented these functions in every version.

Unified Identity and Policy

The invocation chain should preserve the relationship among the real identities of users, services, and agents. Agent names or natural-language declarations should not replace authentication. Authorization should be limited by data scope, tool actions, resources, and validity period, and should be revalidated at the actual execution endpoint. Cross-domain calls must not expand the original authorization.

Shared Audit and Evidence

A task identifier should link model calls, knowledge retrieval, tool execution, and approval events. Audit records should contain the necessary version information, timestamps, calling entities, and disposition outcomes. Sensitive content should be minimized, masked, and access-restricted in audit records. Retention periods and access responsibilities should be determined according to project requirements.

Failure and Change Control

Changes to models, tools, policies, and routing may affect security boundaries and should therefore undergo change review and regression testing. When a critical control is unavailable, the system should stop the relevant high-risk operation or enter a restricted mode; it should not maintain business continuity at the expense of security by allowing operations by default.

Core Security Technologies

3.1 Distributed Data Protection

A distributed data environment should protect the full lifecycle of storage, transmission, retrieval, and use, on the basis of data classification and authorization. Each node retains responsibility for data management within its own domain and collaborates through unified policies and auditable interfaces. “Data remaining within the domain” should be defined as a verifiable data-flow constraint.

[Figure 3 Data Lifecycle and Key Management]

Key management should cover generation, distribution, use, rotation, revocation, and destruction, with clear separation of access to keys and data, backup and recovery procedures, and responsible parties. Algorithm names, parameters, certificates, cryptographic modules, and protocol implementations should be included in the asset inventory and support subsequent migration and replacement.

Derived Data and Egress Checks

Vectors, summaries, model outputs, and logs may still contain sensitive information and should be evaluated together with the original data. Egress checks should decide whether to allow, mask, or block data based on data category, recipient, purpose, and authorization scope. Derived data should not be treated as public information by default.

During deployment, data residency, access paths, and backup paths should be verified. Encryption or local inference alone does not satisfy all data-protection requirements.

3.2 Model Security and Controlled Agent Execution

Model security should cover provenance and versioning, knowledge retrieval, input processing, output inspection, and connections to external tools. User input, external documents, and tool-returned content should be treated as data to be processed and must not be directly elevated to system instructions. Prompt-injection defenses require permission isolation and execution-side validation.[4][5]

[Figure 4 Controlled Agent Execution and Audit Flow]

The model is responsible for understanding the task and proposing a plan, while an independent policy component validates invocation scope, permissions, and parameters. High-risk actions should receive explicit approval before execution. Tools should hold only the minimum permissions needed for the current task, with limits on the networks, files, and business objects they may access.

Output review should, according to the scenario, examine factual support, sensitive information, and business impact. If tool execution fails, permissions change, or results are abnormal, subsequent actions should stop, necessary evidence should be retained, and the case should be transferred for human handling. For operations that may need to be reversed, a rollback method should be defined before production launch.

Least privilege, human approval, and external policy validation follow OWASP guidance for agent security.[4] These controls must not be replaced by the model’s own judgment.

3.3 Quantum-Security Technology Paths and Boundaries

“Quantum security” should be grounded in a clearly defined threat model, cryptographic mechanisms, and implementation evidence. This special chapter distinguishes post-quantum cryptography, quantum key distribution, and quantum-assisted computing to avoid conflating research on computing capability, key-generation technologies, and system-security outcomes.

Post-Quantum Cryptography Migration

NIST has published standards for ML-KEM, ML-DSA, and SLH-DSA, for key encapsulation and digital signatures respectively.[3] They may serve as references for technical research, but this does not mean that a project has adopted these algorithms, nor do they replace cryptographic requirements applicable in the project’s jurisdiction or industry. Migration should begin with an inventory of existing algorithms, protocols, and long-term sensitive data, followed by selection, interoperability testing, and controlled transition.

Quantum Communication and Research Directions

QKD should be evaluated as a specialized technical path where suitable links and equipment are available, while authentication, key storage, and endpoint systems must also be protected.[6] Open quantum systems, non-Hermitian dissipative control, quantum-enhanced solving, and quantum sensing may remain research directions, but their engineering value should be confirmed through independent prototypes, controlled experiments, and security analysis.

Quantum resistance in cryptography does not imply correctness of model inference. Terms such as “quantum-grade encryption” and “quantum-enhanced inference” must not be used as substitutes for algorithms, protocols, defined boundaries, and test reports.

3.4 Cross-Domain Collaboration and Secure Disaster Recovery

Cross-domain collaboration should first define which tasks, data, and results may be shared, and then establish identity federation, authorization propagation, and transmission protection. The scheduling system is responsible for selecting execution nodes that satisfy data-domain and security policies; resource constraints must not automatically override geographic, organizational, or data boundaries.

[Figure 5 Cross-Domain Secure Collaboration and Trust Boundaries]

Each domain should independently maintain its own authorizations and keys. The cross-domain gateway checks the purpose of the request, the receiving entity, and the output content, and uses a unified task identifier to correlate records on both sides. Unauthorized raw sensitive data must not leave its domain as a result of task forwarding, log aggregation, or disaster-recovery replication.

Disaster-recovery objectives should separately define the Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Exercises should verify not only whether nodes fail over, but also whether business services are restored, authorization remains valid, keys are available, and data and audit trails remain consistent. Inter-center network conditions must be included in testing.

Cryptographic protection, network latency, and business recovery are different metrics. The latency of a single link switchover must not be treated as the recovery time of the entire application system.

Industry Application Scenarios

4.1 Overview of Five Industry Application Scenarios

Industry applications are built on shared security capabilities while retaining the responsibility boundaries of different business contexts. The following scenarios illustrate security design and task workflows; they do not indicate that all customer cases, deployment scales, or measured benefits already exist. Deployment should focus on specific business cases in which data can be clearly bounded, operations can be controlled, and results can be accepted against defined criteria.

[Figure 6 Five Industry Security AI Application Scenarios]

The main reusable elements across industries are identity, authorization, audit, and recovery mechanisms. Unvalidated industry decision rules should not be directly reused. Government scenarios emphasize process and authorization accountability; financial scenarios emphasize transaction and risk review; healthcare emphasizes patient information and professional judgment; public safety emphasizes incident verification; and industrial scenarios emphasize production-control boundaries.

4.2 Government and Financial Scenarios

Government Scenarios

For policy Q&A, government services, urban governance, integrated law enforcement, and emergency management, agents may assist with retrieval, document preparation, and task assignment. Content involving administrative actions or external publication should undergo business review. Cross-department collaboration should retain sources, authorization grounds, processing status, and responsible personnel.

Financial Scenarios

For risk-control assistance, transaction auditing, asset information analysis, and review of marketing materials, customer data should be isolated from transaction permissions, and the boundary between model-assisted analysis and final decision-making should be clear. Models must not independently approve transactions, adjust credit limits, or make representations regarding returns to external parties.

The above are requirements for scenario implementation and do not indicate that industry certification has been obtained. Applicable requirements should be jointly confirmed by the project’s business, security, and compliance owners.

4.3 Healthcare, Public Safety, and Industrial Scenarios

Healthcare Scenarios

Clinical decision support, medication-risk alerts, medical-record structuring, and regional healthcare collaboration should be based on protection of patient information and review by healthcare professionals. The system should retain source provenance and the evidentiary basis for its outputs, clearly flag uncertain results, and must not replace diagnosis, prescriptions, or treatment decisions with model-generated content.

Public Safety Scenarios

Video analysis, patrol assistance, risk identification, and emergency dispatch should be limited by defined monitoring purposes, access scope, and retention periods. Recognition results should be treated as leads requiring verification through human review and other evidence. A model must not independently make disposition decisions that affect individual rights.

Industrial Scenarios

Equipment inspection, production forecasting, energy optimization, and cross-factory collaboration should distinguish recommendation generation from on-site control. Initial deployment may use read-only access. Execution capabilities should be opened only under explicit permissions after risk assessment, simulation, or controlled testing. Production-control operations should retain human approval and safe rollback.

Evaluation Metrics and Validation Methods

5.1 Metric Definitions and Measurement Design

Security evaluation should measure control coverage, detection performance, business impact, and operational stability at the same time. Each metric should clearly define the evaluated object, denominator, dataset, runtime environment, and statistical window, avoiding the conflation of coverage, accuracy, success rate, and system availability.

TP: risk samples correctly identified; FP: normal samples incorrectly classified as risky; FN: risk samples missed by detection.

Cryptography and Data-Protection Evaluation

Cryptographic capabilities should be verified through inventories of algorithms and parameters, protocol configuration, implementation, and key-management checks; they should not be measured by model accuracy. Data residency should be verified against actual traffic, logs, caches, operations, and backup paths. De-identification effectiveness should be assessed together with re-identification risk.

All results should be associated with the versions of the model, prompt templates, knowledge base, tools, policies, and test environment. Reports should disclose failure cases and residual risks as well as successful results, rather than presenting only the best outcomes.

5.2 Testing Process and Evidence Management

Evaluation should proceed through scope definition, sample preparation, test execution, issue remediation, and retesting. Business, platform, and security teams should jointly confirm the pass criteria. Functions that do not meet the criteria should remain disabled or be limited to pilot scope.

Reporting Requirements for High-Confidence Metrics

Metrics such as 99.999% require a sufficient observation scale and clearly defined statistical methodology. The absence of failures in a small number of tests does not directly demonstrate the same performance in production. Reports should state the sample size, number of failures, test duration, load distribution, and estimation uncertainty, and should distinguish request success rate from time-based availability.

Evidence Package and Retest Triggers

The evidence package should include at least the test plan, environment inventory, input samples, expected outcomes, actual results, issue records, and retest conclusions. Access controls should be applied to sensitive samples and logs to prevent evaluation materials from becoming a new leakage channel.

When substantial changes occur to the model, knowledge base, tool permissions, routing policies, cryptographic configuration, or runtime environment, the affected controls should be reassessed. Audit findings, actual incidents, and new attack methods should also trigger updates to the test set and control policies.

Implementation Roadmap and Operational Governance

6.1 Phased Implementation Roadmap

Security capabilities should be developed progressively within a controlled scope, with each phase’s outputs mapped to verifiable acceptance criteria. The implementation period depends on system complexity, data sensitivity, the existing security baseline, and business risk; no uniform schedule should be set independently of project conditions.

[Figure 7 Phased Security AI Implementation Roadmap]

6.2 Operational Responsibilities and Delivery Requirements

Sustained security depends on clear responsibilities and executable operational processes. Every launch and change should confirm who defines business rules, who approves risky operations, who maintains technical controls, who retains evidence, and who has authority to suspend the service.

Mandatory Checklist for Release and Acceptance

Project delivery should include architecture and data-flow diagrams, an inventory of actual functions, permission and approval matrices, cryptography and key-management plans, test and disaster-recovery reports, log-retention rules, incident-response procedures, and a residual-risk register. Quantum-related functions should additionally include algorithm or device versions, applicable links, and dedicated validation materials.

Exception Handling and Continuous Improvement

When unauthorized access, abnormal export, tool misuse, or key incidents are detected, the relevant operations should be stopped according to risk, affected components isolated, necessary credentials revoked, and evidence preserved. Before recovery, confirm that the issue has been addressed and critical controls are effective. Post-incident review should be translated into updates to policies, test sets, and operational processes.

The value of Lingyan Miaoyu Security AI lies in keeping capability boundaries, execution processes, and validation evidence aligned. Product capabilities, business scenarios, and organizational responsibilities together form the foundation for trustworthy operation; no single technology can replace this system.

Appendix A Metric Validation Checklist

The numerical values from the original metric tables in this special chapter are retained below as inputs pending verification. They are not achieved product performance, committed targets, or acceptance conclusions. A project should first revise the metric definitions and determine applicability, then agree on targets and conduct testing. Metrics that are not applicable must not be repurposed directly as evidence of other capabilities.

A.1 Data and Key Metrics

A.2 Model Security Metrics

Validation focus: Key length alone cannot represent post-quantum security strength. Entropy values should specify the entropy type, unit, and estimation method. “Quantum validation” and “disturbance sensitivity” must define the specific mechanism and decision criteria. Data residency, de-identification, and audit coverage rates should define the complete population of objects.

A.3 Agent and Computing Metrics

Agent Security

Computing and Cross-Domain Collaboration

All percentage thresholds should be accompanied by the total sample size, failure count, statistical period, and applicable scenarios. Detection and blocking metrics should also report false positives for normal business activity. Millisecond-level latency metrics should define measurement start and end points, network distance, concurrent load, and percentile. Single-component test results must not be directly generalized to end-to-end business performance.

This page and the previous page are both checklists pending verification and do not indicate that Huazhi Future has implemented all quantum-related mechanisms listed in the tables or achieved the stated values.

A.4 Industry Metrics and Validation Records

A “100% compliance coverage rate” should correspond to a clear, applicable, and complete checklist, with item-by-item validation evidence. It is not equivalent to obtaining certification or to comprehensive compliance across all business activities. A “quantum-security validation success rate” should first define the validation object and mechanism; it must not be used as a substitute metric for diagnostic accuracy, risk-judgment accuracy, or production safety.

Recommended Validation Record Fields

Validation Status

Recommended status values are “To Be Defined,” “To Be Tested,” “Tested,” “Reviewed,” and “Continuously Monitored.” Only results that have been reviewed and have a clearly defined scope of applicability may be included in external technical specifications or project acceptance documents. Validity should be reconfirmed after changes to the environment or version.

Appendix B Terms and References

References

[1] Huazhi Future. Lingyan Miaoyu Special Chapter on Security AI Capabilities. Source material for this special chapter.

[2] Huazhi Future. Huazhi Future Lingyan Miaoyu Large Language Model Application White Paper. Reference for the system and content.

[3] NIST. NIST Releases First 3 Finalized Post-Quantum Encryption Standards, 2024. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards

[4] OWASP. AI Agent Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

[5] OWASP. LLM Prompt Injection Prevention Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html

[6] NCSC. Quantum networking technologies. https://www.ncsc.gov.uk/paper/quantum-networking-technologies

External materials are used as references for technical definitions and design principles and do not constitute certification or testing endorsement of Huazhi products.

FAQ: Lingyan Miaoyu Security AI White Paper

What is the Lingyan Miaoyu Security AI special chapter?

It is a special chapter on security AI capabilities released by Huazhi Future (Chongqing) Technology Co., Ltd. as a companion to the Lingyan Miaoyu Large Language Model Application White Paper. It explains how data protection, model security, agent governance, computing-resource coordination, and evaluation and audit work together, providing a unified framework for technical selection, solution design, project acceptance, and ongoing operations.

What are the four security boundaries enterprises should define?

According to the chapter: the data boundary (encryption alone does not mean data stays in-domain — inputs, outputs, vector indices, logs, caches, and backups must also be managed); the execution boundary (a model may propose a plan but must not grant itself permissions — high-risk operations require independent authorization and business approval); the result boundary (signatures and hashes detect tampering but cannot prove a model conclusion is correct — professional judgments need human review); and the security assurance boundary (cryptographic protection, system security, and industry compliance are separate layers that cannot be inferred from one another).

How does the chapter distinguish PQC, QKD, and QRNG?

Post-Quantum Cryptography (PQC) refers to cryptographic algorithms designed for quantum threats and implemented on classical devices, used for key establishment or digital signatures. Quantum Key Distribution (QKD) uses quantum communication mechanisms to generate and distribute keys, and requires dedicated equipment and links without replacing endpoint, application, or authorization protection. Quantum Random Number Generation (QRNG) provides random-number sources to cryptographic systems, with its entropy source and estimation method requiring explicit specification. Quantum-assisted computing is assessed separately and does not automatically provide resistance to quantum attacks.

Which industry scenarios does the chapter cover, and what does each emphasize?

Five scenarios: government (process and authorization accountability for policy Q&A, urban governance, and law enforcement assistance), financial (separating customer data from transaction permissions; models must not independently approve transactions or adjust credit limits), healthcare (patient information protection and professional review; models must not replace diagnosis or prescriptions), public safety (recognition results treated as leads requiring human verification), and industrial (read-only access first, with production-control operations requiring human approval and safe rollback).

How should the metric thresholds in Appendix A be interpreted?

All numerical thresholds in Appendix A — such as ≥99.999% success rates or ≤30 ms recovery switchover latency — are retained as inputs pending verification. They are not achieved product performance, committed targets, or acceptance conclusions. Projects should first revise metric definitions, determine applicability, agree on targets, and conduct testing with disclosed sample sizes, failure counts, and statistical methods.

Related Reading

• MAAS Technology Advancement
• MAAS Newsroom
• Maase Inc. Official Site

External materials cited in this chapter are used as references for technical definitions and design principles and do not constitute certification or testing endorsement of Huazhi Future products.

Huazhi Future (Chongqing) Technology Co., Ltd.
Security Architecture · Agent Governance · Industry Applications · Validation & Evaluation