Javier Garza is a Staff Developer Advocate at Snyk and co-author, with Stephen Ludin, of Learning HTTP/2. His developer education work spans web performance and AI application security, explaining why a protocol upgrade can disappoint, where an agent can encounter malicious instructions, and how engineers can test those behaviors themselves.
Understanding what makes the web faster
Javier spent 17 years at Akamai, helping companies deliver faster and more secure applications. By 2020, his developer advocacy work combined web performance, security, and DevOps practices. Published in 2017, Learning HTTP/2 brought together protocol internals, migration advice, performance measurement, and debugging tools. It addressed a consequential transition: techniques developers used to work around HTTP/1.1’s limitations could become unnecessary or counterproductive under HTTP/2.
His analysis of HTTP/2 performance explained why the upgrade could help a page containing many small resources while disappointing on large transfers over a connection with packet loss. Multiplexing and compressed headers reduced overhead, but requests sharing one TCP connection also shared its response to congestion. Javier also warned against misleading comparisons: changing delivery for a site’s own resources would not automatically accelerate content loaded from third parties.
In his 2016 investigation of server push, Javier compared an edge server that already knew which resources to send with one that waited for instructions in the origin’s response headers. Both supported server push, yet the latter spent much of the potential time saving waiting for the origin. His later introduction to HTTP/3 followed the problem down to the transport layer, explaining how QUIC addressed limitations that HTTP/2 had left in place.
Teaching others to find the answer
Javier left Akamai in September 2021, planning a break with family and time helping Footsteps Missions, a nonprofit whose work in Honduras he had previously supported as a volunteer.
His farewell essay also described a change in how he helped colleagues. Becoming the person everyone asked for answers had begun consuming hours and following him outside work. He started showing people how he found answers and asking them to document what they learned somewhere others could use it. That approach let colleagues solve subsequent problems and share the results without depending on his availability.
Discover the AI components first. Javier demonstrates an AI bill of materials that turns a repository scan into a searchable inventory of models, datasets, and agents. This gives teams concrete components to assess, including AI use they may otherwise overlook.
Separate instructions from code vulnerabilities. Tool definitions can contain hidden instructions that redirect an agent; the code implementing those tools can contain a different class of vulnerability. Javier distinguishes scans for those two problems and explains a scan, fix, and rescan loop using coding-agent rules and hooks.
Constrain access and actions. Malicious instructions embedded in external content can bypass an application’s intended rules. Javier pairs this risk with defenses at different points: a database view restricts what an assistant can retrieve, while limited permissions, output validation, and human approval constrain subsequent actions.
Practice finding failures. Javier uses Gandalf challenges and an intentionally vulnerable student assistant to let developers investigate attacks. The assistant is a Snyk workshop resource. He also brings threat modeling into development by mapping assets, trust boundaries, and possible attacks before deployment.
Javier extends this teaching to dependency verification, separate development and production environments, IDE configuration, and developer review. His governance advice includes explaining why guardrails exist: restrictions that developers do not understand can invite workarounds.
Javier Garza walks through prompt injection, AI component inventories, threat modeling and agent security, connecting concrete failures to controls in data access, code, deployment and everyday development.
Indirect prompt injection enters through content an assistant retrieves for a legitimate task. Restrict both how that content influences instructions and which downstream actions the assistant can perform.
A read-only database view containing only permitted fields limits disclosure and writes through that connection, independently of whether the model follows its prompt.
AI bills of materials make models, datasets, agents and integrations searchable across projects, helping teams locate affected applications when a component becomes vulnerable.
Scan agent integrations for malicious instructions and inspect their source code for conventional vulnerabilities. These checks address different failure mechanisms.
Generated code needs explicit security requirements, constrained development permissions and a controlled path to production. Functional success alone does not establish safe operation.
▶ Watch ↗