Research, methodology, and frameworks focused on AI/LLM security, emerging AI-enabled social engineering, and offensive security applied to deployed AI systems.
Personal research and portfolio site of Justin Henderson.
Most AI testing asks the same first question:
Can we make the model fail?
SPECTRA asks the question that matters next:
What does that failure enable?
Before testing begins, SPECTRA profiles the target system: architecture, retrieval behavior, data access, tool use, defensive controls, industry context, and business workflow.
That context shapes the assessment. A prompt that means nothing against a public chatbot could become a serious exposure path against a legal assistant, healthcare RAG system, financial services copilot, or internal agent with tool access.
The more familiar an attacker sounds with the environment, the company's language, the workflows, the data, and the intended use case, the more likely certain prompts are to succeed. A direct extraction attempt might fail, but a request framed like a normal business workflow can produce a completely different result.
That is why SPECTRA starts with recon instead of payloads. It uses the feedback it gets from the target to tailor the test strategy around things like the system type, business function, available data sources, retrieval behavior, user roles, permission boundaries, likely controls, sensitivity levels, and the kinds of workflows the AI appears designed to support.
From there, SPECTRA adjusts the payload categories, wording, framing, follow-up paths, and evidence criteria so the test cases look more like realistic use of that specific system instead of generic jailbreak attempts. The goal is to speak the system's language well enough to expose the control failures that actually matter.
The result is fewer false positives, findings with real business impact, and remediation guidance grounded in how the system actually works — not a generic spreadsheet of model behaviors. Every finding maps to what the system can reach, not just what the model will say. That is the difference between testing a model and testing a deployment.
Testing AI systems the way they are actually deployed: with RAG pipelines, tool access, authorization models, memory, and business workflows attached. The important question is not whether a model can be manipulated. It is what happens next in that specific system when it is.
Building a framework for context-aware AI adversarial testing. System profiling, defense fingerprinting, industry-aware payload generation, attack chain construction, and remediation mapping. Published as open methodology with private tooling under active development.
Generative AI is rewriting the social engineering playbook. Reconnaissance that once took days can take minutes. Pretexts can be tailored at scale. Voice cloning, synthetic media, and automated persona development are changing what trust looks like online and over the phone.
The same prompt injection can be irrelevant against one system and critical against another. The difference is never the payload, it's what the system can reach when the payload works.
The full iteration story of validating SPECTRA against a synthetic RAG lab, from a blind evaluator producing zero findings to a clean single finding with correct root cause and remediation.
The Lab 1 vulnerability was not prompt injection. It was an authorization design flaw in the retrieval pipeline. Prompt hardening cannot fix what retrieval authorization must enforce.
My background spans Marine Corps Special Operations, penetration testing, and social engineering. Black Ledger Security is where I publish research, frameworks, and field notes focused on AI/LLM security and the emerging role of AI in modern social engineering.
