The Five-Element Firewall Pipeline (McKinsey-Lily Worked End to End)

1. The Lead

You're a procurement officer or a CIO or a partner at a firm and somebody just put a quote on your desk for an AI platform. You have to sign by the end of the quarter. The vendor is good. The demo is good. The references check out. You have six weeks to decide whether the thing on the table is going to be the next Lily.

This post is for you. The architecture arc closes here. The four patterns I've been laying out across this series (agent-versus-human at the envelope, cells in the workflow, structured memory in the pump, structural firewall on the action) all converge on the question you're actually trying to answer at procurement, which is whether the platform is structurally safe or behaviorally safe. Whether it fails closed by design or fails open by oversight.

The Lily incident in February was the latter. The procurement decision that mattered happened twenty months before the agent walked through the SQL injection. Once that decision was made, the technical hygiene was already too far downstream to save anyone.

Here's the structure that would have saved them, named in full. Five elements. One worked case. Six questions you can put on the vendor's desk this week.

2. Five Elements

Our firewall pipeline has five layers. We named them after the Chinese five-element cycle because that's how they work in sequence, each one feeding the next.

Wood. The Manifest layer. Every tool, every endpoint, every command declares what it is. Read or write. Inbound or outbound. UI or API. Reversible or irreversible. Approval-gated or not. The manifest is shipped with the module. The platform refuses to load a tool whose manifest doesn't pass schema. Wood is the generative layer. Nothing happens without something declared.

Earth. The Registry layer. Once tools are declared, the registry holds them in a single source of truth, scoped to site, domain, project, workflow. The same tool can have different permissions in different scopes. The same agent can have different reach in different rooms. Earth centers. Earth keeps. The registry is what the firewall queries when it needs to know if a particular call is allowed in a particular context.

Metal. The Firewall layer. chmod-style permission bitset on every tool call. Read, write, execute, direction, interface. Five bits. The firewall checks the calling principal against the registry against the manifest before any command crosses into execution. Metal cuts. Metal separates. If the bits don't line up, the call doesn't fire. There's no override on the happy path.

Water. The Instructions layer. Behavioral specs as enforceable contracts, not policy docs. Each tool gets an instruction set that tells the AI when and how to invoke it, with explicit completion gates, examples, and a four-point structure (context, intent, examples, gate). The instructions are composed fresh on every request from a nine-layer stack: AL, security, domain, project, workflow, module, MCP, channel. Water flows. Water adapts. Same tool, different instructions per scope.

Fire. The Adapter layer. Provider-agnostic execution. The adapter is where the call actually lands against the model. Claude, GPT, Gemini, Bedrock, a local Llama. The adapter normalizes the wire format to the canonical envelope and back. Fire transforms. Fire executes. The safety guarantees from Wood through Water don't depend on which fire is burning.

Five elements, five jobs. Each one is a separate file in the codebase. Each one fails closed if anything upstream is missing. Each one writes an audit row when it fires.

Worth a moment on what this differs from. Traditional BPM tools (Camunda, Temporal, ServiceNow) are built around data: collecting it, transforming it, routing it through approvals, persisting the result. The ACL boundary in those tools lives at the data record. StoneForge is built around services, because AI agents call services. Every remote service or piece of remote data the AI touches, whether it's reading an email, fetching a SharePoint document, hitting a CRM endpoint, or pulling a row from a tenant's database, gets its own chmod bitset. The five elements wrap the call, not the record. That's the structural shift that lets an AI workflow safely traverse a hundred services where a BPM tool would route a hundred documents.

That's the architecture. Started last summer, well before McKinsey-Lily, Microsoft killing Copilot, or any of the cases that have since rolled in to confirm it. The Lily incident happens to be the most public worked example of the failure mode, so let's walk it through end to end.

3. Lily Worked End to End

Recap. February 2026. Codewall, a security research firm, ran an autonomous agent against McKinsey's internal AI platform called Lily. Two hundred API endpoints. Twenty-two of them shipped writable to production with no authentication. The agent walked through one, used SQL injection to escalate, got read-write access to forty thousand consultant accounts and every system prompt governing how the platform reasons. Two hours. Twenty dollars. No insider help. Responsibly disclosed March 9. The technical postmortem said "authenticate your endpoints."

Right answer to the wrong question. The right question is "what posture allowed twenty-two of two hundred endpoints to ship that way." Here's how each layer of our firewall pipeline would have answered it, in order.

Wood would have caught it at manifest load. Every endpoint in Lily would have shipped with a declared manifest. The manifest schema requires direction and interface bits. An endpoint with no auth and a writable verb would have declared permissions: rwxdi against the schema. The platform's manifest loader would have refused that combination unless the corresponding tool registration also declared approval: required on dangerous verbs. If the manifest was unsigned or malformed, the platform would have refused to load it at all. Wood is the layer where the question "is this a coherent thing we're agreeing to let exist" gets answered.

