- How is this different from a standard penetration test?
- A conventional pentest treats the application as the system under test and the model as an opaque dependency. We treat the model, its context window, its tools, and its infrastructure as one system — because an attacker does. Findings that only appear when you chain a prompt-level trick to a cloud-level misconfiguration are the ones that get missed by teams that only own one half.
- Do you need access to model weights?
- No. Most engagements are black- or grey-box against a deployed endpoint, which is the attacker’s actual vantage point. Weight access, training data, or fine-tuning history helps for alignment evaluation and lets us reason about why a behaviour occurs rather than only that it does — but it is never a precondition.
- Will testing damage production or pollute our data?
- Scope, rate limits, and data handling are agreed in writing before anything runs, and we default to a staging environment mirroring production configuration. Where production is genuinely the only meaningful target, we agree explicit blast-radius limits and a rollback path first. Any data encountered is handled under the engagement’s NDA and destroyed on completion.
- What do we actually receive?
- A written report with reproducible proof-of-concept for every finding, severity rated against exploitability in your deployment rather than a generic scale, and remediation guidance specific to your stack. Plus the harness — the test cases become yours, so regression testing does not require hiring us again.
- Do you publish what you find?
- Never client work without written permission, and never with identifying detail. Novel techniques that are not client-specific may be written up generically for the research surface, always after remediation and always with the client’s sign-off on the wording.