The HP Garage in Palo Alto is remembered as the “Birthplace of Silicon Valley.” It was a one-car workspace where Bill Hewlett and Dave Packard turned a technical experiment into a company that helped define an industry. Technology often starts in rooms too small for the consequences it creates. A quick prototype becomes a product with thousands of users, with support expectations. An experiment in building software becomes the infrastructure that a lot of the internet depends on.
This made the Bay Area city the perfect place to hold the San Francisco Secure Software and AppSec Summit 2026. Application security is once again standing near the garage door, watching experiments harden into systems before the governance model has caught up.
The event brought together over a hundred security practitioners, product security leaders, founders, and enterprise AppSec teams together for a practitioner-heavy day focused on secure software, AI-driven development, supply chain risk, and operational maturity. Throughout the event, AI was never treated as a magic layer, but as an accelerant, one that makes architectural debt, identity shortcuts, weak ownership, and lifecycle gaps harder to ignore.
Here are just a few highlights from the event.
The Agent in the Hoodie
In the opening keynote session "Securing Autonomous AI Agents: The New Attack Surface No One Is Ready For," Aaron Brown, Head of Security and IT at Mercor, plainly explained that prompt injection is arbitrary instruction execution in softer clothing. Every agent input should be treated as untrusted code, and every memory write as a potential persistent payload. We have seen this reactive pattern before, as SQL injection forced parameterized queries, and cross-site scripting forced content security controls. When untrusted input can steer execution, permissions alone will not save you.
The production risk is the untrusted content agents now consume from email, web pages, continuous integration builds, rules files, and shared knowledge bases. Aaron’s said access to private data, exposure to untrusted content, and external communication form an exploitable agent trifecta. There is no robust prompt injection filter ready to solve that problem. Not today and not on any near-term roadmap. He emplored us all to "stop building castle walls and start building blast doors." This looks like capability scoping per invocation, sandboxed execution, egress allowlisting, no ambient credentials, and human approval gates for actions that cannot be undone.
Aaron said the next step is to treat agents like interns with root access: onboard them, scope them, audit them, and offboard them. That means giving every agent its own revocable identity, logging every tool invocation, and trusting system calls over agent explanations. The risks already landing in production, including sub-agent fan out, Model Context Protocol supply chain exposure, and shared-memory injection, all point to the same conclusion: the control plane is the blast radius. He left us with the practical advice that "You will not out-prompt the attacker. You can out-engineer them."
Kill the Server Before It Kills You
In the session from Mike Wilkes, Field CISO at Aikido, called "Shutting It Down: Decommissioning as an AppSec Control," he explained that in his experience, the software development lifecycle tends to obsess over what gets built, shipped, and maintained, but it often goes quiet when systems should die. That silence has a cost. Every orphaned app, stale server, forgotten license, unmanaged certificate, and abandoned integration becomes infrastructure for someone else. Old systems do not patch themselves.
Decommissioning is not, and can not, be owned by security alone. It is a cross-functional retirement process that requires business approval, access removal, data retention decisions, and post-shutdown verification, among other basic requirements. Good asset management depends on mature tagging, infrastructure as code, and continuous discovery because the configuration management database is only as accurate as its last update. Mike pushed the audience to treat infrastructure as cattle, not pets.
He said we need to "Give cloud assets a death date. Celebrate shutdown as part of the lifecycle." Then prove it happened with evidence that teams can use in an audit. We also need to stop only asking what new systems are being deployed and start finding the systems the organization is brave enough to shut down.Forgotten systems are not harmless clutter. They are loaded weapons pointed at the business.
SBOMs, Herds, and the Dependency Reality Check
In the session panel discussion "The Evolving Supply Chain Risk Landscape: What’s Actually Breaking in Production," a group of seasoned experts presented a grounded view of supply chain security that challenged several comfortable assumptions. It started with a question from the moderator, Mike Shema, Host of Application Security Weekly, about the effectiveness of SBOMs in AppSec.
Ankur Chakraborty, Senior Director of Platform Security at Box, was blunt that software bills of materials (SBOMs) are not reducing production risk by themselves. Ankit Agrawal, Senior Manager, Application Security at Webflow, gave them a narrower lane, saying they are useful for federal compliance and some inventory use cases, but not a vulnerability prevention mechanism. David Holmes, Application Security Chief Technology Officer at Thales, added that knowing whether you have a vulnerable package still matters, but AppSec teams should not confuse awareness with control. Gursev Singh Kalra, Vice President, Product Security at Salesforce, brought the concern forward into AI-assisted development, where tools do not naturally pause to ask whether a dependency is safe. They fulfill the prompt.
The panel kept returning to the point that the list of dependencies is not the control. Ankur argued for system-level guardrails because modern package ecosystems can break clean inventory assumptions quickly. Ankit pointed to controls around dependency intake, risk scoring, and pipeline-specific policy enforcement, noting that overly rigid software development lifecycle rules can push developers into workarounds. Gursev emphasized parallel security review for machine-generated code, with automated checks running as code is created, not after it is already in production. David pushed on the human problem underneath the tooling, that organizations still need skilled people to define what agents can do, where they should be constrained, and when automation has exceeded its authority.
AI-generated code complicated the discussion. The panelists observed that coding agents do not naturally pause to ask whether a dependency is safe. They fulfill prompts. That means dependency governance has to move closer to the act of creation, with paved paths, continuous policy checks, and guardrails that apply consistently across humans, agents, and pipelines. The lesson was not that supply chain security needs a new slogan. It needs enforcement points that work at machine speed without forcing developers into workarounds.
AppSec Moves Closer to the Architecture
The panel "The Future of AppSec: What Changes, What Stays, and What Gets Replaced" opened by separating AI usefulness from AI theater. Ken Johnson, Co-Founder and CTO at DryRun Security, called “AI skills” overhyped when they are not tied to durable business cases or clear model choices. Simon Harloff, Chief Product Security Officer at Dam Secure, pushed back on the idea that AI simply replaces humans. Seth Law, Founder of Redpoint Security, warned about overdependence on tools like Claude Code, especially when junior practitioners are pushed into senior-level work before they understand the consequences. Cole Cornford, Chief Executive Officer, Galah Cyber, pointed to a deeper risk that base models age quickly, and what looks useful today can become obsolete as the model, context, and business case change.
AppSec review is moving away from people reading every pull request and toward systems that shape, constrain, and verify work before production. Panelists argued that manual code review is no longer the primary control, and the real question is how AI-generated work changes system architecture. We were challenged to think about what “code owner” means when AI can modify large portions of a codebase, then predicted that traditional DevSecOps approval workflows will fade as agents feed outcomes into pipelines.
The group tied the shift back to supply chain risk, noting that AI pushes teams further into software they did not directly write. Legacy controls like web application firewalls and software composition analysis may be headed for a dinosaur moment as AppSec blends into application engineering and general security. AppSec is not disappearing. It is being redistributed, automated, and pushed closer to architecture.
AppSec Is Becoming Control Plane Engineering
AppSec is shifting from finding security issues to engineering the control plane around how software gets built, changed, retired, and delegated to agents. Accountability is the goal. Not just who found the risk, but what system constrained it, who owned it, and how the organization proved it was handled.
AppSec Is Losing the Comfort of Human Scale
For years, AppSec assumed humans could stay close enough to the work to understand it. A human wrote the code and reviewed the pull request. A human approved the waiver. That model was already strained, and AI makes the strain much more visible.
Software now moves faster than human attention can serve as the primary security boundary. Agents can generate code, choose dependencies, call tools, spawn sub-agents, and write memory faster than teams can inspect each decision. Humans still matter, but their work moves upstream into intent, architecture, constraints, and exception handling. Machine-speed work needs machine-enforced boundaries.
Ownership Is the Scarce Resource
Many sessions were really about ownership. Who owns the agent’s permissions? Who owns a stale system after the business stopped using it? Who owns a dependency pulled by a coding assistant? Who owns the risk when a release ships with a waiver?
Most AppSec failures are not failures of detection. They are failures of accountable closure. The organization may know the issue exists, but not who can make it go away. That is why asset inventory, agent identity, risk registers, paved paths, and decommissioning kept showing up.
Reversibility Is the New Security Boundary
One interesting takeaway was "reversibility." The old instinct was to ask whether something was allowed. The better question is whether it can be safely undone. If an agent suggests a code change, it can be reviewed and reverted. If it deletes customer data, sends credentials externally, changes production state, or writes persistent instructions into shared memory, the risk changes. Decommissioning is controlled reversibility for infrastructure.
Human-in-the-loop gating matters most where the action cannot be cleanly unwound. The future AppSec control model is less about what AI can do and more about which actions are safe to automate because the blast radius is bounded.
The Work Of AppSec Is Moving Down a Layer
The next version of AppSec will not be judged by how loudly it warns, how many findings it opens, or how often it says no. It will be judged by what it makes impossible by default. The teams that adapt will stop treating security as a review function bolted onto software and start treating it as part of the operating model beneath software. They will implement identities that expire, systems that can die cleanly, agents that inherit intent rather than access, and risk decisions that leave a trace.
AppSec is not disappearing into AI, automation, or developer tooling. It is moving down a layer, closer to the places where software becomes real. The future belongs to teams that can turn judgment into guardrails, guardrails into defaults, and defaults into systems that hold even when nobody is watching.
