← All speakers

Bio, Work & Ideas

Randall Degges

Conference affiliation: Snyk

On this page

Randall Degges is VP of AI Engineering and Developer Relations at Snyk, where he builds AI-powered security tools and developer experiences. The creator of ipify and a former startup CTO, he has spent his career turning difficult infrastructure and security problems into tools that other programmers can actually use.

From telephony infrastructure to developer tools

Degges’s early work involved backend telephony systems, where even retrieving a caller’s name could require carrier agreements, specialized hardware, and substantial integration work. In 2012, he and his collaborators launched OpenCNAM to make caller-ID information accessible through a simple API. As CTO, he built the initial service and subsequently replaced its monolithic Django implementation with smaller Flask services when demand exposed scaling problems.

The experience taught him lessons beyond backend performance. OpenCNAM’s developer-oriented presentation obscured the needs of customers who simply wanted caller ID working on their business phone systems. He also regretted diverting attention to other projects while OpenCNAM was growing. His startup retrospective combines pride in a useful product with an unusually candid account of misunderstanding its audience and underinvesting in its continued development.

His interest increasingly moved toward developer tools outside telephony. He published The Heroku Hacker’s Guide in 2012, drawing on experience building deployment systems and provisioning infrastructure. Heroku appealed to him because it reduced the operational work between writing software and putting it into users’ hands.

That preference also shaped ipify, a free API that returns the caller’s public IP address. Degges created it while building infrastructure-management software that needed to discover cloud instances’ addresses without relying on provider management APIs. Its deliberately narrow purpose made it easy to integrate into provisioning and configuration workflows. He initially implemented it in Node.js, then rewrote it in Go after investigating throughput limitations. By January 2018, it had surpassed 30 billion requests per month on several occasions. He later transferred ownership to WhoisXML API, continuing to help occasionally.

Making authentication easier to get right

In 2014, Degges stepped back from OpenCNAM’s day-to-day CTO role and joined Stormpath as its first developer evangelist. Building an internal authentication service had already introduced him to the complexity of web security. Stormpath offered a way to spare other developers some of that work through an authentication and user-management API.

He approached developer relations as an engineering responsibility. After experimenting with extensive outreach, he devoted more time to client libraries, documentation, and working directly with users. He built Flask and Express integrations and helped improve the Python and Django libraries. His account of that shift makes the reasoning concrete: promoting an API accomplishes little if a developer must inspect its source and assemble low-level security plumbing just to try it.

Stormpath’s acquisition brought him to Okta in 2017, where he went on to lead evangelism. Authentication remained a central concern: password storage, session management, authorization, and account recovery placed consequential responsibilities on application developers. His argument for simpler authentication tools grew directly from building and supporting those integrations.

At Okta, he introduced PassProtect, an open-source library that warns users when they enter passwords found in breach data, and built a companion Chrome extension. The tool used Have I Been Pwned’s password service and a k-anonymity approach to check passwords without transmitting the password or its complete hash. It put a security intervention at the moment someone could act on it, rather than requiring them to discover a breach afterward.

Security where software takes action

At Snyk, Degges’s work now extends to AI-powered development and autonomous agents. Several positions connect his earlier security engineering to this newer focus:

  • Protect session credentials from page scripts. His writing on browser storage argues against keeping session tokens in local storage because JavaScript executing on the page can read them. A compromised third-party script can therefore turn a convenient storage choice into account compromise. He favors server-side sessions with appropriately protected cookies, treating credential handling as an architectural decision.
  • Enforce security around tool calls. Degges advocates infrastructure-level guardrails that inspect an agent’s actions independently of its model and prompts. Hooks around tool access, execution, and returned data can apply permissions, validate inputs, detect dangerous content, and record decisions. He also argues for modifying unsafe requests when the legitimate task can still be completed, since repeated rejection can send an agent into unproductive retry loops. His proposed Snyk integration with Arcade’s execution pipeline is a direction for development, rather than a claim that every described capability has shipped.
  • Treat agent skills as a software supply chain. In his writing on securing the skill ecosystem, Degges emphasizes that a skill combines executable code with natural-language instructions interpreted by an agent. Reviewing only the code misses instructions that manipulate the agent into misusing its permissions. He describes Snyk and Vercel’s scanning integration as a way to bring analysis of both code and instructions into skill distribution; the underlying research and scanning technology are collaborative company work.

Across these projects, Degges keeps returning to the point where a programmer’s intention becomes an operational consequence: an API integration, a login session, a password check, or an agent’s tool call. His work makes those moments easier to use and harder to misuse.

Read the topics behind these talks

1 conference talk

Key ideas

Scroll to read ↓

Safe autonomous software needs independent validation of generated code, dependencies, tools, and behavior—not just a more capable model.

  • Safe autonomy starts with a trust question
    0:33 ↗
  • Persistent attackers meet a larger attack surface
    4:34 ↗
  • The backlog is growing while exploits compose
    7:00 ↗
  • The environment can be unsafe before code runs
    8:33 ↗
  • Inventory the stack, then test the specific risk
    10:24 ↗
  • A validator needs more than plausible findings
    12:04 ↗
  • Put security context where decisions happen
    13:29 ↗
  • Two packages can have no CVEs and still differ
    15:30 ↗
  • An unchanged skill can acquire changed instructions
    18:55 ↗
  • From individual checks to a learning system
    21:03 ↗

References