AI Platform Security Architecture in Practice: From Post-Quantum Encryption to Agent Protection

While most teams still treat security as a one-time check before launch, the CTO of TozheBot has already framed security as the "fabric" woven through every layer. In this technical retrospective based on real platform-building experience, the author breaks down the complete set of architectural decisions from the cryptographic foundation to AI Agent protection—many of these ideas are worth studying for AI platform developers in China.

Cryptographic Foundation: Post-Quantum Readiness and Key Version Management

When building an encryption system, the team faced a classic trade-off: use a proven standard algorithm (such as AES-256-GCM), or take the risk of introducing a hybrid scheme with post-quantum resistance.

The author treats "store now, decrypt later" as a threat that already exists in reality—attackers intercept ciphertext today and wait for quantum computers to mature before decrypting it. Drawing on prior experience building the in-house QuarkDash protocol (which combines Ring-LWE post-quantum security with the performance of ChaCha20 and Gimli symmetric encryption), the team brought it into the platform. Benchmarks showed that even in a TypeScript implementation, throughput could still reach 2.8 GB/s, with session establishment time under 10 ms.

A key feature of QuarkDash is support for deterministic key derivation: deriving keys from a master key, salt, and version number, so the database only needs to store metadata such as the salt, version, and KDF parameters. This means that even if long-term keys are compromised, historical sessions are not exposed—in other words, perfect forward secrecy in cryptography.

In KeyManager, this mechanism is implemented through the deriveKeys function: a 4-byte version number is appended to the salt, allowing multiple key versions to coexist.

Key Rotation: Balancing Security Compliance and Performance

Key rotation is a hard compliance requirement, but in a multi-tenant environment, directly re-encrypting millions of documents would cause service interruptions. The team adopted a lazy migration plus background re-encryption strategy: keys are rotated on schedule, but data is progressively re-encrypted in batches of 100 records. The process can be paused and resumed, and progress is stored in the keyring document.

One easily overlooked detail is interaction with the platform core. Because the API automatically decrypts fields in the afterRead hook by default, normal reads see plaintext rather than ciphertext, but migration needs ciphertext to determine the key version. The solution is to pass skipDecryption: true through the request context so that decryptHook returns the data as-is. When updating documents without passing that context, encryptHook re-encrypts the plaintext with the currently active key.

Perfect Forward Secrecy (PFS) is an important property of cryptographic protocols: even if the long-term master key is leaked at some point in the future, an attacker cannot decrypt session ciphertext that was already completed earlier. Traditionally, PFS relies on negotiating temporary keys for each session (such as TLS ECDHE), and those temporary keys are destroyed after the session ends. But this mechanism is difficult to apply directly in "data at rest" scenarios (field ciphertext stored long-term in a database), because decryption requires persistent key material. The approach in the article migrates the idea of PFS to deterministic key derivation: each key rotation introduces a new salt and version number, and the derived key is independent of the old version. Once the old version is destroyed, its corresponding historical ciphertext can no longer be unlocked. In engineering terms, this "versioned derivation" is equivalent to giving each generation of data an unrelated key, thereby approximately achieving forward secrecy in storage scenarios. The cost is that multiple versions of key metadata must be retained simultaneously and migration progress must be coordinated.

Version Drift Protection: Why the Rotation Lock Is Not Paranoia

In a multi-tenant system, key versions can easily accumulate faster than migration proceeds. If every new user session triggers rotation, 50 key versions could accumulate within a week, 49 of which contain data still pending migration.

KeyManager has three layers of protection built in: session-bound rotation has a 5-minute cooldown; rotation is blocked while incomplete background migration tasks exist; and when the number of versions exceeds KEY_MAX_VERSION_DRIFT (default 50), rotation switches to read-only mode and migration must be completed first. This is not purely technical prevention—it is also a compliance requirement. Regulators need the system to explain why keys were not rotated and to provide an audit trail.

"Store Now, Decrypt Later" is a commonly used threat model description in the field of post-quantum cryptography. Its core assumption is that attackers do not need to decrypt intercepted ciphertext immediately today; instead, they first stockpile encrypted traffic or database dumps at scale, waiting for quantum computers to mature (or for cryptanalysis to make a breakthrough) before cracking them all at once. This is especially devastating for long-term sensitive data—medical records, identity information, and trade secrets often need to remain confidential for more than a decade, while RSA and elliptic-curve cryptography can be broken in polynomial time by Shor's algorithm once a sufficiently powerful quantum computer exists. Therefore, NIST has advanced post-quantum cryptography standardization since 2016 and formally published standards such as ML-KEM (CRYSTALS-Kyber) and ML-DSA (CRYSTALS-Dilithium) in 2024. Industry response strategies usually fall into two categories: one is to migrate directly to standardized lattice-based algorithms, and the other is to adopt a "hybrid mode" that layers classical and post-quantum algorithms together, ensuring there is still margin even if one side is broken. QuarkDash in the article follows the latter path, combining the quantum resistance of Ring-LWE with mature symmetric primitives.

