What struck me in IT Security speaker Christian Schneider’s description of this case was where the failure occurred: not neatly inside one broken component, but across a chain of valid system interactions. Schneider sums it up like this: “The system moved through legitimate states, end to end, until it betrayed itself.”

That example changed how I looked at two other IT Security Summit experts’ arguments, Michael Hoffman and Christian Wenz. Hoffman focuses on additional authorization controls outside application code; Wenz on why old and familiar security problems persist as software grows more complex. Together, their observations point toward the same principle: while secure application code remains essential, it cannot be the only thing containing a failure.

Do you want to see these three experts live? Join us at the IT Security Summit in Munich from November 30 to December 4. There, you can form your own opinions on their sessions, ask questions, and continue the conversation over coffee.

Security has spent years moving closer to developers. Shift left, secure-by-design, automated testing, security checks in CI/CD. The direction has been clear: security should not arrive at the end of development as a final review or a collection of fixes. It should shape the software from the beginning. Good enterprise security architecture, however, does not rely on application behavior alone. It also places critical, cross-cutting controls in the surrounding infrastructure, where rules can be enforced consistently and independently of any specific application’s code.

Infrastructure, in this sense, includes identity and access controls, gateways, network policies, deployment pipelines, runtime restrictions and similar safeguards. These are the foundations that determine what software can access, where it can communicate and how far a failure can spread.

Why putting security in the infrastructure matters more now

None of this is new security doctrine. Defense in depth, least privilege, isolation and independent enforcement have been established principles for years. What has changed is the environment in which they have to work.

Modern applications have gradually accumulated more dependencies, frameworks, cloud services, configuration, identity layers and connections to other systems. Every additional layer creates another place where assumptions can break, permissions can be misconfigured or dependencies can behave differently than expected. Security depends increasingly on the relationships between systems as well as on the correctness of the code inside one application.

Agentic AI adds another dimension. Developers still define the environment, available tools and permissions, but they may no longer specify every intermediate action the software takes. That makes structural controls more important: the surrounding system has to determine what an application may access, which systems it can reach and how far an unexpected action can travel.

The point is not to replace secure development with infrastructure. Security now has to work in both places: inside the application, where developers design secure behavior, and around it, where the architecture limits the consequences when that behavior fails or becomes unpredictable.

Assume the application will get something wrong

Applications are fallible. An authorization check can be forgotten, misconfigured or applied in the wrong place. Any architecture that depends on one control working correctly every time is therefore fragile by design.

Michael Hoffman makes this concrete with authorization. Developers still have to decide inside the application who may access which data or perform which action. But, as he puts it, “a little element missing in your code” can already increase the security risk.

What I find useful in Hoffman’s argument is how clearly it reinforces one of the oldest principles in security: assume an individual control will eventually fail and make sure the system has another layer ready when it does. Infrastructure can add another barrier through access controls, gateways, network policies or other safeguards when an application-level check is missing or fails.

An airport makes this idea easy to visualize. Getting through one checkpoint does not give you access to every gate, aircraft or restricted area. Further checks, doors and access controls limit how far one mistake—or one successful attempt to bypass a control—can go. 

This is the logic of defense in depth: instead of asking only whether a control can fail, the more useful question is what happens next when it does. There is a parallel with recovery in DevOps: recovery asks how quickly a system returns to normal; defense in depth asks how far a failure can travel before another layer contains it.

Security outside the code 

In modern software, there is rarely just one “second layer”: security increasingly depends on the systems and services around the application. 

Christian Wenz sees the growing complexity of software reflected in the 2025 OWASP Top Ten. Security misconfiguration has become more prominent and he links that to a simple development: software is increasingly configurable. An application can contain sound security logic and still run with unsafe settings, vulnerable dependencies or poorly controlled connections to other systems.

Wenz’s argument is that the security boundary has gradually expanded. Teams are no longer responsible only for the code they write. They also depend on frameworks, external packages, identity systems, deployment pipelines and other components whose behavior and configuration affect the application’s security.

