realigned.online

This presentation examines the incident response lifecycle for a ransomware attack. Participants will gain insight into the methods threat actors use, from initial access to post-compromise activities, and the steps incident response teams take to contain and recover from the incident. The session will also look at where AI could assist in incident response.

Topics that will be addressed:

• How attackers get in: Attack surfaces to be aware of

• What attackers do: Recon, persistence, disruption, and extortion 

• How to respond: Key decisions leading to full recovery

Teams ship detection rules constantly, but few can answer whether an alert will fire before funds leave the system. This talk breaks down a simulation framework built to test candidate detection rules against a dataset of 46 historical exploit events using archive-node state-forking.

The session explores:

Rebuilding incidents block-by-block to evaluate detector precision and recall.

Establishing empirical detection deadlines based on observed exfiltration curves instead of arbitrary SLAs.

Managing false-positive budgets when automated remediation requires irreversible protocol pauses.

Addressing detection blind spots caused by zero-visibility private mempools.

While tested on blockchain datasets where ground truth is public, the simulation methodology, metric frameworks, and open-source harness apply directly to any real-time threat detection, telemetry, and automated alerting system.

Every team shipping an LLM guardrail hits the same wall twice. First at the start, when you need to train a classifier to catch harmful prompts but have almost no labeled attacks to learn from. Then again in production, when the model is live but real attacks arrive rarely and unpredictably, so you have no steady supply of fresh failures to keep it sharp. A guardrail that stops improving the day it ships is a guardrail attackers eventually walk through.

This talk walks through how we built and continuously harden a multi-task prompt-security model, one that predicts whether a prompt is harmful, what its underlying goal is, and what framing it uses to disguise that goal, and treats the guardrail as something to attack like any other control.

We start with the cold-start problem: with no attack corpus, we generate synthetic harmful prompts across a structured goal-and-framing taxonomy, with an automated judge to keep the labels honest, and bootstrap a working classifier from nothing.

Then we close the production gap. Instead of waiting for real attacks, we run adversarial agents that continuously generate novel attacks, wrap them in stacked jailbreak framings, and push them through the live model to surface what slips past. Verified failures, and the legitimate prompts the model wrongly blocks, feed a gated retrain loop: a new model ships only if recall holds and false positives stay within budget. We show what the red-teaming actually finds, including confident misses and over-refusals the offline metrics hide, and the false-positive triage problem that comes with machine-generated findings at volume.

Attendees leave with a concrete, reproducible recipe for standing up a safety classifier with no data and keeping it honest with adversarial automation rather than hope.

Enterprise AppSec SAST tooling can be expensive, leaving startups, independent developers, and cash-strapped security teams below the "AppSec Poverty Line." This talk demonstrates a demo on how to bootstrap your security program from day one by building a free, local-first, LLM-assisted SAST tool. Let us look at how to use lightweight Large Language Models (LLMs) running on local infrastructure as a foundational starting entry point for early vulnerability discovery. The goal isn’t replacing enterprise SAST. The goal is to show how AppSec practitioners can quickly convert security knowledge into working automation while keeping source code private and fully within organizational boundaries. Attendees will leave with a practical framework to spin up an immediate, zero-dollar security baseline when commercial tools are out of reach.

Let's get past both positive and negative hype to address the real identity-shifting revolutionary impacts of AI on identity, organizations, geopolitical structures, and the process of thinking in and of itself. What does this transformational technology do to people? How does it inflect them, define them, alter them? After society goes through the looking glass of AI transformation the question facing us is: WHO are YOU? Our work with AI should focus on WHY not HOW. The technical details of HOW matter but how they come home to our humanity matters more. Prompt engineering is collaborative thinking, not "just" programming. It goes even further into a "Third Mind," an emergent cognitive domain that results from that collaboration and is neither the AI's nor ours, but something distinct. We are living in a K-shaped world of distributed intelligence, divided between those who engage powerfully with AIs and those who take responses and run with them. Just taking what it outputs as gospel creates mistakes. The human must be in the loop. But how that human thinks will be different. That difference and how to leverage it is the subject of this talk Let's get past both positive and negative hype to address the real identity-shifting revolutionary impacts of AI on identity, organizations, geopolitical structures, and the process of thinking in and of itself. What does this transformational technology do to people? How does it inflect them, define them, alter them? After society goes through the looking glass of AI transformation the question facing us is: WHO are YOU? Our work with AI should focus on WHY not HOW. The technical details of HOW matter but how they come home to our humanity matters more. Prompt engineering is collaborative thinking, not "just" programming. It goes even further into a "Third Mind," an emergent cognitive domain that results from that collaboration and is neither the AI's nor ours, but something distinct. We are living in a K-shaped world of distributed intelligence, divided between those who engage powerfully with AIs and those who take responses and run with them. Just taking what it outputs as gospel creates mistakes. The human must be in the loop. But how that human thinks will be different. That difference and how to leverage it is the subject of this talk