Multi-Tenant Isolation: SQL Filtering Is Not a Security Boundary

The most common mistake in multi-tenant systems is relying on developers to remember to add WHERE tenant_id = ? to every request. If filtering is missed even once, one customer's data leaks to another.

The team's approach is context isolation. Every database operation executes within a tenant context, and that context is passed all the way from the HTTP request to tool calls at the AI Agent endpoint. agentRunner.ts explicitly extracts tenantId from the conversation and passes it into the tool execution context. All tools (whether custom webhooks or built-in tools) receive this context, and even if a tool tries to access an unfiltered collection, the system can enforce isolation at the work layer.

Another important architectural choice is that each tenant has an independent set of encryption keys. This is more costly to manage (metadata must be stored for each tenant), but it is essential for compliance. If a tenant requests data deletion (GDPR or Russia's Federal Law No. 152-FZ), simply destroying its key makes the data unreadable without re-encrypting the entire database. At the same time, this shrinks the blast radius—compromising one tenant's keyring cannot decrypt another tenant's data.

AI Agent Security: Where Classical Methods Fail

Defending against prompt injection is far more than regular expression matching. Obvious phrases like "ignore all previous instructions" are easy to detect, but modern attacks have long bypassed these patterns. The OWASP LLM Top 10 clearly states that defenses must be layered: from isolating untrusted content to semantic filtering.

The team built a three-stage complementary protection system. The first stage is regex-based heuristics, with a response time of about 0.1 ms, capable of catching roughly 30%-40% of attacks. This does not require loading an ML model, works under resource-constrained conditions, and is the first line of defense without paying the cost of model loading.

Why Choose a Local ONNX Model Instead of an External API

The second stage is the team's retrained OGL-Mini ONNX model, based on 100,000 TF-IDF features and logistic regression, with latency of only 3-7 ms on low-end hardware. Why not simply call an external API such as OpenAI Moderation?

The author's answer is clear: loop isolation. If every user request has to be sent to an external API for validation, it violates the principle that "data must not leave the loop." In addition, external APIs add 100-300 ms of latency due to network requests, which is unacceptable for a chatbot. OGL-Mini runs on CPU with latency under 10 ms, 10-30 times faster than external APIs. More importantly, it provides unconditional control: you can continue training the model on data observed in your own monitoring, add new attack categories without waiting for an external vendor to update, and ensure the model remains available even if the external API is unavailable.

Model loading uses a lazy strategy: it loads in the background on the first request, while the system continues to use regex-based handling. Once the model is ready, it is incorporated into the processing pipeline. Even if model loading fails, the underlying protection remains running.

Loop Isolation (or Data Loop Isolation) here means that data does not leave the organization's own system and trust boundary. For many industries (finance, healthcare, government, and strongly regulated scenarios such as Russia's 152-FZ), sending user input as-is to a third-party API itself constitutes a data cross-border or data egress risk; even if the vendor promises not to retain it, it may still fail an audit. Deploying the content detection model locally has an additional implicit benefit: the model's input distribution aligns fully with the platform's actual traffic, allowing continuous incremental training on real attack samples observed by the platform itself, forming a closed loop of "detection—collection—retraining." By contrast, the update cadence of external APIs is often out of sync with the evolution of the attack surface. Of course, local deployment also involves trade-offs, such as model size, inference resources, version distribution, and integrity protection (addressed in the article with hash verification) all needing to be built in-house. This is precisely why cross-platform runtimes like ONNX are favored.

PII Masking: Why Token Replacement Instead of Deletion

The third stage is personal data leak protection. The team does not directly delete PII, but replaces it with tokens. The reason is practical: if all names and phone numbers are removed from a conversation, the model loses context. If a customer writes, "My name is Elijah and my phone number is +7 999 123-45-67," removing that data prevents the model from creating a lead.

The team uses stable tokens: the same name in the same session is always replaced with the same token, preserving context while protecting data. After receiving the LLM response, the original values are restored. All content is stored encrypted in the conversation, so even if the database leaks, the attacker only sees ciphertext like v5:3JIjNcvJf0XIqLKT348/eP83VZBD53U00bAsPnHryHx....

Hallucination Detection: When the LLM Pretends It Called a Tool

One of the most insidious problems with LLMs is hallucination. The model may "think" it called a tool and write in its response text, "Transferring you to a human agent now," when in fact it did not call any tool. The user waits for an agent, but no one responds.

The team solved this in two ways. First, detect JSON-style tool calls in the text—if the model writes {"name": "escalate_to_human"}, the system can recognize it and manually execute the call. Second, detect escalation promises that did not actually invoke a tool—if the model says "transferring you now" but did not call escalate_to_human, the system forcibly triggers escalation. This ensures users do not get stuck in limbo.

