Supplementary Note 4 — The Wall of Defense — Detection and Structural Defense are Different Jobs

Telco × Agentic AI / Vol. 16
August 2026 / Author: Hiroyuki Hikino

🎧 Click here to listen to the audio version
If you want to grasp the overall picture through audio before reading the main text, please click here.
You can listen simply by pressing the play button.

Introduction: Why I am including the third installment of the Wall series

So far, as supplementary notes to Act 1, I have covered connection with the TM Forum (Vol. 13), the wall of control (Vol. 14), and the wall of observation (Vol. 15).

While having repeated discussions with industry readers, there is one more question that always comes back with the same weight.

This is a question that is deeply connected to the control discussed in Vol. 14 and the observation discussed in Vol. 15, but it has a different axis.
If we don't organize this head-on, we will inevitably stumble somewhere in enterprise design discussions.

In this paper, I will name this question “The Wall of Defense” and organize it as the correct way to structure Defense in Depth.

The nature of the misunderstanding — thinking that detection and structural defense are the same layer

If you break down the customer's perspective, it looks like this.

This premise is wrong.
Defender / Purview and Ephemeral are not competing roles, but different layers.
The moment you think they are about the same layer, they look “redundant,” but in reality, they are at completely different levels, handling completely different threats.

If we don't carefully separate these, the discussion won't move forward.

Organizing positions in the 5-layer defense stack

If you organize the security layer that protects agents according to the industry-standard Defense in Depth framework, it looks like this.

What is important here is that Defender and Purview handle L4-L5 (Control/Detection) and Ephemeral handles L1 (Architecture).
Both are at completely different layers and respond to completely different threats.

And each layer is independently necessary.
None of them can replace the others.
This is the principle of Defense in Depth, and it applies in exactly the same way in the agent era.

Why “detection” alone is not enough — The Confused Deputy problem

This is the essential point in terms of security.

One of the most troublesome attacks in the agent era is prompt injection. The fatal nature of prompt injection can be summarized in the following point.
The fatal nature of prompt injection is summarized in this one point.

It manifests as behavior that looks completely normal.

From the perspective of detection-based products (Defender / Purview), this is how it appears.

This is the classic information security problem, Confused Deputy, itself. A subject with legitimate authority abuses that authority based on malicious instructions. Detection layers centered on pattern recognition and behavioral analysis are

structurally weak against this class of attack.

This is why a defensive layer other than the detection layer — in other words, an architectural layer — is necessary.

Comparing the same attack in a persistent environment versus an ephemeral one over time

I would like to lay them out concretely in a virtual scenario.

Scenario: An agent subjected to prompt injection attempts to send confidential data externally.

Persistent environment (detection layer only)

Ephemeral environment (detection layer + architectural layer)

→ Same alerts, same Defender, same Purview. The difference is
damage duration of 30+ minutes vs 0 minutes.

This is the significance of the L1 (architectural layer). The detection layer has the role of "noticing," while the architectural layer has the role of
preventing damage before it is noticed. Both perform different jobs.

Defender / Purview also run within ephemeral environments

Here, I want to answer head-on the customer's question: "Won't these also start up together?"

As a matter of fact, that is correct.
Defender for Endpoint and Purview are integrated into each ephemeral instance of W365 for Agent.
This is not a parallel opposition, but a series collaboration relationship.

Laying out their respective roles clearly, it looks like this.

To use a metaphor, Defender is the "security guards and surveillance cameras," Purview is the "labels and locks on the contents of the safe," and Ephemeral is the "design where the room itself evaporates when the meeting ends." The three are not in a replacement relationship, but in a
complementary relationship.

The bank vault time-lock metaphor

When talking with industry readers, this metaphor is the most effective.

A bank vault is equipped with security guards, surveillance cameras, and alarm systems.
Nevertheless, the vault itself is equipped with a time lock designed so that it cannot be opened by anyone's authority outside of business hours.

Why?

This is the relationship between the detection layer and the structural defense layer.

In the world of agents, the time lock is the Ephemeral execution environment.
Both Defender and Purview play extremely important roles, but they belong to the detection and response layer.
Ephemeral is a different layer that wins through structure and a zero-trust design is only complete when both are present.

Clearly stating the limitations of detection-based approaches

For readers who have read this far and still think that Defender/Purview alone is sufficient, I would like to summarize the limitations of the detection layer.

This is not to deny Defender/Purview, but to clarify areas that the detection layer cannot handle on its own.

1. Vulnerable to unknown attack patterns

   • Defender is a combination of pattern matching and AI anomaly detection, but there is still little training data for novel agent-specific attack techniques (currently being compiled as the OWASP Agentic AI Top 10).

2. There is a time lag between alert triggering and containment

   • The industry average MTTR (Mean Time To Respond) from alert to SOC response is 30 minutes to several hours.

   • During this time, the damage continues to spread.

