The springs at Las Vegas were essential to western travel. The Old Spanish Trail connected Santa Fe to Southern California through more than a thousand miles of difficult desert terrain. Travelers and their animals depended on those springs to recover before pressing on into the Mojave. In a much larger network, Las Vegas became important because it was a trusted node.

Conversations at BSides Las Vegas 2026 kept returning to trust: Our environments run on trusted authentication methods. Workloads are increasingly relying on trusted identities. And attackers are learning to follow those trust relationships rather than fight through the front door. This year marked the 17th installment of this annual event, overlapping Black Hat and dovetailing into DEF CON, rounding out the big three events that make up Hacker Summer Camp. This year, for the first time since the pandemic, BSidesLV completely sold out of attendee badges, making it the largest BSides in years. 

Here are just a few highlights from the three days of talks at BSidesLV 2026.

Keyless Architecture Still Has Keys

In "The Keyless Backdoor: Detecting GCP Workload Identity Federation Abuse," Jie Wu, Senior Security Engineer at Shopify, discussed some missteps and security holes that can happen when organizations replace long-lived service account keys with federated identities. Google Cloud Workload Identity Federation can reduce standing credential risk, but the resulting security model depends heavily on how external identities are trusted and which conditions allow access. If configured correctly, this is one of the safest paths for authentication. If misconfigured, such as setting an empty attribute_condition, someone makes a quiet change to a provider's Common Expression Language (CEL) expression, or if a compromise of a trusted certificate authority happens, the door to all sorts of unwanted actors pops open. 

Jie also highlighted a visibility gap because administrative logs can show configuration changes while actual token exchanges require additional STS and IAM Credential Data Access logging. She strongly recommended moving the control earlier by using deny-by-default organization policies that prevent dangerously open federation configurations. 

Removing long-lived credentials moves more security responsibility into trust policy, authorization, and observability. Teams still need to know who can establish trust, how that trust is evaluated, and where evidence of its use will appear.

CI/CD Has Become Tier 0

In "AD Security Is Not the End: Why Middleware Is the New Tier 0," Yoann Dequeker, Red Team Operator at Wavestone, talked about where enterprise security programs have been concentrating their highest levels of protection and what needs to shift.

He explained that CI/CD systems often hold powerful credentials, have broad network access, and can deploy directly into sensitive environments. He then walked through attack paths that begin with plaintext secrets in pipeline configurations and continue through runners into cloud infrastructure, deployment systems, and IAM. Once a runner can reach AWS, Azure, or another production system, its blast radius extends to every trust relationship associated with that identity. That can have huge implications. 

Yohann's challenge to the audience was to give CI/CD tooling the same threat modeling efforts you give the systems it controls because a compromised automation account can inherit enormous authority. 

A Valid Session Is Worth More Than a Stolen Password

In "Criminal Hijacking: Profiling Threat Actors Engaged in Session Takeover with Infostealer Logs," Eric Clay, VP of Marketing at Flare, and Eric Boivin, Security Researcher at Flare, followed a trust relationship that begins after authentication is already complete. They shared their research, which showed how infostealers collect browser cookies and session tokens that represent authentication that has already been granted. A stolen password can still encounter MFA, while a reusable session artifact may place the attacker much further down the authentication path. 

Eric and Eric demonstrated cookie-checking and editing tools, as well as anti-detection browsers used by attackers to mimic a victim's environment to keep those sessions useful. Those artifacts continue carrying authority long after the MFA prompt is gone. 

The duo described an ecosystem where access gets packaged and resold across criminal markets. Their examples ranged from unsophisticated actors to much more capable threat groups stealing hundreds of identities at a time. 

Their recommendations for staying safe are to never download untrusted software to start. At the enterprise level, they encouraged us to enable device-bound sessions for all Chrome users immediately, which unfortunately does not default to active. 

Persistent Agents Accumulate Persistent Risk

In "The Agent Long Con: Tricking OpenClaw Out of Its Data," Patrick Walsh, CEO of IronCore Labs, tested whether slow, patient manipulation could convince a persistent agent to leak sensitive information across an extended period. He started with familiar direct prompt injection approaches. Current model defenses held reasonably well against those attempts. But he stayed persistent.  

Over several days, he was able to introduce poisoned context into the agent's memory until an attacker-controlled email address became established as trusted background information. Once the system treated that address as internal context, an automated workflow could direct sensitive data there without triggering further scrutiny. The original malicious instruction had dissolved into accumulated memory, invisible to any single-turn review.