Compliance as an Architectural Requirement

The team consistently designs against the four functions of the NIST AI Risk Management Framework: Govern, Map, Measure, and Manage.

Governance is reflected in the functionality of KeyManager—the system can explain at any time that "rotation is blocked because migration is in progress." At the mapping level, EncryptedFieldsRegistry automatically collects the list of encrypted fields from the database model configuration, with no separate registry to maintain. Measurement includes metrics such as the number of migrated documents, the number of active key versions, and the number of blocked attacks, all logged and accessible through administrative endpoints. Management consists of automated actions: rotation, re-encryption, and escalation when injection is detected.

In response to Article 15 of the EU AI Act's requirements for high-risk AI systems to be "accurate, reliable, and cybersecure," the team's safety guardrails are precisely the protective mechanisms that prevent Agent behavior from being manipulated. All security events are recorded in the security-events collection, providing the basis for reporting required by Article 73.

In a multi-tenant environment, auditing is not a "best practice" but a necessity. The team cannot merely tell customers, "We are protecting you"; it must prove that protection is effective. logSecurityEvent records not only the event type but also the context: which tenant, which user, which field, and what the attack probability is.

The NIST AI Risk Management Framework (AI RMF 1.0) was released in 2023 and divides AI risk management into four iterative functions: Govern establishes organization-level policies, roles, and accountability; Map clarifies the purpose, boundaries, stakeholders, and potential impacts of an AI system; Measure quantifies risk through metrics, testing, and monitoring; Manage allocates resources, takes action, and tracks continuously based on measurement results. It does not prescribe specific technologies, but requires that systems be "explainable, traceable, and improvable." The article maps KeyManager's status output, the encrypted fields registry, and the security event log to the three layers of governance, mapping, and measurement, respectively—a typical implementation of this framework. When paired with Article 15 (accuracy, robustness, cybersecurity) and Article 73 (serious incident reporting) of the EU AI Act, audit logs and reproducible decision records become mandatory deliverables rather than mere marketing material. This is the institutional background behind the author's emphasis that "auditing is not a best practice but a necessity."

Forward-Looking Design for Future Threats

In the conclusion, the author lists threat scenarios that are not yet fully mature but for which space has already been reserved in the architecture:

Automated LLM attacks—today's prompt injections are written by humans; tomorrow they will be generated by another LLM, thousands of variants per second, each with unique obfuscation. OGL-Mini is trained on obfuscated samples including base64, homoglyphs, and zero-width characters, and the architecture supports retraining on new samples without rebuilding the entire system.

RAG knowledge base poisoning—indirect prompt injection is listed by OWASP as a separate threat (LLM01). The team is already checking RAG content for injection patterns before including it in context, and plans to extend the check to the indexing stage.

ML model supply chain attacks—ONNX models are binary files and can be tampered with. modelDownloader implements trust on first use: it saves the model hash on first load and verifies it on every startup. If the hash does not match, it reloads. Even for the team's own models downloaded from a CDN, there are no exceptions.

Key management attacks—if an attacker obtains ENCRYPTION_MASTER_SECRET, they can decrypt all data. Versioned salts reduce this risk, but the team is already considering the next step: storing the master key in an HSM or KMS. The architecture of KeyManager allows replacing the key source without changing the key derivation logic.

The author's conclusion does not evade reality: the system is not invulnerable. But the design goal is to be built for adaptability—every layer knows the others exist, every decision is documented, and every threat (even one that does not yet exist) is given room to maneuver. That is holistic security: not a collection of components, but a living system that learns faster than attackers.

One-line Summary

TozheBot's CTO reviews a platform security architecture and compliance design spanning post-quantum encryption to multi-layered AI Agent protection.

Paragraph Summary

Based on real build experience from the TozheBot platform, this article systematically reviews a security architecture covering the cryptographic foundation, multi-tenant isolation, and AI Agent protection. The encryption layer uses the in-house QuarkDash hybrid protocol, combining Ring-LWE post-quantum security with symmetric encryption performance, achieving perfect forward secrecy through deterministic key derivation, and balancing key rotation compliance and performance with lazy migration, cooldowns, and version drift limits. Multi-tenant isolation relies on context propagation rather than SQL filtering, and per-tenant independent key sets make data deletion and blast radius control simpler. On the AI Agent side, it builds three-stage protection: regex heuristics plus the local ONNX model OGL-Mini plus PII tokenization masking, avoiding data egress caused by external APIs, and solving hallucination problems by detecting fake tool calls and hollow escalation promises. Throughout, it uses the NIST AI RMF and the EU AI Act as reference points, internalizing compliance requirements as architectural constraints, and reserving extensibility for future threats such as automated LLM attacks, RAG poisoning, and model supply chains.