3. Vulnerable to attacks disguised as legitimate behavior

   • The aforementioned Confused Deputy problem.

4. Cross-cutting attacks are only visible after the fact

   • Attacks coordinated by multiple agents are analyzed for correlation using tools like Sentinel, but this is often post-incident analysis

What bridges all these limitations is a "structure where damage does not spread even if an incident occurs", in other words, an Ephemeral execution environment.

The detection layer and the structural defense layer each have weaknesses that the other cannot cover.
That is precisely why both must beprovided simultaneously.

Supplementary note on "Won't it take time to start up?"

When the discussion turns to full-scale introduction of Ephemeral, there is one more question that always comes up.

This is also a continuation of the discussion on defensive walls, so I would like to touch upon it here.

The reality of the numbers

When operating an Ephemeral execution platform in production in the industry, the adoption of aWarm Pool is a natural prerequisite.

An Ephemeral platform that starts from a full cold state every time does not exist in production operations.
If you discuss this while misunderstanding this point, Ephemeral will appear disadvantageous.

Position within the overall MTTR

When breaking down the MTTR for failure response in the telecommunications industry, startup time is onlya very small fraction of the total.

Spin-up accounts for onlya very small fraction of the total MTTR even after incorporating AI.
The real bottlenecks are detection and isolation, and shortening these by orders of magnitude is the true value of AI.

Persistent environments have "unreadable worst-case values"

This is the point of counter-offensive.
When operating persistent Agent VMs, the average startup time is fast, but theworst-case value is unpredictable.

• Recovery scripts do not work in production due to configuration drift (config rot)

• Recovery operations themselves result in authentication errors due to expired authentication tokens

• Processes crash precisely when needed due to memory leaks or handle exhaustion

• Gaps in recovery capability occur due to planned outages or patch applications

Ephemeral startsfrom a golden image every time, so execution time is deterministic.
Considering that SLAs in the telecommunications industry are evaluated not by average values but byworst-case values, certainty becomes the selection criterion.

Zero Trust Principles and Ephemeral

Finally, I would like to place the discussion of defensive walls within the context of zero trust principles.

Zero trust is often summarized as "Never trust, always verify."
However, in the agent era, another axis is added.

This is the very principle of Ephemeral.
Past legitimacy does not create current trust.
Re-authenticate for each task, reset the environment, and do not carry over state.

This is a property that cannot be realized at the detection layer.
The detection layer determines "is it abnormal at this moment?"
The structural defense layer guarantees a "structure where past contamination does not propagate to the present."

Only by combining both can zero trust design become implementable in the agent era.

Refining the Ephemeral Principle — "Then who is the one starting it?"

I have emphasized the structural value of ephemeral so far.
When discussing this with industry readers, the following question always comes back.

This question demands the most important refinement of the ephemeral principle.
I would like to state the conclusion first.

Two Types of Agents — Layer Orchestrators and Workers

When breaking down an agent infrastructure that can be implemented in an enterprise, the following two types always appear.

