Agent frameworks and orchestration
LangGraph and LangChain, LlamaIndex, AutoGen, the OpenAI Agents SDK, MCP and custom orchestration, identified with the version actually deployed rather than the one in the README.
Someone added an MCP server to the agent last sprintIt shipped with write access to production
Maps what your agents are actually built from — frameworks, model providers, SDKs, MCP servers, prompt and tool schemas, dependencies, secrets and provenance — then finds the vulnerable packages, poisoned artifacts, unsafe defaults and dangerous capabilities among them.
See the programme
One of eight domains in AI Security Assurance
How It Works
Enumerate, resolve, inspect, rank.
01
Enumerate
Repositories, lockfiles, container images and agent manifests are read to find every framework, model provider, SDK and MCP server the estate actually depends on.
02
Resolve
Each dependency is resolved to its true origin and provenance, so a package that arrived transitively through an agent framework is attributed rather than hidden behind it.
03
Inspect
Prompt and tool schemas, default configurations and declared capabilities are inspected for what they permit — not only what they are documented to do.
04
Rank
Findings are ranked by the capability they unlock and where that capability is reachable, so a write-and-delete tool on a production identity outranks a stale package nothing calls.
What You Can Do
Everything it maps.
MCP servers and their tool schemas
Every connected server enumerated with the tools it exposes and the arguments they accept, because the risk lives in the capability the schema permits, not in the server's description.
Models and providers
Which models are called, by which components, through which providers and routes, including the ones reached directly from code rather than through the approved gateway.
Dependencies and SBOMs
A software bill of materials for the agent stack, with transitive dependencies attributed to the framework that pulled them in, so ownership of a vulnerable package is never ambiguous.
Vulnerable and poisoned packages
Known-vulnerable versions and artifacts showing signs of tampering or typo-squatting, flagged against where they are reachable rather than as a flat advisory list.
Secrets in the agent path
Credentials in prompts, configuration, environment and code, including the API key pasted into a system prompt where no secret scanner was looking for it.
Unsafe defaults
The settings that ship permissive — unrestricted tool use, disabled confirmation, verbose error output, unbounded autonomy — found before they are inherited into production.
Dangerous capabilities
Shell execution, filesystem write, network egress, credential access and deployment rights surfaced explicitly, so the blast radius of a compromised agent is known in advance.
Provenance and integrity
Where each artifact came from and whether its chain of custody holds, which is what separates a reviewed dependency from one that appeared in a lockfile without a pull request.
Prompt and tool schema drift
Changes to prompts and tool definitions tracked over time, because the schema that was reviewed at design time is rarely the schema running six sprints later.
Business Outcomes
What it changes.
Known
You can answer what the agent is built from and what it is permitted to do, which is the question neither the code review nor the cloud console answers on its own.
Attributed
Every dependency resolves to an origin and an owner, so a poisoned artifact has a named path in rather than an argument about who introduced it.
Bounded
Dangerous capabilities are surfaced before they are inherited, so the blast radius is a decision rather than a discovery during an incident.
Know what your agents are actually made of.
Point it at the repositories and manifests behind one agent workload and get the frameworks, servers, models, dependencies and capabilities back with their provenance.