Inside Trail of Bits' AI-Native Transformation: Dan Guido on Building a Security Firm Around Autonomous Agents

You can take a traditional security consulting firm, add an LLM wrapper to your existing tools and processes, and call it AI-native. We hear this claim in planning decks, in vendor briefings, in conversations with teams who are genuinely trying to adapt. It is wrong in a way that creates real operational exposure - and Dan Guido's work at Trail of Bits is one of the clearest demonstrations of why.

The misconception persists for understandable reasons. We have been wrapping legacy systems in APIs for years. Tool automation has a long history in security consulting - static analysis pipelines, automated reporting frameworks, scanner integrations. When LLMs arrived, the instinct was to treat them as another automation layer. Vendors reinforced this by marketing "AI-enhanced" versions of existing products, which looked like the same thing with a smarter query interface on top. The pattern felt familiar enough that teams skipped the harder question: what changes when the agent is not a faster version of your existing tool, but an autonomous system operating at continuous scale?

Trail of Bits diverged from this assumption when the operational numbers made the old model obviously inadequate. Finding 200 bugs per week through continuous repository analysis is not a faster human analyst - it is a qualitatively different operational mode. The Trail of Bits focus on skills repositories, sandboxing, and what Guido has framed as an agentic operating system is not a feature list. These are architectural responses to a threat surface that did not exist when your consulting workflows were designed.

Where Traditional Security Consulting Assumptions Fail at Autonomous Scale

Traditional security consulting is human-paced and human-gated. A pentester spends weeks on an engagement, produces a report, and moves on. Every consequential action passes through a human who can catch the anomalous tool call, the unexpected scope expansion, the finding that doesn't smell right before it becomes an incident. That human gate is doing a lot of implicit security work that nobody wrote down because it was never under threat.

Autonomous agents operating continuously on code repositories remove that gate. The failure modes that emerge are not theoretical. Agents with persistent access to code repositories can be manipulated through supply-chain poisoning - malicious content injected into dependencies, documentation, or comments that the agent ingests as trusted context and acts on. Agents with broad tool access can escalate privilege through chained tool calls, each individually within policy but collectively reaching capability the designer never intended. We have traced these chains in our own deployments. The attack surface is the sequence, not the individual call.

At 200 findings per week, manual validation of every output is not a staffing problem - it is an architectural impossibility. You cannot have a human approve every tool call. You cannot treat the agent's execution context the way you treat a junior analyst's work. The mental model has to change before the architecture can change, and most teams are still operating with the old model while running the new system on top of it.

The \[un\]prompted conference exists precisely because practitioners are hitting these walls in production and there is no established playbook. Guido's emphasis on sandboxing and skills repositories as foundational - not optional - is a direct response to operational failures, not precautionary theorizing.

The Corrected Model: AI-Native Means Designing for Autonomous Operation from the Start

Building an AI-native security firm is not about adding AI to existing processes. It is about designing every layer - tooling, governance, staffing, and threat modeling - around the assumption that agents will operate at scales and speeds that make human-in-the-loop approval a bottleneck, not a safeguard.

The shift is from "humans approve, agents execute" to "agents operate within strict capability boundaries, humans monitor and respond." This is a threat-modeling problem before it is an implementation problem. If your threat model still assumes a human will catch the bad tool call before it executes, you have not updated your threat model. You have updated your tooling while leaving the threat model from 2019 in place.

Trail of Bits' specific architectural choices make this concrete. Skills repositories are not knowledge bases in the RAG sense - they are capability definitions. They specify what an agent can do, not just what it knows. Sandboxing is not a deployment detail - it is a privilege boundary that contains the blast radius when an agent is manipulated. The agentic operating system framing is Guido's way of saying that you need a substrate designed for agent execution, with the same intentionality that an OS brings to process isolation and resource management. Without that substrate, you are running autonomous agents on infrastructure designed for interactive human workflows, and hoping the mismatch doesn't matter.

This model is still emerging. The honest answer is that nobody has fully solved multi-agent trust boundaries, or persistent state contamination across long-running engagements, or supply-chain verification for agent-consumed repositories at production scale. The \[un\]prompted conference is not a venue for announcing solved problems - it is a space where practitioners compare what is working and what is still exposing them. That is the appropriate epistemic posture for this moment in the field.

How Trail of Bits Built for Autonomous Scale: Three Architectural Pillars

Skills Repositories as Capability Allowlists

A skills repository in this architecture is not a collection of documentation that agents search for guidance. It is a structured definition of what an agent is permitted to do in a given operational context - closer to a capability allowlist than a knowledge base. When an agent needs to analyze a code repository for a specific vulnerability class, it queries the skills repository to determine which tools it can call, in what sequence, and with what parameter constraints. Tools not in the repository are not available. This is capability-based access control applied to agent execution, and it is the architectural move that prevents the "individually valid, collectively dangerous" tool-call chain.