In a conversation I had with Wenz he made that historical change tangible when he said it was easier to prevent vulnerabilities “20 years ago with fewer frameworks, because nowadays we’re handing off so much to frameworks.” Those frameworks provide useful security features, but they also introduce more behavior, configuration and dependencies that teams have to understand.

From guidelines to enforcement

Some security expectations can move from guidance into enforcement: a pipeline, policy or platform can make them part of the normal route to production. Wenz points to integrity checks in CI/CD as one example: instead of relying on every team to reproduce the same security rule correctly, part of that rule can be built into the systems applications share.

That changes responsibilities as well as architecture. Developers still have to build secure applications, but they increasingly work inside foundations that define which configurations, connections and deployment paths are acceptable in the first place. Security doesn’t end where the code ends, and its reach into the surrounding systems continues to grow.

The less predictable the software, the harder the boundaries

Agentic AI gives this established architectural approach new urgency because it changes the character of the problem. A conventional application can be complicated, but developers largely determine its execution paths. An agentic system introduces another layer: the developer still defines the environment, permissions, tools and goal, but the model can decide which intermediate steps to take. Christian Schneider puts it bluntly: “Here the model decides what happens next. Not you. Not the developer.” Instead of defining every action, developers increasingly define the boundaries within which actions are possible.

That is what makes the EchoLeak case I mentioned at the beginning of the article more than an isolated AI vulnerability. As Schneider argued, the individual components could appear properly secured, yet their interaction still produced an unsafe outcome. What stands out to me from that example is that security has to account for the paths an autonomous system can create between otherwise well-secured components. 

This is where Schneider’s distinction between probabilistic and structural controls is more relevant. Guardrails and classifiers can influence what an agent is likely to do; structural controls restrict what it is actually able to do. Least privilege, network restrictions, sandboxing, isolated sessions and tightly scoped credentials are familiar measures, but agentic systems make them more consequential.

Permissions are a good example. Schneider argues that tool and credential access should be limited to the “bare minimum of the current task.” He applies the same logic to combinations of capabilities: an agent that can read private data, consume untrusted content and communicate externally has a much more dangerous path available than one whose architecture separates those capabilities.

For me, that is the core lesson of agentic security. A developer won’t be able to predict every decision an agent will make, hence their task is to design the surrounding system so that an unexpected decision can be stopped and contained somewhere. The less predictable the software becomes, the more predictable its boundaries need to be.

Learn more: IT Security Summit Munich explores many of the topics I’ve discussed in this article in greater depth. Its sessions and workshops examine established security practices, how security is being built into modern development and infrastructure, and what changes as AI becomes part of the systems we need to protect.

Some of those sessions and workshops are:

• Secretless AI – How to Deploy AI Agents Without Exposing your Secrets — Barak Abekasis and Martin Gegenleitner
• Becoming the Godfather of Threat Modeling — Mike van der Bijl
• How the EU Cyber Resilience Act will impact your SDLC — Manuel Schuller

Good security foundations change the starting point

My main conclusion from the perspectives of Schneider, Hofmann and Wenz is that we shouldn’t be looking for a wholly new category of “AI security.” Agentic AI introduces real new threats and failure modes, but many of the strongest responses are familiar: least privilege, isolation, defense in depth, explicit trust boundaries and controls that limit what software can actually do.

Doing the fundamentals well will not make agentic systems harmless, but it reduces how much an organization has to trust them to behave exactly as expected. If privileges are already limited and failures can be contained, an unexpected decision has less room to cause damage. 

For me, the lesson extends past today’s AI debate. Organizations that build security into their foundations are better prepared not only for agentic AI, but for whatever technology comes next. The question is whether those foundations remain useful when new systems introduce behavior we have not yet learned to anticipate.

Technology changes, but the discipline underneath it should already be there.

How prepared is your organization for what comes next? At the IT Security Summit Munich, security experts and practitioners will explore the practices, architectures and emerging threats shaping enterprise security: from established security fundamentals to securing AI agents. Join us from November 30 to December 4 to challenge your current approach, learn from others facing the same questions and prepare your organization for what comes after today’s AI debate.