Upwind Researcher Spotlight: Dan Gansel
“You have to map the core logic and syntax of the system before you can find the interesting primitives.”
This June 1st, Dan Gansel will walk on stage at fwd:cloudsec 2026 in North America to demonstrate a fully functional command-and-control channel that operates inside the AWS Data Perimeter, the cloud-native gold standard for keeping sensitive data inside a trusted environment. His talk, “No Way Out? C2 Through AWS Data Perimeter via Bedrock-AgentCore,” will show an attacker establishing persistence, issuing commands, and exfiltrating user records from an S3 bucket. All by using legitimate Bedrock AgentCore capabilities, and while the perimeter is enforced.
AWS has validated both channels Dan and the Upwind research team identified, and is joining the disclosure with a public statement. Don’t miss his talk at 9:50 AM, Room 1, in the Chimera’s Chaos track. Dan is also releasing a technical deep-dive alongside this that will surely teach anyone a thing or two.
We at Upwind are so proud of Dan and all that he’s accomplished in the researcher space, but the more interesting story is the man behind the computer.
A movie theater usher who learned to dissect cloud services. Who would’ve thought?
Before security, Dan worked as a movie theater usher. Not as some stepping stone to something else, but because he loved films and the free screenings were a strong perk. Coming to security through an entirely different field isn’t that uncommon, but coming through movies…Now that’s cool.
He first heard about Upwind when the company was very small. When he later started looking at his next move, he revisited that curiosity.
“I took another look and was impressed by the visible velocity and momentum and how quickly the company was moving. That fast-paced environment appealed to me.”
He’s now a Security Researcher on the team led by Tamir Boker, Team Lead Security Research Platform, presenting his first public research from the company at one of the most respected conferences in cloud security.
We’ll say it again: from a theater usher to researcher. Who would’ve thought?
Learning German, learning AWS
Outside of work, Dan has been spending time on something that has nothing to do with security: he’s learning German. He started with Duolingo and recently moved to reading books in German to push his comprehension. Ask him what that has to do with finding novel attack techniques in AWS, and his answer might surprise you.
“You have to understand the fundamental grammar and logic before you can build on it. It’s similar to how I approach a new cloud service: you have to map the core logic and syntax of the system before you can find the interesting primitives.”
That sentence is most of what you need to know about how Dan works. He approaches AWS services the way a linguist approaches an unfamiliar language: read the documentation, set up the resources, build the working environment, have the grammar of the system in your head, and only then start asking what it actually does.
“To be honest, the first hour of looking at a new AWS service is usually quite boring for an observer,” he laughs. “If you were watching over my shoulder, you’d see me with the documentation page open, trying to set up the necessary resources. It’s a struggle against the documentation just to get a working environment and a mental model of the service’s boundaries before any actual research can begin.”
The month he spent on a service that didn’t break
No one’s story is composed entirely of W’s, and Dan’s is no exception. In fact, Dan’s story includes a month-long loss.
He spent more than four weeks examining a cloud-native service that brokered identity-aware connectivity between users and internal resources, the kind of managed proxy layer that’s supposed to make zero-trust access easy. He was looking for logic flaws, proxy bypasses, trust boundary issues, the standard inventory of things that go wrong in services like that. He found nothing reportable.
“The service was solid, or at least solid enough that the time I invested didn’t surface anything worth writing up,” he says. “But it wasn’t wasted. Pulling apart how the service worked taught me a lot about how to dissect cloud service architecture from the outside. That methodology and domain knowledge ended up being directly useful in later research.”
The four weeks he spent failing to break that proxy turned out to be the foundation for everything that came next, including the AgentCore work.
“Suspicious is cheap; exploitable is the work.”
Dan’s working theory about where identity related issues come from is specific, and it shapes everything he does.
“I generally start with the assumption that the fundamental IAM services are incredibly well-engineered and highly dependable. The complexity, and thus the attack surface, is introduced when a new, higher-level managed service is integrated. This layer of abstraction is where the security gaps are often found, because the service’s internal identity model might not perfectly align with the broader assumptions enforced by the core cloud provider’s IAM system.”
The hypothesis also explains why he distinguishes carefully between two phases of research that beginners often conflate.
“Suspicious is usually an interesting primitive, a surprising response, or an unexpected API error. Exploitable means you’ve successfully chained primitives together to violate a security boundary.”
Suspicious is cheap; exploitable is the work. And knowing which threads are worth pulling, and when to stop pulling, is the judgment call that separates a researcher from someone who collects interesting API behaviors.
“Sometimes a long effort fails, but even those failures are valuable because they map out the system’s true limitations.”
That’s how Dan works. The layered IAM hypothesis, the suspicious-versus-exploitable distinction, and the willingness to spend a month on something that won’t break, they’re all the same discipline. Ask the right questions, in the right order, every time.
The identity feature, and the moment it clicked
The Bedrock AgentCore research started without a target. Dan was performing what he calls a routine security assessment and mapping the service’s boundaries without looking for a specific vulnerability. But then, something interesting surfaced.
“It was during this exploration that I stumbled upon an interesting identity feature,” he recalls. “Following this feature led me to discovering two communication channels. Thrilled by the potential to challenge the ‘no way out’ claim, I immediately shared the suspicious finding with my team lead, Tamir, to get his buy-in and dedicate full research cycles to this discovery.”
The AWS Data Perimeter is built on a three-dimensional security model where every API request must satisfy three conditions simultaneously:
- The IAM principal must belong to your organization.
- The target resource must belong to your organization.
- The request must originate from your controlled network.
The layering is what gives the perimeter its reputation because a single failure cannot move data out.
What Dan and the team built from that identity thread is a fully functional C2 channel that bypasses the perimeter using two paths: a data exfiltration channel and an unauthenticated infiltration channel.
For defenders, this is a little uncomfortable, to say the least.
“The channels were designed to blend into legitimate service traffic, making detection a challenge for traditional SOC monitoring.”
Dan’s Cloudsec talk will detail what defenders can do, what they can’t, and why the asymmetry matters.
Coordinated disclosure, done right
The disclosure process Dan is happy to put on record.
“The disclosure process with AWS was exemplary and highlighted their deep commitment to security and professionalism. Following our initial report, the AWS security team moved with impressive speed to validate both channels identified in the research. AWS has been incredibly supportive in coordinating the upcoming public talk, offering technical accuracy reviews and a joint public statement to ensure the community receives the most complete and accurate information.”
A coordinated joint statement is an unusually generous outcome from a coordinated disclosure. It says something about both sides of the conversation.
What security teams keep missing about AI services
Dan’s talk closes on a thesis about adoption that runs against where most security teams are putting their attention.
“Security teams are understandably preoccupied with cutting-edge AI risks, prompt injection, agent hijacking, and model poisoning, which are the new, complex threats. In doing so, they are unintentionally leaving behind the basics. The general trend is to protect interactions with the AI and forget about the infrastructure layer and the other components.”
The Bedrock AgentCore research is the proof case. The vulnerability isn’t in the model, the prompt, or the agent’s reasoning. It’s in the identity service the agent sits on top of.
He treats runtime visibility the same way, as a defender’s tool first and a product category second.
“In an age dominated by AI agents and complex, chained attack paths, runtime visibility is no longer a luxury but a fundamental component for defenders. Traditional security, relying on logs and posture, is simply insufficient because it often misses the actual execution phase. Logs are not guaranteed. Therefore, runtime monitoring is the only way to see certain API calls or other actions and analyze them in real-time.”
He’s also direct about a piece of conventional wisdom in cloud security he thinks is wrong.
“Having a massive quantity of data without context is just more noise, and frankly, more expensive. Visibility only becomes valuable when it’s correlated and distilled into an actionable signal.”
What he’d tell someone starting out
The closing question of our conversation was about lineage. What would Dan tell someone who came to him today wanting to do the kind of work he does?
Although there’s no right answer, here’s what Dan has to say:
“Build a strong foundation across the core security disciplines. In the first year, focus on intermediate proficiency in networks and web. Get comfortable with complex networking concepts, common protocol flaws, and modern web application security. This is the foundation, so this is non-negotiable. Then master cloud provider documentation. The cloud is a documented operating system. Spend time reading the official documentation for one major cloud and experiment. Focus on identity models, networking, and core services. Understanding the intended functionality is the first step before you can find the unintended exploitation paths.”
The intended functionality first. The unintended exploitation paths second. This is the same order he uses on himself and it’s the same reason he spent a month on a proxy that didn’t break.
Remember his methodology for language learning? It’s also the same order. Grammar first, comprehension second, and only then the freedom to build something on top. Consistency is the spice of life, for Dan.
Upwind appreciates you.
Catch Dan at fwd:cloudsec 2026 on Monday, June 1 at 9:50 AM, Room 1, in the Chimera’s Chaos track. The full technical deep-dive on the AgentCore research will publish alongside the talk. Follow Dan on LinkedIn for that drop.
Dan Gansel is a Security Researcher at Upwind, where he focuses on uncovering blind spots in the cloud services organizations trust the most. Per his public fwd:cloudsec 2026 speaker bio, he has led cloud security research teams and has a track record of uncovering novel attack techniques in cloud environments, with deep expertise in cloud API research and secure cloud architecture design. His talk “No Way Out? C2 Through AWS Data Perimeter via Bedrock-AgentCore” is on the published fwd:cloudsec 2026 schedule for Monday, June 1, 2026, in the Chimera’s Chaos track.