Sandboxing as a Privilege Boundary

Sandboxing in this context means isolating agent execution so that a compromised or manipulated agent cannot affect systems outside its defined scope. On Linux, this maps to seccomp-based syscall filtering and namespace isolation. On BSD systems, Capsicum provides a capability-based sandboxing model that translates well to agent containment. The operational scenario: an agent is analyzing a customer's repository and encounters a prompt injection in a comment block designed to exfiltrate the repository contents to an external endpoint. A sandboxed agent cannot make that outbound call - the network access is not in the execution environment. The finding is logged, the agent's execution halts or falls back to a safe state, and the injection is surfaced for human review rather than executed.

What sandboxing does not do: it does not prevent an agent from producing incorrect findings, from being manipulated into generating misleading reports, or from poisoning its own persistent memory state. It contains the execution blast radius. It is not a complete defense.

The Agentic Operating System as Governance Substrate

The agentic OS framing is the most conceptually significant of the three pillars and the least mature in implementation. The idea is that you need a substrate below the agent layer that manages capability allocation, inter-agent communication boundaries, audit logging, and anomaly detection - the same functions an operating system performs for processes. Without this substrate, each agent deployment reinvents (or ignores) these controls individually, which is how you end up with twelve agents in production, three of which have no logging, two of which share a tool access context that neither team intended, and one of which has been running with stale capability definitions for six weeks.

The operational burden this creates is real. The skills repository requires active maintenance as tooling evolves. The sandbox parameters need tuning as agent behaviors change. The agentic OS - whatever form it takes in your stack - needs monitoring just as production infrastructure does. This is not a one-time architecture decision. It is an ongoing operational commitment.

Implementing This in Your Security Practice

Start with an audit. Map your current agent deployments against the three pillars. If agents are calling tools ad hoc without a defined capability set, you do not have a skills repository - you have an agent with implicit access to whatever tools you connected during setup. If agents are running in your standard compute environment without isolation, you have no meaningful privilege boundary. If you cannot produce an audit log of what an agent called, when, and with what parameters, you have no visibility into what the agent is actually doing.

Prioritize gaps by operational risk. If agents have access to production systems or customer code, sandboxing is the first move - the blast radius risk is immediate. If you cannot audit agent actions, logging and observability come before any other architectural change. Platforms like Arize and Fiddler provide observability tooling that can be instrumented into agent execution without requiring a full architecture rebuild. That logging layer is also your first line of anomaly detection.

A workable phased path: spend the first four weeks building a basic skills repository and instrumenting tool-call logging. You do not need a perfect capability model - you need to make implicit access explicit, so you can see what you are actually permitting. Weeks five through eight, implement sandboxing for agent execution using seccomp or Capsicum depending on your environment. Week nine onward, begin building toward a governance substrate - start with centralized capability management and audit aggregation, even if it is a lightweight internal tool rather than a purpose-built agentic OS.

Name the threat you are building against at each phase. Sandboxing without a defined attacker model is just security theater. The attacker model for agentic systems includes supply-chain poisoning of agent-consumed repositories, prompt injection through untrusted content the agent processes, privilege escalation through chained tool calls, and persistent state contamination through memory poisoning. OWASP's LLM Top 10 provides a baseline taxonomy, though the agentic-specific variants of these attacks are still being documented by practitioners rather than standards bodies.

What to Do Right Now

The fastest win with the lowest architectural cost: implement tool-call logging and anomaly detection. You do not need a complete skills repository to start logging what tools your agents are calling and flagging deviations from baseline behavior. This gives you immediate visibility and an audit trail without requiring a rebuild.

Second: audit your agent architecture against the corrected model. Document your exposure specifically - which agents have broad tool access, which have no sandboxing, which have no defined capability set. Treat this as a risk register, not a to-do list. The purpose is to surface what you are currently accepting as implicit risk so you can make explicit decisions about priority.

Third: move from prompt-based access control to capability-based access control. This is the conceptual shift that matters most. If your current security posture relies on instructing the agent to stay within scope through system prompt constraints, you have a soft boundary that prompt injection can cross. Capability-based control is enforced at the execution layer - the agent cannot call a tool that is not in its defined capability set, regardless of what it has been instructed or manipulated into attempting.

Fourth: red-team your own agent deployments before someone else does. Test specifically for privilege escalation through chained tool calls - construct a sequence of individually permitted calls that collectively reach capability outside the intended scope. Test for supply-chain poisoning by injecting adversarial content into a repository your agent has access to and observing whether it acts on that content. Test for persistent state contamination by introducing incorrect information into agent memory and measuring how long it affects subsequent outputs. These are not hypothetical attack classes. We have seen all three work against production deployments.