Earth would have caught it at registration. Even if a manifest passed, the registry would have placed the tool into a specific scope. The Gmail-import endpoints in our system land in module:gmail, scope:site. The Lily-style write endpoints would have landed in module:lily-core, scope:site as well. The registry exposes the same tool with different permission bitsets in different scopes; a tool scoped to "agent_context" gets different bits than the same tool scoped to "user_context." Earth is the layer where "who is this tool for, in which room" gets a row.

Metal would have caught it at the call site. When the Codewall agent's request hit the firewall, the firewall would have asked the registry "what is the permission for this call." The registry would have answered with a five-bit grid (rwxdi). The firewall would have compared the calling principal's bits to the tool's bits. An agent without write authority against a writable endpoint without the interface bit set for "agent" would have been rejected before SQL ever loaded. Metal is the layer where "do these bits line up" gets enforced. Metal is the layer Lily didn't have.

Water would have caught it at the instruction layer. Even if Metal somehow let the call through (it wouldn't have, but hypothetically), the AI's own instruction set for that endpoint would have included a completion gate requiring approval for any write operation in a non-admin context. The composed prompt would have included the security layer's mandatory rule: "Never invoke write or execute verbs against scope agent_context without explicit approval gate firing." Water is the layer where "did the AI know it shouldn't do this" gets answered with executable code, not a PDF.

Fire would have caught it at execution. The adapter would have logged the call with a full chain of custody: principal, scope, timestamp, manifest hash, registry hint, firewall verdict, instruction set hash. Even if every prior layer had been compromised (they couldn't have been, but Fire is also a safety net), the audit trail would have been complete enough that detection at incident-response time would have happened within minutes, not after February's quiet two-hour window. Fire is the layer where "what actually happened, in order, with provenance" gets a queryable table.

Five layers. Five separate failures that would have to all happen for the Codewall walk-through to succeed. Lily had none of them. Twenty-two of two hundred endpoints shipped because the platform's structural posture treated agent-grade access as a configuration concern instead of an architectural one. The fix isn't to authenticate the endpoints. The fix is to never let an endpoint exist without all five elements participating in its lifecycle. That's a procurement decision directly, not a sprint task.

4. The Buyer's Six-Question Checklist

If you're the procurement officer with the quote on your desk, here are the questions you put to the vendor this week. Not in a follow-up email. In the room. On the record.

Question 1: Does your platform structurally distinguish a human user from an AI agent at the envelope level, before any command is dispatched? A vendor who says "we have role-based access control" is not answering this question. RBAC is for users. The distinction has to be present in the wire format every command crosses. If the only difference between an agent calling an endpoint and a human calling an endpoint is the user-agent string, you have Lily-shaped risk. And if your AI platform assigns a single service account for the global AI system to use across every agent action and every user, you have Copilot-shaped risk on top of that. That might not be the dumbest idea, but it better hope the dumbest idea don't die.

Question 2: When the AI calls a tool, can you tell me, by code citation, the chmod-style permission bits applied to that call, in that scope, at that moment? If the vendor's answer is "we have permissions" without a bitset and a scope and a registry row to show you, they're describing wishful thinking. The five bits matter (read, write, execute, direction, interface). Anything fewer is selling you 1990s file permissions for a 2026 problem.

Question 3: What happens when your platform's safety configuration is left at defaults for two years and nobody touches it? The Lily question. Most vendors will answer with what the safe configuration looks like when fully tuned. That's the wrong answer. The right answer describes the default posture when nobody is paying attention. If the default is permissive, the platform fails open under pressure, and pressure is the universal eventual state.

Question 4: Can you, in under five minutes, revoke an agent's access from a console while it is mid-run? This is the kill-switch question. Not "delete the agent." Not "file a ticket." Not "wait for a redeploy." Revoke. Live. Through an interface that's on every operator's screen. If the answer is anything other than yes-with-a-demo, your incident response plan has a hole the size of every running agent.

Question 5: When something goes wrong, what does your platform hand the regulator? A transcript is the wrong answer. A pile of logs is the wrong answer. The right answer is a structured statement of action, authority, agent, and audit, per the AAAA framing in last week's post. Decisions made. By whom. On whose authority. With what proof. If the vendor can't produce a structured statement from a recent test case, they have storage, not memory, and you have to explain that to compliance later.

Question 6: Is the safety in the architecture or in the model? This is the lock-in question. If the vendor's safety story depends on which AI model is behind the curtain, you're locked into that model. When the model's vendor changes their safety commitments (and several have in 2026), your safety architecture goes with them. The right answer is that safety lives in the platform's structural choices, not in the model's training. The model is just another tool in the toolbox.

Six questions. None of them are technical hygiene questions. All of them are architectural posture questions. A vendor who can answer all six with code citations has built a platform that isn't going to be the next Lily. A vendor who can't answer them is selling you a transcript pretending to be memory pretending to be safety.

If you want the full architectural detail behind those six questions, including the cell-native communication protocol that the firewall pipeline sits on, RFC SF-005 dropped this week for Plank Owners. Foundation through firewall pipeline in one document, RFC voice, top-down architectural.

5. Why I Wrote This Down

Four patterns. Endpoints that don't know agent from human (Issue 003). State machines with AI in the boxes (Issue 004). Transcripts pretending to be memory (Issue 005). And now this one, the absence of a structural firewall pipeline behind the things AI is allowed to do (this post). Four foundational technical debts that the 2026 enterprise AI rollout is going to spend the next three years paying down through incidents.

I built the answer to all four because they're the same answer. The cell is the envelope. The workflow engine is the heart. The pump is the memory. The firewall pipeline is the action layer. Each one fails closed by design. Each one writes its own audit trail. Each one survives a provider swap, a model upgrade, a procurement rotation, and a regulator visit.

Same parking lot off I-10. Same fixed budget. Same Founding Members keeping the lights on while the platform reaches the customers who write the bigger checks. The architecture arc closes here, and the platform conversation begins. If you've been reading along, you have the buyer's-side framework for evaluating any AI platform on the structural-firewall test, including ours. Use it on us. Use it on whichever vendor put the quote on your desk. The framework doesn't care which side of the table you're on.

I'm fixing to spend the next stretch writing about what teams actually do with the platform once they have it. Cases. Recipes. The patterns that show up when a real operations team starts building inside the substrate. The architecture arc was the spec. The next arc is the product.

6. The Bridge

RFC SF-005, cell-native communication protocol, dropped for Plank Owners this week. The full architectural spec, foundation through firewall pipeline. Worked examples. Verb taxonomy. ACL grammar. Migration notes from the older protocol drafts. Authored over the last week. About sixty pages.

The next post is the start of the operations arc. First case study. First recipe. First what-it-looks-like-when-someone-actually-uses-this. The architecture arc was for the architect. The operations arc is for the team lead and the partner and the analyst.

If you're not yet a subscriber, the post you're reading is paid content the runway depends on. The link below sets you up at twelve dollars a month, or as a Plank Owner at the founding rate. Either tier gets you the operations arc and the SF-005 spec.

[CTA: Subscribe at $12/mo]    [CTA: Apply as Plank Owner]    [CTA: Read RFC SF-005]

Notes for the next pass

• Voice check: zero em dashes; "fixing to" used twice (§5 and §5 closer) which is at the high end of the sparingly rule; no "ostensibly/fundamentally/ultimately." Texan plain. Personal references in §5 only.
• Length: ~2200 words. Slightly longer than 004/005 because the worked Lily walkthrough in §3 needs five paragraphs to land each layer, and the buyer's-six-questions in §4 needs six paragraphs. Could tighten to ~2000 if you want; the §3 walkthrough has the most cuttable prose.
• Five-element brand callout: Wood/Earth/Metal/Water/Fire framing in §2 is RFC 95's actual element-naming. Use it consciously as brand vocabulary going forward; it's distinctive without being corporate.
• The Lily walkthrough is hypothetical-but-honest: §3 says "would have caught" for each layer; that's the correct framing because Lily didn't have these layers. Doesn't claim StoneForge was deployed at McKinsey; claims our architecture would have prevented their specific failure mode.
• The buyer's six questions: distilled from the Nate Jones briefing's "two questions" framing plus the four StoneForge differentiators. If Nate wants attribution language, easy add. If you want this six-question list ALSO published as a standalone one-page PDF for LinkedIn distribution, mark that as a parking-lot.
• Series closure in §5: explicitly names the four patterns from Issues 003-006. Reader who's been following has a complete diagnostic framework. Reader who jumped in late gets pointed back to the prior issues.
• Operations arc tease in §5 and §6: opens the next series without committing to specific topics. Cases, recipes, what-it-looks-like-in-production. Gives Founding Members a reason to stay subscribed past the architecture arc.
• SF-005 reference in §4 and §6: positions the spec as the architect-grade complement to the post arc. Three CTAs in the closer: subscribe, Plank Owner, read SF-005. Last CTA only valid if SF-005 is actually drafted and dropped same week as this post. If SF-005 slips, drop the third CTA and reuse the second.
• Optional diagram for §2: a five-element cycle diagram (Wood→Fire→Earth→Metal→Water→Wood). Could be Mermaid flowchart or a hand-drawn circle. The text carries it without a visual, but the diagram lands well if you want one for the deck/PDF version of this post.
• Distribution targets for this one: same as Issue 003 (HN, Lobste.rs, r/programming, r/aiagents, r/selfhosted, X tagging Lily-coverage accounts, LinkedIn warm DMs). Plus this one is procurement-officer-readable in a way Issue 003 wasn't quite — worth one targeted send to anyone in your network in CIO/procurement/compliance roles.