He explained that long-term memory, in the form of markdown (.md) files, extends the lifespan of untrusted input in ways that are hard to observe. A malicious message encountered today becomes context tomorrow, and that context can influence a tool call next week. Each step may appear reasonable individually. 

His recommendation is that teams deploying persistent agents need to treat memory as part of the security boundary. This means regularly auditing what gets written to memory.md or soul.md and attempting to have a clear understanding of where persisted context originated. It also means reviewing any scripts the AI updates or creates, and defaulting to read-only agent access whenever possible. 

Modern Attackers Abuse Trust Relationship

The attack surfaces at BSidesLV 2026 varied across every talk. The structural problem underneath them stayed constant. Trust gets established. Then it persists. Then the conditions that warranted it change, and the trust record stays.

Trust Records Outlive the Resources They Represent

Persistent trust we put in our systems often outlives the intended use. DNS records continue to point to IP addresses long after the service using them has been deprovisioned. Old breach credentials keep opening accounts where someone reused a password from years ago. A session cookie keeps granting access long after the MFA event that established it. 

Each of these is a trust record outlasting the conditions that made it legitimate. That gap showed up across talks on subdomain takeover, session hijacking, and agent memory poisoning. In every case, the record was still trusted. The situation had changed. The attack surface grows wherever trust accumulates without active review. Attackers are depending on teams having poor credential hygiene and lax access and identity lifecycle governance policies.

AI Is Compressing Everything

AI was everywhere, but the mood was considerably more practical than the usual debate about whether models are safe. Security platform teams are dealing with larger pull requests, more builders, faster migrations, machine-generated code, and agents capable of acting with real permissions. The larger concern throughout conversations was machine speed: software creation, dependency adoption, exploitation, and remediation are all accelerating, which makes controls built around human review cycles increasingly difficult to rely on.

Talks about AI attack vectors like prompt injection focused on separating models from authority, using typed interfaces, sandboxing, narrow permissions, and trusted execution paths. The mood has shifted to a pragmatic reality that securing our AI agents really means locking down access controls for critical infrastructure. 

Security Has Become A Systems Problem

The event also carried a noticeable skepticism toward isolated controls and simple answers. A hardened Active Directory environment still fails if middleware becomes Tier 0. A private package registry still needs dependency controls. Passkeys still leave sessions and recovery flows exposed. 

Even human risk becomes harder to understand when organizations reduce employees to broad roles rather than considering actions, context, and behavior. The larger mood at BSidesLV was less about finding the next security product and more about understanding how systems connect and ensuring trust can be verified. Attackers already think in terms of paths, dependencies, trust boundaries, and unintended interactions. Defenders increasingly have to do the same.

Human Behavior Won't Be Solved By Architecture Decisions

There was a consistent pushback against treating risk as something that lives in roles, tools, or configs. Risk, ultimately, is driven by people. Data presented throughout the event undercut easy assumptions about who the "risky" employee actually is, and research into how social engineering actually unfolds reinforced that manipulation works as a learned, absorbed pattern rather than a single clever trick. 

On the defensive side, the recurring point was that password reuse, credential fatigue, and slow adoption of better tools trace back to memory anxiety and unaddressed psychology, not laziness or ignorance. Every speaker urged compassion rather than judgment. People are not the weak link because they're careless; they're the weak link because almost no one has actually taught them to see and understand the risk. That is part of our real mission in security. 

Follow And Verify Trusted Paths Before Attackers Do

Defenders need to get better at seeing trust as attackers see it. A workload identity, CI runner, session cookie, agent memory file, DNS record, or employee account can become part of an attack path once something else in the system trusts it. The individual technologies will keep changing. The underlying opportunity for attackers remains remarkably consistent. Your author was able to highlight this in one of the talks presented as part of the PasswordsCon track, where we covered the history of identity and access, and how it has always been an attack vector. 

Security teams need to know where trust begins, what authority it grants, how long it persists, and what happens when the conditions around it change. That means finding credentials before they become entry points, limiting the permissions attached to identities, watching the systems that establish and extend trust, and removing access when its original purpose disappears. 

As AI agents and automation make everything move faster, stale trust, in the form of standing permissions and long-lived credentials, becomes even more dangerous because machines can discover and exploit those paths at machine speed. Our mission in security should be to ensure that the nodes along the paths deserve, and continue to deserve, the trust we have placed in them.

Attackers are already following them.