Return to Part 0: Table of ContentsPrevious Article: Part 36, Who Holds the Undo?
One hundred and eighty-nine days.
That is how long a promise in this book has been waiting. On 16 April 2026, Chapter 10, "Explainable Zero Trust," set out three separate jobs at the reasoning layer of an AI agent. Observability captures technical execution: what the agent did, how fast, against which services. Logic Logging records the reasoning so a decision can be reconstructed afterwards. And the Logic Firewall "inspects and can interrupt agent reasoning chains before they produce actions."
Chapter 10 defined the first two in depth. It pointed to later chapters for the other two. It gave those chapters numbers, and the numbers went to other topics as the book grew. Thirty-six chapters on, the firewall still had no chapter of its own.
This is it. It is also the last chapter of this book. Almost everything the book has built turns out to be an input to this one checkpoint.
The moment that matters
An agent's run has a shape. It receives a task, plans, reads, and reasons. At some point it decides to do something: call an API, write a file, send a message, change a permission. Everything before that decision is thinking. Everything after it is consequence.
Most agent controls sit at one end or the other. Identity controls act at the start: they decide whether this agent may begin at all. Audit acts at the end: it tells you what happened. Both are necessary. Neither can stop a single bad action in the middle of an otherwise legitimate run.
Chapter 36, "Who Holds the Undo?", made that concrete. A task approved as harmless can generate a dangerous action halfway through. Its rule was to classify actions, not tasks, and check every action against a registry at runtime. That rule needs a place to run. The Logic Firewall is that place.
Here is the definition the book has used since Chapter 10. It is an active governance mechanism that inspects and interrupts agent reasoning before action. In engineering terms, it sits in the path between the agent's decision and the tool call that carries it out. In practice that means a tool gateway, an MCP proxy, or the runtime hook your agent framework exposes before a tool executes. Chapter 31, "A Firewall for a Protocol Nobody Told You Was on the Network," dealt with finding agent protocol traffic on the network at all. The Logic Firewall works one layer up. It does not ask whether this is agent traffic.
Four inputs
The checkpoint needs four things in hand before it can rule on a proposed action. Each is something an earlier chapter built.
Who is acting. Chapter 12, "The Sixth Pillar," argued that agent identity is the perimeter: every agent holds a verifiable identity, scoped authority and an accountable owner. If the firewall cannot tell which agent is calling, it is filtering anonymous traffic, and everything after this line is guesswork. Part Four spent four chapters on exactly this problem.
What it was asked to do. Chapter 19, "The Delegation Problem," and Chapter 20, "When Agents Delegate to Agents," dealt with authority that arrives second-hand, from a user to an agent and from one agent to another. The firewall's version of that authority is a task declaration: what the task is for, which systems and data it may touch, and when it expires. An action outside the declaration is out of scope however reasonable it looks. The firewall checks the agent's behaviour against what was asked, not its own idea of what would help.
What it currently holds. Simon Willison named the lethal trifecta on 16 June 2025. An agent that combines access to private data, exposure to untrusted content and the ability to communicate externally can be steered into leaking what it holds. Chapter 29, "The Trust Boundary Is the CI Runner," paired that with Meta's Agents Rule of Two (31 October 2025): an unsupervised session should not hold all three at once. The firewall is where that count is kept. It knows what the session has read, what it can reach, and whether the proposed call would complete the set.
Whether the action can be taken back. Chapter 36 gave every action type a tier, from Tier 0 (routine and reversible) to Tier 3 (blocked outright). It also set the test for the hardest column: an action is reversible only if the party acting holds a tested means of undoing it. The registry assigns the tier. The firewall reads it at the moment of the call.
Identity, delegation, capability, reversibility. Four chapters' worth of design, consulted in the few milliseconds between decision and execution.
Four outcomes
A firewall that can only say yes or no gets switched off. The first time it blocks something a business owner needed, someone widens the rule until it blocks nothing. So the Logic Firewall has four answers, not two.
Allow. The action is in scope, the session's capability count is within limits, and the tier permits it without a human. Most calls should typically land here. If they do not, the task declarations are too narrow or the registry is misclassified, and both are findings.
Allow, degraded. The action is permitted in a narrower form: read instead of write, a draft instead of a send, a smaller result set, a shorter credential lifetime. Degrading keeps work moving while removing the part that cannot be taken back.
Hold for approval. The action waits for a named human. Chapter 36 set when: Tier 2 actions, and any action caught by one of its five runtime triggers. The firewall is what makes the hold real. Without it, "requires approval" is a line in a policy document that the agent never reads.
Block. The action does not execute, and the run is told why. Tier 3 actions land here, as does anything that would complete the trifecta in an unsupervised session.
Every one of the four outcomes writes a record. That is where Logic Logging comes back in, and where this chapter turns to the half of its brief that Chapter 10 also left open.
Observability is what makes the checkpoint honest
Chapter 10 drew the line carefully, writing that "you can have observability without Logic Logging". You know the system is running, but you cannot reconstruct a specific decision for audit. The reverse is also true. It matters more here. A Logic Firewall without observability is enforcing rules against a picture of the agent that nobody has checked.
Two of its four inputs are dynamic. What the session currently holds changes every time the agent reads something. Whether a runtime trigger has fired depends on what the agent has been doing for the last few minutes, not on what it was approved to do this morning. Both come from telemetry. If the firewall cannot see each tool call, its arguments, its result and the task it belongs to, it cannot keep the capability count. The Rule of Two becomes a claim rather than a control.
The engineering for this is arriving, unevenly. OpenTelemetry's semantic conventions for generative AI live in a dedicated repository, separate from the main conventions, with no tagged release as at 21 October 2026. The repository's own documentation defines invoke_agent as the operation covering the run and execute_tool as the operation covering each tool call. Every one of its seventy-nine gen_ai.* attributes is marked "Development," meaning names can still change. A practitioner account published in July 2026 models the same run as a tree of spans and reports the identical status. That corroborates a standard still moving under the people trying to build on it. Build on it, and pin the version you build on. A span schema that changes its field names underneath a production firewall is a silent failure, not a loud one. The calls still log. They just stop joining to the task they belonged to.
The design point is independent of any standard. Three records, three jobs, one shared key:
- The observability span says what ran: the tool, the target, the timing, the result.
- The Logic Log entry says why: the task, the reasoning the agent offered, the inputs it relied on.
- The firewall decision says what was permitted: the four inputs as the firewall saw them, the outcome, and the rule that produced it.
Join them on the agent identity and the task identifier, and you have what Chapter 10 called Proof of Action: the ability to prove what an agent did, when, with which permissions, on which inputs. Leave any one out and you have two-thirds of an explanation, which is what most agent incidents hand an investigator today.
What it cannot do
The Logic Firewall reduces a specific risk. It does not remove agent risk. Presenting it to a board as though it did overstates what it protects against.
It inspects what the agent proposes, not what the model "intends." A well-formed call that sits inside the task declaration and below the tier threshold will pass, whatever produced it. A task declaration that is too broad lets everything through. And a firewall that adds noticeable latency to every call will be routed around by the first team with a deadline.
It also has to be maintained by you. Task declarations drift, registries go stale, and new tools arrive with no tier. Chapter 19 named what happens when nobody makes these decisions deliberately: the Vendor-Decides Pattern, "the enterprise governance framework that emerges from accumulated vendor defaults..." rather than from a deliberate architectural choice. The Logic Firewall is the opposite choice. It is a control you own, configured to your tasks and your registry, rather than one you inherit. Owning it is the point and also the price.
The policy file
Chapter 36 closed with a registry that gives each action type its tier. This chapter closes with the policy that reads it. It is a starting structure, not a product configuration; adapt the field names to your gateway.
# logic-firewall-policy.yml# Evaluated for every proposed tool call, after the agent decides and before execution.policy:version: 1owner: enterprise-architecturedefault_outcome: hold # anything unmatched waits for a humandecision_log: logic-log # every outcome is written, including allowinputs:identity:require_verified_agent_id: true # unidentified caller: blocktask:require_declaration: true # no declaration: holdfields: [purpose, allowed_tools, allowed_targets, data_classes, expires_at]capability:track_per_session: [private_data, untrusted_content, external_comms]max_unsupervised: 2 # Rule of Tworeversibility:registry: escalation-matrix.yml # tiers 0 to 3, from Chapter 36unknown_action_tier: 2rules:- id: out-of-scopewhen: action.tool not in task.allowed_tools or action.target not in task.allowed_targetsoutcome: block- id: task-expiredwhen: now > task.expires_atoutcome: block- id: third-legwhen: session.capability_count_after(action) > inputs.capability.max_unsupervised and session.supervised == falseoutcome: hold- id: tier-3when: registry.tier(action) == 3outcome: block- id: tier-2when: registry.tier(action) == 2outcome: hold- id: degrade-writeswhen: registry.tier(action) == 1 and agent.risk_signal == elevatedoutcome: allow_degradeddegrade_to: read_only- id: routinewhen: registry.tier(action) == 0outcome: allowobservability:require_span_per_tool_call: truejoin_keys: [agent_id, task_id, span_id]semconv_version_pinned: true # GenAI conventions still in developmentreview:approval_rate_alert:action_tiers: [2]threshold_pct: 95 # sustained near-total approval is a findingwindow_days: 30stale_declaration_days: 90Read the rules from top to bottom and the design shows. Scope comes first, because an out-of-scope action is wrong whatever its tier. The capability count comes next, because completing the trifecta changes the risk of everything after it. Reversibility decides the rest. And the default, for anything nobody anticipated, is a human, not a pass.
The review block carries over the measure Chapter 36 set out. An approval rate that sits near 100 per cent means either the action is misclassified or the reviewer has stopped reviewing. The firewall is the natural place to count.
What changes on Monday
Three things, in order, none of which needs a new product.
First, find the hook. Every serious agent framework and gateway exposes some point between the model's decision and the tool's execution. Find yours, and find out whether anything runs there today. In most estates nothing does.
Second, write task declarations for your three busiest agents. Purpose, tools, targets, data classes, expiry. If nobody can write one, the agent has no declared task and no scope to enforce.
Third, turn on the spans. Each span carries one tool call, with agent identity and task identifier. Without them the firewall in the file above cannot keep its count. With them you have the beginnings of Proof of Action, whether or not you ever enforce a rule.
Where the book ends
This is the final chapter of the series that becomes the book Assume Breach.
The book set out with three jobs. To give New Zealand technology leaders a local voice on Zero Trust for agentic AI. To give practitioners patterns and configurations they could deploy. And to address what international material tends to skip: New Zealand governance, Māori data sovereignty, and defence against the compound risk Simon Willison named.
It ends here because the argument has arrived where it was always going. Parts One to Three set out what an agent is and the obligations it operates under in Aotearoa. Part Four gave it an identity. Parts Five and Six built defences and patterns around it. Part Seven has been about where control actually sits when the agent acts. This chapter is the answer the book has been working towards. The last control is the one you own, placed at the one moment that matters, fed by everything the earlier chapters asked you to build.
EA Thursday continues. From next week it follows the news, taking current events and reading them through the architecture this book has laid down. The frameworks stay. The chapter numbers stop.
Thank you for reading thirty-seven of them.
The question
Pick the agent in your estate that you trust most. Between the moment it decides to act and the moment its tool call executes, what is checking it, and who would know if the answer is nothing?
If your programme needs an independent architecture assurance review before its next gate, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Assume Breach, the book this series becomes, is in production with The Hamberger Report. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] Hamberger, A. "Explainable Zero Trust: When Your AI Must Justify Its Decisions." EA Thursday, Chapter 10, 16 April 2026. https://www.linkedin.com/pulse/chapter-10-explainable-zero-trust-when-your-ai-must-its-hamberger-fgbse/
[2] Hamberger, A. "The Sixth Pillar: Agent Identity and the New Perimeter." EA Thursday, Chapter 12.
[3] Hamberger, A. "The Delegation Problem." EA Thursday, Chapter 19.
[4] Hamberger, A. "When Agents Delegate to Agents: Securing the Chain of Agency." EA Thursday, Chapter 20.
[5] Hamberger, A. "The Trust Boundary Is the CI Runner." EA Thursday, Chapter 29, 27 August 2026.
[6] Hamberger, A. "A Firewall for a Protocol Nobody Told You Was on the Network." EA Thursday, Chapter 31, 10 September 2026.
[7] Hamberger, A. "Who Holds the Undo?" EA Thursday, Chapter 36, 15 October 2026.
[8] Willison, S. "The lethal trifecta for AI agents: private data, untrusted content, and external communication." 16 June 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
[9] Willison, S. "New Prompt Injection Papers." 2 November 2025 (covering Meta AI's "Agents Rule of Two," 31 October 2025). https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/
[10] OpenTelemetry. "Semantic Conventions for Generative AI." Repository, accessed 21 October 2026 (verified directly against the repository's own docs folder, commit 547934a, 18 October 2026). https://github.com/open-telemetry/semantic-conventions-genai
[11] azena.ai. "OpenTelemetry's GenAI Semantic Conventions Are Not Stable Yet: Here's What Actually Shipped in 2026." DEV Community, July 2026. https://dev.to/azena-ai/opentelemetrys-genai-semantic-conventions-are-not-stable-yet-heres-what-actually-shipped-in-2026-3mke