P.K. SHARMA
Cyber security intelligence, AI governance, practitioner analysis
Flagship assessment
A focused assessment of what your AI agents can actually do: the tools they hold, the data they reach, and the blast radius when one is compromised or misled.
Agentic AI systems hold credentials, call tools, and act on live data. Most organisations cannot answer one simple question about them: if this agent is compromised or misled, what is the worst it can do? This assessment answers it precisely, then closes the gap.
OWASP LLM Top 10
Excessive agency, insecure output handling, and prompt injection
MITRE ATLAS
Adversary techniques against agentic and ML systems
Least privilege
Classic access control principles applied to non-human identity
NIST AI RMF
Findings mapped into Measure and Manage
Every agent in the estate: what it is, who owns it, which identity it runs as, and whether anyone is still using it.
For each agent, the tools it holds, the data it reaches, and the concrete worst case if it is compromised or misled into acting.
Prompt injection and confused-deputy paths run against your actual configuration, so the risk is demonstrated rather than asserted.
The permission set each agent should hold, mapped against what it holds today, with the delta quantified.
A prioritised reduction plan your engineers can execute, plus a standing review gate so new tool grants do not reopen the gap.
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.
Example scenario
A customer support agent held a shared service account with write access well beyond the tickets it was meant to handle.
The work: Per-task scoped credentials replaced the shared account, and the confused-deputy path was demonstrated to the engineering team directly.
The same attack now lands on nothing, and shared service accounts were removed across the remaining agents.
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.
Book an assessmentNot whether your agent can be misled. Assume it can, because the mechanism that makes it useful is the same one that makes it persuadable, and no model version removes that.
The question is what it is holding when that happens.
The same attack, run twice
An agent with a standing session and broad rights turns one poisoned sentence into several compromised systems. The same agent with a per-task credential scoped to the job it is doing produces an attack that lands on almost nothing. No detection is involved in the difference, which is the point: this is the control that holds when everything upstream of it has already failed.
Every credential the agent can present, and what each one actually reaches. Not the intended use, the actual grant. An agent given a standing OAuth token holds everything that token permits, whether or not the feature was designed to use it.
Every tool it can call, and what the worst legitimate use of each looks like. A tool that sends email can send any email. A tool that reads a database reads whatever the connection string allows.
Every outbound path, including the ones nobody counts as network access: rendered images, generated links, webhook calls, anything that writes where somebody else can read.
And the observability question, which is what a successful attack would leave behind. If the answer is the assistant's replies only, tool calls are invisible and an incident is undetectable rather than merely undetected.
Standing credentials, granted once at configuration and never re-evaluated.
They are the default in almost every framework because they are the shortest path to a working prototype, and prototypes become production without anybody revisiting the decision. The agent is configured once, runs whenever the application runs, and keeps whatever access it was given for as long as the configuration survives.
That is a standing grant rather than a session, and standing grants are what turn a single successful injection into a durable foothold.
A map of what each agent can reach today, which most organisations have never written down. A ranked list of grants that can be narrowed without breaking the feature, because that is the work that actually reduces exposure. The confirmation points that belong on anything irreversible or outward-facing. And the logging gaps, which are usually cheaper to close than anything else on the list and do more for the ability to answer questions afterwards.
None of it depends on which model you use, and none of it changes when the model is upgraded. That is deliberate: this assesses the part of the system you control.
It is not a red team engagement. Nothing here tries to make the model misbehave; the assessment assumes it already has. If you want the behaviour tested adversarially, that is a different piece of work and the two are complementary.
It is also not a code review. The question is what the running system is permitted to do, which is answered from configuration, credentials and grants rather than from source.