The layer orchestrator (sometimes called the "boss agent" for convenience in the industry, though maybe that's just me...) does not perform directly business processing. It does not read customer data, does not hit external APIs directly, and does not have persistent state.
Its role is limited to "starting the workers necessary for this task now, with only the necessary authority, for only the necessary time."
Because the authority is minimal, even if it is compromised, the damage is limited, and it can be stably operated as a target for auditing, patching, and redundancy even if it is resident.

Worker agents actually read customer data, hit external APIs, and perform code or configuration changes.
Authority is concentrated here, but this is ephemeral.
At the moment the task is completed, it disappears along with the environment, and tokens, caches, and states are all volatilized.

Here, I want to note that this does not contradict the previous discussion of "persistent environments cannot read worst-case values."
The reason worst-case values cannot be read is when the layer that performs business processing directly is made resident.
The layer orchestrator is a layer that does not perform business but only starts workers, and the attack surface is orders of magnitude smaller.
Even though both share the word "resident," they are completely different entities in terms of design.

Relationship between Kubernetes Control Plane and Pods

This structure has a metaphor that industry readers of container operations will understand immediately.

In Kubernetes, the Control Plane (kube-apiserver, scheduler, controller-manager) is resident, and Pods are ephemeral.
The Control Plane does not execute business logic, but it manages the life and death of Pods.
The "division of labor between resident and ephemeral" that the industry has reached in 10 years of container operations and the structure that agent infrastructure is about to reach are essentially the same form.
It is not a new principle, but a re-application of principles that the industry has already learned.

Technical Boundary Between L3 and L4

When the ephemeral principle is refined as described above, the boundaries of the TM Forum AN Maturity Levels also become technically clear.

Up to L3, the overall loop of observation, judgment, and execution is closed.
However, when a failure or worker anomaly occurs within each layer, there is no entity to restart or replace it, forcing human intervention.

In L4, a layer orchestrator resides within each layer to autonomously perform worker startup, monitoring, and replacement.
The point of human intervention shifts from intra-layer processing tocross-layer exceptions and high-blast-radius judgments.

In other words, the existence of a layer orchestrator is not only a discussion about the wall of defense, but alsoa condition for technically establishing the transition from L3 to L4.

This broader structural theory—a multi-stage architecture where a meta-orchestrator, layer orchestrators for each layer, and worker agents are arranged in three tiers—will be handled in more detail in Act 2 of this series.
In this article (The Wall of Defense), I will limit myself to clarifying that a resident layer is necessary within the ephemeral principle, and that this design organizes the attack surface rather than increasing it.

The Wall of Control, the Wall of Observation, and the Wall of Defense — The Relationship Between the Three Walls

So far, as supplementary notes, I have dealt with the three walls in order.
These are not independent discussions, but are deeply connected.

The three walls must be integratedfor the same execution, at the same granularity, and at the same timing.
If you build layers with separate products and separate vendors, accidents will leak from the joints between the layers.
This is the reason why 'aligning the five conditions with a single vendor' in the 12th installment is effective across the three axes of control, observation, and defense simultaneously.

Next Issue Preview: Final Installment — Summary of Act 1 and Connection to Act 2

With this, all the discussions for Act 1 have been presented.
Theory (Installments 1–12), Supplementary Note 1 (TM Forum, Installment 13), Supplementary Note 2 (Wall of Control, Installment 14), Supplementary Note 3 (Wall of Observation, Installment 15), and Supplementary Note 4 (Wall of Defense, this article).

Next time (Installment 17), as the final installment of Act 1, I will compress these into a single structural diagram.
Then, I will make the connection to Act 2 of this series—a discussion of a larger methodology called Agentic AI Runtime.

Execution Layer, Control Layer, Observation Layer, and Defense Layer — these are the components of the new infrastructure layer that the industry will face over the next 10 years.
How to redraw that overall picture will be the theme of the final installment.

Notes (Reprinted)

• This article represents my personal views and does not represent my affiliated organization.

• For standards and frameworks such as NIST, OWASP, and CSA, the official materials from each organization are the latest and most accurate sources of information.

• For specific functions and specifications of security products (Defender, Purview, Sentinel, Entra, etc.), please refer to the official documentation for each product.

• For specific interpretations and applications of national regulations (GDPR, APPI, Telecommunications Business Act, etc.), please follow the judgments of your organization's legal and compliance departments and regulatory authorities.

Series Index

• Part 1: The Wall of Autonomous Operations — Why Do We Stop at L3?

• Part 2: Conditions for Reaching AN Level 4 — The Three-Layer Structure of Observation, Judgment, and Execution

• Part 3: The Void of the Execution Layer — Why Is the Entire Industry Stuck?

• Part 4: Head, Hands, and Control — The Three Elements Required for the Execution Layer

• Part 5: The Three-Element Matrix — Re-evaluating Existing Approaches

• Part 6: The New Horizon of Agentic AI Runtime

• Part 7: Windows 365 for Agent — The "Execution Layer Foundation" the Industry Has Been Waiting For Has Emerged

• Extra Edition (Part 7.5): 95% Is Caused by Human Error — The New Main Battlefield of Agent ID

• Part 8: Project Opal — The Uncharted Territory of the Orchestration Layer

• Part 9: Application to Telco AN (1) — Closed-Loop Fault Response

• Part 10: Application to Telco AN (2) — Service Deployment and the Wall of Vendor GUIs

• Part 11: Application to Telco AN (3) — Self-Healing, Self-Optimization, and the Learning Loop

• Part 12: Why Microsoft — The Theory of Structural Advantage

• Part 13: Supplementary Note 1 — Connecting the TM Forum AN Framework with This Series

• Part 14: Supplementary Note 2 — The Wall of Control, Its True Height

• Part 15: Supplementary Note 3 — The Wall of Observation — From Substrate Observability to Outcome Observability

• Part 16: Supplementary Note 4 — The Wall of Defense — Detection and Structural Defense Are Different Jobs (This Article)

• Part 17 (Final): Beyond the Execution Layer of Autonomous Networks — Summary of Act 1 and Connection to Act 2

This article: approx. 6,800 characters / 20-minute read

Author: Hiroyuki Hikino
20 years in the telecommunications industry. 3G/4G/5G mobile core network design / Former Cisco network engineer / Currently at Microsoft (speaking as an individual) / Representative of Diestaday LLC

Please feel free to share your comments or questions in the article comments or on LinkedIn.

If you resonate with this series, please consider liking and following on note, or reposting on LinkedIn.