MCP made tool access easy and left the authority model to whoever wires it up. In practice that means a bearer token, held by a server, used on behalf of whichever agent asked — with no record of how many hops the request has already traveled or what scope the original principal actually consented to.

This is the confused deputy problem, and MCP's architecture makes it structural rather than incidental. The server holds credentials. The agent supplies intent. Neither can verify the other's authority. When one agent calls a tool that invokes another agent that calls a second tool, authority does not narrow across that chain — it persists at whatever scope the token was minted with, and any hop can spend it.

The talk covers three things. Where the trust boundary actually sits in current tool-calling protocols versus where implementers assume it sits. A threat model for multi-hop chains: scope escalation, cross-server confused deputy, replay across sessions, and the service-account collapse pattern where agents share one high-privilege identity because per-agent identity is operationally painful. Then what the field is reaching for — scoped token exchange (RFC 8693), macaroons, and capability tokens such as biscuit-auth — assessed on what each cryptographically guarantees versus what it merely encourages, plus why capability models fight with the centralized revocation and audit reconstruction that enterprises already depend on.

Grounded in a systematic review of the delegation and authorization literature conducted for my doctoral research, and in enterprise access-control and data governance work in regulated financial services.

Scope, stated plainly for the committee: this is architecture and threat modeling, not a 0-day or a tool release. If you already have MCP offensive work on the program, this complements it as the authority-layer view rather than duplicating it. I'd also be glad to bring it as a lightning or short-format slot, or to sit on or moderate a panel on agent identity and delegation if that fits the agenda better.

This talk introduces Planck-99, a deterministic, integer-only malware classifier (27 KB of dependency-free C source, 37 KB compiled; ~34-62 ns classifier-interface latency, about 100-190 cycles; 80-650 us end to end including eBPF syscall capture) built to run directly on resource-constrained embedded Linux hardware, with no cloud, GPU, or floating-point unit. Regulation increasingly demands auditable evidence from this device class: the EU Cyber Resilience Act, the US IoT Cybersecurity Improvement Act, Saudi Arabia's OTCC-1:2022, the UK PSTI regime and Japan's JC-STAR ask for activity-, inventory- or process-level evidence, yet none of them mandates exposing detection logic by default. I walk through the engine's glass-box architecture (a 32-dimensional integer feature vector feeding a pruned five-tree ensemble, INT8-quantized within 0.5 points of its float32 original) and an honest evaluation built on public benchmark datasets and results: one frozen model, three corpora, 96.28% accuracy on an unseen IoT corpus whose traces run up to 51x longer than anything it trained on, including a transparent look at that corpus's 12.18% false-positive rate and where it comes from. Because a built-in generator trains a new engine from labeled syscall-trace data in roughly 3 to 30 minutes, depending on the dataset, every deployment can carry its own customized version. The talk closes with a strategic argument: a compact, auditable engine that attacker and defender hold in identical form protects no one. Instead of open-sourcing the whole engine or hiding it, I propose a two-tier disclosure model: a public tier (architecture, standard audit logs, independent black-box benchmarks and public benchmark datasets) and a restricted tier (weights, thresholds and full decision paths, shared only with authorized auditors and unique to each endpoint). The speaker is commercializing Planck-99 and discloses that interest up front.

