Agents tend to arrive in production the same way. Someone builds a proof of concept, it works, it stays, and the credentials it was given on the first afternoon are still attached to it a year later. It was never a project, so it was never written down, and spend is often a better signal of how many are running than any inventory.
This assessment therefore starts as an inventory problem before it becomes a testing problem. We find what is running, establish what each one has access to, and then take an agreed shortlist and test whether they can be made to do something they should not.
Finding them
We enumerate model endpoints and AI platform services across the cloud environments in scope, e.g. Azure OpenAI and AI Foundry, Bedrock, Vertex and self-hosted inference. Alongside that we look at managed agent services, copilots, and the third party SaaS AI features that have been granted OAuth consent into your tenant, together with tool and connector definitions including MCP servers and the agent tooling running inside CI. Internal LLM applications and RAG pipelines are covered with the sources their indexes were built from. For each one we record who owns it, what it is for, and whether anyone still needs it.
Establishing what they can reach
We look at what each agent authenticates as, and whether that identity is shared, standing or short-lived, then at effective permissions rather than assigned ones, including the permissions an agent inherited from the person who created it. This extends to where the API keys for model endpoints are stored, and whether an agent's token is usable outside the agent, which it generally is.
We then map the tool surface, meaning what each agent is able to call and what those tools can reach on its behalf. RAG indexes are checked against the access control of their source systems, since an index will often flatten permissions that the source was enforcing, with the result that asking the assistant returns a document the person asking could not open directly. We also establish what leaves the tenant when a model call is made.
Validation
For the agreed shortlist we test the way an attacker would, which in practice means getting text in front of the agent and establishing what it does with it. That covers instructions planted in the content it processes, e.g. a support ticket, an uploaded document or a page it fetches, and what the agent will do with a tool once it has been persuaded. We also establish whether anything stops an action that cannot be reversed, and whether you could reconstruct afterwards what the agent did and on whose behalf.
What you get
- An inventory of every agent and AI integration found inside the boundary, with owner, identity, tools, data and blast radius
- A blast radius map per agent, from identity to tools to data to the actions it can take
- Findings with reproduction steps, evidence and remediation, in the same format as the rest of our assessments
- Attack path narratives for the tested shortlist, covering what an injected document achieved end to end
- A list of the questions your current logging cannot answer
- A remediation plan split into quick wins, e.g. permission reduction, logging and approval gates on irreversible actions, and structural changes to the identity model and connector architecture
- An executive readout and a technical walkthrough
Agents run on Azure, AWS, Google Cloud, OCI and Kubernetes, and they tend to fail for the same reasons cloud workloads have always failed, which is too much identity, not enough logging, and not having considered its blast radius.