P.K. SHARMA
Cyber security intelligence, AI governance, practitioner analysis
Flagship assessment
A framework-driven security assessment of your AI estate: threat modelling, architecture review, and adversarial testing mapped to the OWASP LLM Top 10, MITRE ATLAS, and NIST AI RMF.
AI features ship faster than security teams can review them. This assessment applies a published, repeatable framework to your AI estate: threat modelling, architecture review, and hands-on adversarial testing, with findings your engineers can act on the same week.
OWASP LLM Top 10
The reference attack classes, tested hands-on
MITRE ATLAS
Adversary tactics and techniques against AI systems
NIST AI RMF
Findings mapped into Measure and Manage functions
What the system does, what it holds, who can reach it, and what the worst realistic outcome looks like. Rules of engagement agreed in writing.
Model choice, retrieval pipelines, tool grants, session handling, and trust boundaries reviewed against the threat model.
Hands-on attacks: prompt injection, data exfiltration, insecure output handling, tool abuse, and the failure modes specific to your design.
Every finding rated for severity and exploitability, with reproduction steps and the business consequence stated plainly.
A prioritised fix plan, then a retest cycle that confirms the fixes hold rather than assuming they do.
Example scenario
A company was two weeks from launching a customer-facing RAG chatbot with access to its knowledge base.
The work: Adversarial testing found an indirect prompt injection path that exfiltrated other customers' data through the retrieval layer.
The launch went ahead on schedule with the retrieval layer redesigned; the same attack now lands on nothing.
Example scenario
An internal agent platform had accumulated broad tool permissions during development, and nobody could say what a compromised agent could reach.
The work: Blast radius analysis per agent, then a least-privilege target model and a permission rebuild in priority order.
Agent permissions cut by more than half with no workflow breakage, and a standing review gate for every new tool grant.
Start the conversation
A short call to understand your situation; a clear scope if the engagement fits, and a straight answer if it does not.
Request an assessmentAn application test asks whether the software can be broken into. It examines code paths, dependencies, authentication and configuration, and a clean result holds until one of those changes.
An AI system fails differently. The code can be correct, the dependencies current and the configuration sound, and the system will still do something harmful because text arrived that it treated as an instruction. Nothing in a conventional test is looking for that, and nothing in it would find it.
What a clean result actually establishes
That difference decides how the engagement is scoped, how findings are written, and what a pass is worth. It also means the two are complementary rather than alternatives. An organisation that has penetration tested its AI application has tested the application, not the behaviour the AI was added for.
The failure mode of AI security work is a report full of transcripts showing a model saying something odd. That is not a finding, and it is why security findings about AI get filed and forgotten.
A finding worth acting on names four things. What the system did, stated as an action rather than as output. How often it reproduced, because four in ten and one in a thousand are different problems. The conditions it was found under, meaning model version, system prompt, temperature and conversation length, since all four move the result and all four change. And the design change that closes it, rather than a patch, because the durable mitigations here are architectural.
A finding missing the reproduction rate cannot be prioritised. One missing the conditions cannot be retested after the next model upgrade, which is the exact moment it most needs retesting.
Four things are testable, and scope usually stops after the first two.
The model, under adversarial input. The application, meaning how untrusted text reaches the model and what the surrounding code does with the output. The tools and agency, which is what the system can read, write, send, pay or delete once persuaded. And the organisation, which is whether anybody would notice and who decides what happens next.
The last one produces the findings clients least expect and most often need. "This cannot be detected afterwards" is usually cheaper to fix than "this can be jailbroken", and it does more.
Judgement about where the exposure sits, from somebody who has done this before, and a written account of what was tried and how far it got.
Not a certificate. The method cannot support one: a model returns a distribution, so a clean result means these behaviours were not elicited by these people in this time against this configuration. Anybody offering a certificate at the end of an AI red team engagement is selling something the technique does not produce.
The work is performed personally rather than passed to a delivery team, which is the reason the scope is what it is.