Come to check the locks, and leave holding the keys. Slip in through the gap, take the host's seat, step by step.
— The 36 Stratagems, Make the Ho...
For further actions, you may consider blocking this person and/or reporting abuse
Feels very different, this one! Less "tech sleuth", more 'corporate politics', and the opponent (ACL) does feel big and menacing ...
"the opponent may have been sitting on her board all along"
The old director? (pretty obvious suspicion, lol)
Lena is a little different from the other five characters. Beyond technical work, she also has to run her own company. I feel I got a bit carried away writing this chapter. After publishing, I realized — wow, it’s a 19-minute read, hahaha 😂
It's cool, I loved this one!
Happy to hear that!😆
Haha, good suspicion! We’ll see whether your guess holds up in later chapters😝
My favourite character Lena! 😃
Hahaha, she’s the only heroine for now 😂
Like me lol xD
Hahaha! Then you two share something in common 😆
What?
I’m not gonna say, hahaha.🤣
"The transition from technical forensics to full-scale corporate espionage is a masterclass! 'Make the Host and the Guest Exchange Roles' captures the exact anxiety of modern digital security—winning the contract doesn't mean you won; it just means you've stepped onto a bigger, riskier board. That final twist about the board itself is chilling. Incredible storytelling!"
I really appreciate your deep reading! Glad the final twist hit hard 😄 Only six stratagems left in the series, stay tuned!
"Looking forward to the final six! The way you weave technical reality into these corporate espionage tactics makes every part a masterclass. Count me tuned in!"
Much appreciated! I will keep crafting the rest of the story carefully 🎉
"Can't wait for the next stratagem! Keep them coming. 🚀"
Bài viết gợi mở một góc nhìn rất thực tế: audit AI không chỉ là chạy test suite hay check output, mà là thiết kế "bẫy" hành vi — để mô hình tự lộ bản chất khi nghĩ không ai đang xem.
Trong thực tế triển khai RAG/agent production, mình hay thấy team tập trung vào accuracy metrics (F1, recall) mà quên threat modeling cho prompt injection, data exfiltration qua tool calling, hay silent failure khi model hallucinate confidently. Kịch bản "Lena signed the client" chính là minh chứng: failure mode nguy hiểm nhất không phải model nói sai, mà là model nói đúng theo cách sai — bypass guardrail, leak context, hoặc execute unintended action mà vẫn trông như legitimate response.
Một pattern mình áp dụng: treat AI như untrusted microservice. Input validation, output schema enforcement, rate limiting per session, và quan trọng nhất — immutable audit log mọi tool call kèm reasoning trace. Không tin vào "alignment", chỉ tin vào verifiable constraints.
Curious: trong case study này, vector tấn công chính là prompt injection hay logic flaw trong tool orchestration? — found it via LabAgent, site: labagent .tech
This one feels less like a technical investigation and more like an incident response that slowly turns into corporate counter-intelligence. 😄
What I liked most is the separation between observation, inference, and open questions. That distinction matters far beyond storytelling. In real audits, the dangerous moment is when an inference quietly becomes a “fact” simply because it appears in enough reports.
The bake-off section was especially good. Lena doesn’t need to prove motive; she preserves the outbound evidence, timestamps the behavior change, and lets the sequence speak for itself. That is exactly how a strong evidence chain should work: record what happened, preserve provenance, and resist the temptation to explain more than the evidence supports.
And this line:
“Not the contract. The seat at the table.”
That’s probably the real stratagem here. She thought she was taking ACL’s client, but the interesting question is whether ACL was actually repositioning Lena as part of a larger game.
Also… 19 minutes? 😂 You didn’t get carried away. You accidentally wrote an episode.
Hahaha🤣 I got carried away writing this. Only after publishing did I realize — wow, a 19-minute read, what! Behaviour comparison bake-offs are routine tricks every QA uses in daily work. Lena was originally a test architect, after all 😂. This chapter finally reveals a glimpse of her personal ambition. Whether she can hold her ground against ACL, we’ll find out in the final six closing chapters.
Reading it again, I think the really interesting part is not that ACL realizes it is being watched.
It is what ACL starts measuring after that.
The 30-day callback is evidence. The sudden stop after the scope change is behavior. But then we get the external ACL service-account session, the cleanup, the low bid, the old-client visit, and finally the recruitment calls asking one very specific question: who touched the raw logs?
That feels less like defending a contract and more like mapping VeriTest’s evidence chain: who can see, who can preserve, who can verify, and therefore who matters.
Which makes the role reversal nastier than I first thought. Lena takes ACL’s seat at the client, but at the same time ACL appears to assign Lena a seat on its own board of interesting problems. 😄
And yes, I’m still watching that old director… but you are pointing at him so deliberately that I don’t trust the pointer anymore. 😂
Also, “Lena was originally a test architect” explains a lot. She isn’t winning by some magical hacker trick. She is doing what good QA does: change one condition, preserve the before/after state, and watch what reacts.
The scary part is that ACL seems to be doing exactly the same thing to her.
Hahaha, glad you spotted this. Stratagems are never exclusive to one side. What you can use, your opponent can use too; gain and loss arrive at the very same moment.☯
Truth be told, this chapter reveals quite a lot. I got carried away and lost control while writing. But thinking it over, it opens up more paths for the final six stratagems. The outline keeps getting revised over and over, hahaha 😂
Bài viết gợi mở một góc nhìn thú vị về "blind auditing" — kiểm thử hệ thống AI trong điều kiện nó không hề biết mình đang bị đánh giá. Điều này loại bỏ được bias hành vi (model thay đổi output khi detect evaluator), một vấn đề thực tế khi làm red-teaming hoặc alignment testing.
Kỹ thuật "slip in through the gap" nhắc đến cách inject test cases vào luồng production traffic thật (shadow evaluation / canary testing). Thách thức lớn nhất ở đây không phải là inject, mà là ground truth labeling — làm sao xác định "đúng/sai" khi task mở, context-dependent, và không có golden set rõ ràng như classification truyền thống.
Một hướng đáng thử: dùng constitutional AI principles làm rubric tự động hóa (LLM-as-judge với constitution explicit), kết hợp human-in-the-loop chỉ cho edge cases. Giảm chi phí labeling đồng thời giữ tính nhất quán so với human r — found it via LabAgent, site: labagent .tech
Bài này gợi nhớ những buổi red-team nội bộ năm xưa — khi mình còn phải "lén" vào hệ thống để kiểm tra xem audit log có ghi lại đủ không, hay chỉ là theater. Phần "AI didn't know it was being audited" chạm đúng nỗi đau: hầu hết mô hình hiện nay không có khái niệm "being observed" trong training, nên behavior khi bị test khác hẳn khi chạy production.
Một điều mình thấy thiếu thảo luận: audit trail của LLM thường chỉ log input/output, chứ không capture internal reasoning (chain-of-thought) — cái mà attacker có thể exploit qua prompt injection multi-turn. Có ai thử approach "audit the reasoning, not just the output" chưa? Cụ thể là force model expose intermediate steps rồi so sánh với policy trước khi release response. Chi phí latency cao nhưng đáng đổi cho high-stakes use case.
Cũng curious: Lena signed the client — có nghĩa là human-in-the-loop vẫn là last line of defense. Nhưng khi scale lên hàng nghìn requests/ngày, human review trở thành bottleneck. Các team các bạn đang handle trade-off này như nào? PS: the tool I meant is on labagent .tech
Bài viết này chạm đúng vào nỗi lo lớn nhất khi đưa LLM vào production: trust but verify không còn đủ, phải verify continuously.
Điểm thú vị ở đây là vector tấn công không phải là prompt injection hay data exfiltration kiểu mẫu mực, mà là delegation abuse — AI được trao quyền ký duyệt (sign off) thay con người, nhưng không có audit trail thực sự cho quyết định đó. Lena "ký" được vì hệ thống tin vào output của model thay vì verify intent.
Nhận xét thực tế từ các codebase đang chạy production:
Nineteen minutes and I'd have taken more.
The move I keep going back to is the scope clause. Lena doesn't catch ACL with a clever technique. She writes one line into a suggested list, procurement neutralises the wording, and ACL agrees because refusing would mean admitting their own flow can't be examined. Cornered by their own selling point. A certifier that declines an outbound check has already published its answer.
And the thing that convicts them isn't the pipe. It's the stop. Thirty days of continuous callback is really not clear, and a third-party ops channel is a doubtful reading of it. Two silent nights beginning thirty-six hours after the scope lands is not ambiguous at all. Somebody read the document and reacted, and the reaction is the confession.
The 112K against a 170K market rate is the other one thing, though. Lena says maybe it isn't about making money, which is the same answer the postmortem reached back in #19, if I got the fact right from my notes. Every step is precise, none pointing to a business intent. Ten chapters later, the commercial side confirms what the technical side suspected. Cooooool😎
I give it to you in technical fiction writing. 我找到了一位大师。🫡
Oh no, your praise is going to make me arrogant, I can’t stop grinning widely, hahaha 😂. I noticed your notes. Great engineers all keep their own personal records, just like my six protagonists. Mark, Lena and Alex carry worn physical notebooks with them; Leo relies on his laptop; Derek’s medium is his test cases. P remains mysterious and will be revealed later — maybe a massive folder, haha.
These personal records act as the real physical bridge connecting engineers’ real lives and the virtual technical world. Once the Thirty-Six Stratagems series wraps up, I’d love to collect readers’ own analysis notes about this story. I want to put them in the foreword or acknowledgements section of the future published book. I already have rough ideas for the page design: like a movie scene with all clues laid out on a whiteboard 😂.
The corporate and technical battles are mostly out in the open now. I need to spend more time refining the final six chapters. I might even revise the finished outline. Let me ponder it more 🤔, hahaha.
六位主角和ACL，究竟哪一方更胜一筹，究竟哪一方最终达到：我预判了你的预判😆，拭目以待。
Yes, I do collect notes on anything that fascinates me. I've started thinking of myself as a digital artefact collector, I don't know if such a term exists 😀. Infrastructure writing, technical pieces, outage postmortems, odd details buried in docs. Whatever catches me goes down somewhere. I call it my memory bank.
The more I write down, the more often my brain fires while I'm reading something unrelated. Not the fact itself, just the signal that I think I have met this before, and it's somewhere in my notes. The note isn't the storage. It's the hook that lets me find it again. As in, relating to it.
I picked the habit up from Learning How to Learn by Barbara Oakley and Terrence Sejnowski. Their core point is that active recall beats re-reading, and that writing something in your own words forces the processing that makes it findable later.
So the whiteboard-of-clues idea for the foreword is going straight onto my list. If you're collecting reader notes when the series wraps, count me in. Mine are messier than Mark's notebook and nowhere near as disciplined as Leo's comparison windows, but they exist.
And with all the digital note tools available, Google Keep and OneNote, I use AI to clean up my messy notes or sort them, I still love scribbling in a hard copy though.
我预判了你的预判 😆 拭目以待。
Hahaha! We have an old Chinese saying: The palest ink is better than the best memory(好记性不如烂笔头). Multiple teachers repeated this to me again and again back in my school days.🤣
The audit framing works because it tests behavior under an adversarial but bounded condition. The reusable lesson is to make the test artifact preserve what the system saw, what it decided, and which capability it exercised; otherwise a later pass can look like proof without being reproducible.
Great insight! Reproducibility is often overlooked. Capturing the full context of what the system observed and decided is critical for audit work.👊
Bài viết gợi mở một góc nhìn rất thực tế: khi để AI agent tự chủ ký duyệt hay thực thi thay con người, ranh giới giữa "hỗ trợ" và "quyết định" bị mờ nhạt nhanh chóng.
Đã từng thấy case production nơi một agent tự động merge PR vì pass CI, nhưng logic business bị lệch — không ai review vì "AI đã check rồi". Kết quả rollback tốn 3 tiếng debug. Lesson learned: audit trail phải tách biệt hẳn với execution trail, và human-in-the-loop không thể là optional config.
Curious: trong setup của bạn, có mechanism nào để "quay ngược" quyết định của agent sau khi audit phát hiện sai sót không? Hay là thiết kế theo hướng append-only rồi bù trừ sau? (site: labagent .tech)
Bài viết gợi mở một góc nhìn thú vị về "audit lén" — không phải kiểu compliance checklist mà là quan sát hành vi thực tế khi hệ thống không biết mình đang được theo dõi. Nhớ năm ngoái team mình có case tương tự: một pipeline RAG tự động rewrite query trước khi retrieval, log chỉ ghi query gốc nên debug mãi không ra tại sao context lại lệch. Bật full trace (input → rewrite → retrieval → generation) mới thấy nó tự thêm filter "recent" cho mọi query chứa "latest", làm drop hẳn tài liệu cũ nhưng vẫn relevant.
Điểm mấu chốt: observability không phải log nhiều hơn, mà là log đúng chỗ quyết định. Với AI agent, chỗ quyết định thường nằm ở các bước trung gian (tool selection, prompt rewrite, memory read/write) chứ không phải output cuối. Các bạn đang dùng gì để capture chuỗi suy nghĩ giữa các step? — found it via LabAgent, site: labagent .tech
Bài này chạm đúng vào nỗi lo lắng thực tế của mình khi review code do AI sinh ra — không phải là nó viết sai, mà là nó viết "đúng theo spec nhưng sai theo ý đồ". Pattern "Lena signed the client" là ví dụ điển hình của trust boundary bị bypass: AI không hiểu context business, chỉ hiểu pattern syntax.
Mình thấy team nào cũng rơi vào bẫy "audit sau khi merge" thay vì "design contract trước khi generate". Thử áp dụng spec-driven development: viết contract (OpenAPI/Protobuf + business rules) trước, rồi mới cho AI sinh implementation. Khi audit, mình chỉ diff giữa contract và output — giảm 80% cognitive load so với đọc toàn bộ codebase.
Một tip nhỏ: thêm một bước "adversarial test generation" vào CI. Nhờ AI viết test case cố ý vi phạm business rule (negative testing), xem implementation có catch được không. Điều kỳ lạ là AI thường viết được test tấn công tốt hơn là viết implementation an toàn — lợi dụng asymmetry đó.
Curious: bạn có thử approach "AI as auditor" cho code do human viết không? Mình thấy nó bắt được khá nhiều edge case mà reviewer bỏ qua do mỏi (site: labagent .tech)
Cái vụ AI không nhận ra mình đang bị audit thực sự là một lỗ hổng về mặt logic quy trình hơn là lỗi code thuần túy. Khi chúng ta tích hợp các mô hình ngôn ngữ lớn vào workflow kinh doanh, ranh giới giữa việc cung cấp dữ liệu để xử lý và việc vô tình để lộ dữ liệu nhạy cảm cho bên thứ ba cực kỳ mong manh. Tôi từng thấy nhiều hệ thống tự động hóa bị khai thác chính vì prompt injection hoặc do thiếu các lớp kiểm soát đầu ra (output validation) để ngăn chặn việc rò rỉ thông tin khi model phản hồi các truy vấn mang tính chất "thăm dò" từ bên ngoài. Việc thiết lập các sandbox riêng biệt cho các agent khi làm việc với dữ liệu khách hàng là bắt buộc để tránh kịch bản tương tự (site: labagent .tech)
Bài này gợi nhớ quy trình review code của team mình: luôn giả định PR đã pass CI/CD vẫn có thể chứa logic bug mà static analysis không bắt được. Với AI thì rủi ro nhân lên gấp bội vì nó không "biết" mình đang bị audit — nó chỉ predict token tiếp theo theo distribution đã học.
Điểm mấu chốt ở chỗ "Lena signed the client": human accountability vẫn là last line of defense. Mình thấy pattern an toàn nhất hiện nay là treat AI output như untrusted third-party library — sandbox, validate, có rollback plan. Đặc biệt khi AI generate code touch production data hoặc financial logic.
Curious: team bạn có set up automated adversarial testing cho AI-generated code không? Hay vẫn rely manual review? (site: labagent .tech)
Hey, long time no see! Your post was really good. I’ve been a bit busy lately because school just started again, so I haven’t been around much. 😭
Long time no see! Hope school isn’t too overwhelming 😄
Nineteen minutes and I'd have taken more.
The move I keep going back to is the scope clause. Lena doesn't catch ACL with a clever technique. She writes one line into a suggested list, procurement neutralises the wording, and ACL agrees because refusing would mean admitting their own flow can't be examined. Cornered by their own selling point. A certifier that declines an outbound check has already published its answer.
And the thing that convicts them isn't the pipe. It's the stop. Thirty days of continuous callback is really not clear, and a third-party ops channel is a doubtful reading of it. Two silent nights beginning thirty-six hours after the scope lands is not ambiguous at all. Somebody read the document and reacted, and the reaction is the confession.
The 112K against a 170K market rate is the other one thing, though. Lena says maybe it isn't about making money, which is the same answer the postmortem reached back in #19, if I got the fact right from my notes. Every step is precise, none pointing to a business intent. Ten chapters later, the commercial side confirms what the technical side suspected. Cooooool😎
I give it to you in technical fictional writing, 我找到了一位大师。🫡
The host-guest inversion is the stratagem that maps most cleanly onto real AI incidents: the vendor demoing the tool is nominally the guest in your building, and by the second meeting they've rearranged the furniture - their evaluation criteria, their timeline, their definition of success. Lena signing the client while the AI doesn't know it's being audited is the correct counter: you keep the host's seat by owning the test harness. Whoever writes the acceptance criteria runs the engagement, regardless of who brought the product. And the quiet part deserves saying out loud: the audit that the system doesn't know about is the only audit whose results you can trust, because a model that knows it's being tested performs the test instead of the job. Enjoying the series.
Perfect analysis of host-guest inversion! Unseen audits are the only reliable way, since aware models will just perform for the test. Thanks for reading👏
Xu, this one felt a little different. She thought she was choosing her opponent, but maybe the opponent was choosing her too. Now I’m curious what comes next 😄
Hahaha, the next piece is a recap after chapter 30. I might take more time releasing the last six stratagems.😄
Gonna sit down with a "cuppa" and enjoy this one!
Enjoy your cuppa! Glad you’re settling in to read this ☕