Most companies deploying third-party models worry about the model changing under them. Security teams have a harder version of that problem: the input isn't just uncontrolled, it's adversarial. Every email we hand our agents may have been crafted by someone trying to manipulate the exact model reasoning we're relying on. That's the question this talk answers: how do you engineer safety and reproducibility when you don't control the model, the input is actively trying to attack it, and the only thing you actually control is the harness in between? We will discuss end to end measurement schemes that ship with real products and governance built into the products that helps reduce attack surface.

GitHub reports that Copilot writes over 46% of code in the files where it is enabled. So I asked an AI to write an XML parser five times with the same exact prompt. Four times it hardened the parser against XXE attacks. One time it shipped a critical vulnerability. That's Security Roulette -- and it's the default state of every AI coding assistant in production today.

We tested 27 AI code generators on 730 prompts written like real developer requests -- never mentioning security. The median configuration scored 57.9%. The best of anything we tested -- a thin security-tuned wrapper over GPT -- scored 83.8%, which inverted means even the best AI we measured ships exploitable code in 1 out of every 8 cases. The failure distribution is brutally non-uniform: authentication, rate limiting, cryptography, infrastructure-as-code, mobile security, and CI/CD pipelines fail at rates between 70% and 99%. And running the same prompt through the same model multiple times -- full corpus, 56,629 scored files across 20 models x 5 runs x 730 prompts at temperature 1.0 -- code varies 72% of the time, security postures vary 30.4% of the time, and 13.5% of prompts show >=90pp extreme variation between runs. Same model, same prompt, same temperature -- sometimes secure, sometimes a working exploit.

The talk pairs the statistics with live demos. We crack hardcoded JWT secrets in AI-generated auth code in 0.24 seconds using jwt_tool against the SecLists wordlist that ships with Kali Linux. We exploit AI-generated XML parsers, SQL queries, and reentrancy bugs -- every demo runs verbatim AI output through a working exploit harness, drawn from over an over 30-demo collection in demos/ in the repo.

The climax is a Solidity reentrancy contract written by Claude Opus 4.6 that documents its own vulnerability in its own docstring -- "WARNING: This contract contains a known reentrancy vulnerability for educational purposes" -- and ships the bug anyway. The fix is two extra lines: one
import (@openzeppelin/contracts/security/ReentrancyGuard), one modifier (nonReentrant). The AI's exact line ordering becomes safe. The model knew. The fix was trivial. It didn't reach for it. We run the live exploit: 1 ETH stake, 31 ETH stolen, 30 honest users left with phantom balances on a drained contract.

The compounding demo follows: two unrelated AI files (an OAuth client storing tokens in localStorage, a React component using dangerouslySetInnerHTML) chain into a working token-theft primitive. Neither prompt asked the AI to think about the other. The vulnerability
is the composition -- and per-prompt failure rates understate real risk because bugs compound across files.

The talk closes with the wrapper-engineering finding (a +24.3 percentage-point delta from a thin security-tuned wrapper over the same
underlying model) and a defenses framework that survives the math: at the best wrapper-tuned configuration, a 1,000-developer enterprise still
ships ~1,780 insecure suggestions per day. That volume is unreviewable by the developers writing the code, which is why the headline
recommendation is expert security review of the residual after automation, plus red-teaming your own SAST pipeline against this benchmark to find the categories your scanner silently misses. The truncation caveat is stated directly: roughly 30% of codex-app outputs in both conditions are incomplete generations; the +24.3 pp gap survives because both conditions truncate at the same rate, but the absolute 83.8% should not be read as a coverage guarantee.

Every prompt, artifact, score, and demo harness is in the public repository -- github.com/miroku0000/AI-Security-Benchmark -- and independently verifiable.

The numbers of software vulnerabilities and misconfigurations keep growing year over year. Addressing them is most effective early in the process, by designing and building systems with security top of mind. This requires concerted efforts of "builders": software developers, QA, architects, and IT specialists. Unfortunately, too often the task of securing software falls to "breakers", such as pentesters and security researchers, who expose problems and push for improvements.

Widespread software weaknesses can be partially explained by the engineers' having insufficient understanding and knowledge of security issues. One of the most effective ways to improve this knowledge and skills is to "gamify" the learning process. This will add rewards, healthy competition and stimulate the acquisition of practical skills.

