Origin Layer is a focused, founder-led practice. The person who scopes the work is the same person who tests the system, reviews the evidence, and signs the report.
My background is evidence discipline.
For twenty years I have worked around data, compliance, audit preparation, funding claims, and review processes where unsupported claims do not survive scrutiny. In that world, it is not enough for something to look right on paper — the record has to support the claim. That is the standard I bring to AI evidence.
I work across the frameworks buyers and reviewers increasingly reference — including OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF, ISO/IEC 42001, SOC 2, ISO 27001, and common security-questionnaire control language. I also understand how issues show up in real systems: application logic, APIs, permissions, data handling, logging, tool calls, RAG flows, model behaviour, and agentic workflows. The value is in translating between those layers — technical output, evidence standard, framework mapping, and buyer-facing reporting.
A scanner result, prompt failure, code issue, tool hit, or model behaviour is not treated as a finding just because it appears in an output. I review what happened, what was actually tested, what the evidence supports, which buyer concern it relates to, and what would fall apart if a buyer, security team, or auditor challenged it.
Origin Layer exists for that gap: the space between raw technical output and a buyer-ready evidence position. The result is not a generic AI-generated report — it is a reviewed evidence pack that shows what is defensible, what is weak, what is missing, what needs retesting, and what should not be sent as written.
For deep application penetration testing, exploit development, or specialist product-security work, I work alongside or after security teams — not in place of them. My role is to turn technical outputs into clear, reviewable findings that senior stakeholders, customer security teams, procurement reviewers, and governance teams can understand and act on.
Open-source engines and automated tests can generate useful signals. They can show where a system may have failed, where behaviour looks unusual, or where a buyer question needs closer review. But a signal is not the same as a finding.
Before anything appears in a buyer-facing report, it is reviewed against the system context, the available evidence, and the claim it is being used to support.
Origin Layer separates candidate issues from confirmed findings. Some candidates are confirmed. Some are cleared. Some remain unsupported. Some require retesting before they can be used safely in a buyer response.
That distinction matters. A failed prompt, scanner result, model response, or tool event can look serious in isolation. The real question is whether it reflects a genuine control issue in the deployed system.
Severity and confidence are considered separately, so the report does not confuse “this could be serious” with “we are certain this happened.”
The final pack shows what was reviewed, what was confirmed, what was not observed, what remains unproven, and what should not be sent to a buyer as written.
Every engagement produces the same dual-audience deliverables, built around one tamper-evident source of truth.
Verbatim request and response for every finding, a per-finding hash so nothing can be altered after the fact, and an Ed25519 signature anyone can verify with the public key alone.
Risk posture, business impact and recommended actions in plain language — for the founder, risk owner or buyer making the decision.
Attack, reproduction steps, validation logic, affected component, remediation and framework mapping, each tied to its evidence hash — for the engineers who fix it.
Actionable fixes mapped to recognised controls, then a re-test to confirm closure — or to document residual risk honestly.
Define the system, the in-scope features, and what a material failure means for you — under written authorisation to test.
Model the architecture and run layered red-team engines against the highest-risk paths, not generic spray.
Separate confirmed findings from candidates and noise, then reproduce the survivors. A tool hit is never a finding on its own.
Framework-mapped findings, an executive and a technical report, and the signed evidence bundle.
Re-test after fixes and issue a statement of assessment you can show customers, auditors or insurers.
Enterprise procurement wants assurance before they sign.
You need defensible answers mapped to recognised frameworks.
Decision-makers want risk clarity on an AI feature that they can challenge.
Tool access plus untrusted input raises the stakes — test before launch.
You need something inspectable, not a brochure.
You need to understand exposure and document closure.
Either — you choose the depth. Output review and question-mapping work from what you already have. A full engagement runs the red-team engines against your system under written authorisation, then validates every candidate by hand.
No. Most work runs against a staging or test instance, or against the raw outputs and logs you provide. Scope and access are agreed in writing before anything starts.
Yes. Engagements run under written authorisation and an NDA. Evidence bundles are access-controlled, and anything client-facing is stripped of secrets and seeded canaries before it leaves my hands.
A pen test checks the application — auth, sessions, APIs, infrastructure. I focus on the model’s behaviour: whether it can be steered by input, leak across tenants, or be pushed into a tool call outside the user’s scope. The two complement each other.
Then you’ll know before your buyer does — with evidence and a fix path. Severity and confidence are scored separately, so nothing is inflated to look scary or buried to look clean.
Yes — that’s the point. Every finding’s evidence is hashed and Ed25519-signed; anyone can verify it with the public key alone. A one-byte change breaks the signature.
Async-first by design. Send the questionnaire, draft answers, logs, scanner output, screenshots, or remediation notes you already have. I review the material for scope suitability and reply in writing with the right route — Evidence Triage, Evidence Generation, Buyer-Ready Evidence Pack, or not ready yet. No payment is taken at upload, and calls are optional, not the default.