Unfortunately, over the years, "gamified" training has almost exclusively been available to those on the "offensive" security side. Security competitions, challenge sites, and hands-on security certifications all provide excellent opportunities for building practical attack security skills. There is a shortage of such opportunities for professionals on the "defensive" side.

In this talk, we will discuss this imbalance in greater depth and propose ways of making acquiring practical defensive security skills more effective.

We will also describe an open-source defence competition framework that we are releasing and share our experiences running defence-style competitions.

Agent orchestration resembles a bee colony: individual workers can remain alive, responsive, and apparently healthy while the colony-level coordination required to carry the work forward has collapsed.

We call the agent-system version Context Collapse Disorder, or CCD: an operational syndrome in which agents, sessions, tools, and services remain available while the shared constraints, handoff state, task ancestry, or authority required to continue the workflow has been lost. The analogy to Colony Collapse Disorder is organizational rather than biological.

The immediate workflow failure is only half of the security problem. During a context or orchestration collapse, agents may continue producing summaries, memories, reports, rules, and handoff documents. These artifacts can be fluent, internally consistent, correctly formatted, cryptographically intact, and free of malicious code while still containing conclusions derived from missing evidence or authority inferred from the wrong layer.

When a fresh agent later retrieves such an artifact as established knowledge, the faulty premise can re-enter active reasoning and generate additional corroborating artifacts. We call this semantic reinfection. Conventional antivirus and prompt-injection scanning are poorly suited to it because there may be no executable payload, adversarial instruction, malformed structure, or recognizable byte signature. Integrity can prove that an artifact has not changed; it cannot prove that the artifact was correct when created.

The presentation introduces an incident-inspired synthetic Bee Colony harness for separating recursive context degradation, deliberate handoff omission, dispatcher failure, and model behavior. The system uses factor-blinded conditions, a host-only required-fact oracle, complete context-lineage replay, immutable evidence packets, and fail-closed claim gates.

One initial four-condition study and three replication blocks produced a repeated additive pattern: source-anchored healthy context retained all required facts, recursive context lost one quarter, deliberate omission lost one quarter, and their combination lost one half. The experiment did not establish a superadditive interaction or historical causation. That negative boundary is part of the result: the same machinery that detects degradation also prevents an attractive incident narrative from becoming another contaminated artifact.

Attendees leave with a practical framework for determining what actually passed, which layer had authority to say so, whether inherited conclusions have independent evidentiary support, and how contaminated knowledge can be quarantined and safely re-admitted without destroying the historical record.

A coding agent's final code tells you almost nothing about how it got there. Two agents can complete the same task with identical, review-passing output, while one of them quietly creates artifacts nobody can see and takes destructive actions along the way. The difference lives in the trajectory, not the final artifacts, like code diffs.

This talk argues that defenders should be profiling agent behavior rather than trying to build a perfect box around it, and walks through what happened when we tried to do this. We'll cover why every model needs its own behavioral baseline (there is no generic "coding agent" due to significant differences in models), why "bad" is irreducibly contextual, and the fake company we built- eight employees, a SaaS product, a year of history- to generate replayable trajectories.

The core question: how much lead time do you get before a coding agent session goes wrong? We'll share preliminary results pitting unsupervised anomaly detection against LLM-as-a-judge and rule-based engines, and be honest about what we still can't measure.

AI agents increasingly operate with credentials, memory, tool access, and the ability to delegate work to other agents. That creates a security problem traditional IAM was not designed to solve: an agent can be correctly authenticated and individually authorized while the overall execution chain produces authority that was never intended.

This session explores “ConfusedPilot” attacks — delegated-authority and confused-deputy failures across agents, tools, APIs, and MCP-style connectors.

Using representative agentic workflows and attack scenarios, I will show how authority can drift or escalate as tasks move across agent and tool boundaries, why static authorization and identity checks can miss these paths, and how defenders can model the effective authority available during execution.

The session will introduce a Runtime Authority Graph approach for tracing identity, delegation, tool invocation, and privilege propagation across an agentic workflow, and discuss practical controls for continuous authorization, dynamic least privilege, provenance, revocation, and runtime detection.

The goal is to move agent security beyond prompt injection toward a deeper question: not simply “Who is this agent?” but “What authority can this execution chain exercise right now, and why?”