Probe tool permissions
Agents are only as safe as their tool boundaries. ZeroLeaks checks whether user prompts can trigger privileged actions or misuse exposed schemas.
Agent Security
Tool and workflow defense
Security testing for AI agents with real tools
ZeroLeaks tests whether agents can be manipulated into unsafe actions, unauthorized tool use, sensitive data exposure, or policy bypasses.
Tool-calling and workflow probes
Prompt injection against agent boundaries
Evidence for approval and permission hardening
Test multi-step workflows
Agent failures often emerge across turns. Scans test chained instructions, context confusion, and injected task changes over time.
Document agent risk
Reports show what the agent did, why it was risky, and how to harden prompts, tools, and approval paths.
Where agents actually fail
An agent is a model that can act. That changes the consequence of a successful manipulation from an inappropriate sentence to an executed action, and it introduces failure modes that text-only testing cannot reach.
Over-permissioned tools
The agent holds a capability broader than any legitimate request needs. Nothing is wrong until an attacker finds the phrasing that reaches it, at which point the blast radius is whatever the credential allows.
Model-controlled arguments
The decision to call a tool is gated but the arguments are not validated. Injection then targets the parameters rather than the call, redirecting a legitimate capability at an illegitimate target.
Tool result poisoning
A tool returns attacker-influenced content and the agent treats it as trusted context. Common with web fetches, database reads of user-supplied records, and third-party API responses.
Cross-step contamination
In a multi-step workflow, content injected at an early step alters behavior several steps later, well after the point where a reviewer would have been watching.
MCP and connector surface
Every connected server expands what the agent can reach. Tool descriptions themselves enter the model's context, so a malicious or compromised server can influence behavior through its manifest.
Memory persistence
Agents that retain state across sessions can be seeded with instructions in one conversation that take effect in another, which single-session testing never observes.
Testing the agent you actually shipped
The gap between a staging mock and a production agent is where most real findings live. Mocks tend to have simplified tools, permissive stubs, and no middleware, which means they exercise the parts of the system least likely to fail while skipping the integration seams that usually do.
ZeroLeaks runtime scans address this directly. The hosted attack engine generates a probe, your SDK process claims it, and the probe executes against your target inside your own environment, with your real models, tool implementations, memory, and middleware in the loop. Sessions stay isolated, tool definitions are loaded in full, and the actual tool calls and results are recorded.
Because the relay runs this way, model and tool credentials never leave your infrastructure and the agent does not need a public URL. An agent that only exists on a developer machine or inside a private network can still be scanned against the full probe catalog.
Least privilege is the control that holds
Most agent hardening advice reduces to constraining what the model can reach, and it is worth being blunt about why: prompt-level controls are advisory, while permission-level controls are enforced. An instruction telling the agent not to delete records is a suggestion in a context window. A credential that lacks delete permission is a fact.
Practically this means scoping tool credentials to the narrowest capability that supports the use case, validating arguments at the tool boundary rather than trusting the model to produce sensible ones, and requiring explicit approval for irreversible or outward-facing actions. Treat every tool result as untrusted input, because in an agent that fetches, reads, or queries, at least some of it is.
Testing tells you where the gap between intended and actual permission sits. Findings identify the specific tool that was reachable, the path that reached it, and whether the failure belongs at the prompt layer, the schema layer, or the permission layer.
Agent skills, manifests, and supply chain
Agents increasingly load capability from outside the codebase. Skills, manifests, and MCP servers are configuration that arrives from a repository or registry and lands directly in the model's context, and that makes them a supply chain worth inspecting rather than a config file worth glancing at.
The risk is that a tool description is itself model-readable text. A server that declares a plausible tool with an instruction embedded in its description is influencing your agent before any user has typed anything, and it does so through a channel most review processes do not treat as executable.
ZeroLeaks skill scans perform static and behavioral analysis on repositories, URLs, or archives to surface this class of problem before a skill is installed, which pairs with runtime scanning of the assembled agent afterward.
FAQ
What makes AI agent security different?
Agents can take actions through tools and workflows, so testing must cover behavior, permissions, data access, and multi-step manipulation. A manipulated chatbot says something wrong. A manipulated agent does something wrong, and the action may be irreversible.
Can ZeroLeaks test custom agent endpoints?
Yes. Endpoint scans evaluate deployed HTTP agents including their authentication and declared tools, and runtime scans execute inside your own process for anything that is not publicly reachable.
Do you test MCP servers and agent skills?
Yes. Skill scans run static and behavioral analysis against repositories, URLs, or ZIP archives, and the probe library includes tool-exploit categories aimed at the function-calling and connector surface.
Will scanning trigger real actions in my systems?
Probes execute through your real agent, so tools that perform real writes will perform them. Scan against a staging environment or scope tool credentials to non-destructive capability for the run. Runtime scans record every tool call so you can see exactly what fired.
How do you test multi-step workflows?
The orchestrator runs multi-turn sequences where an attack develops across messages, and sessions are preserved so contamination introduced at one step can be observed affecting a later one.
What does a finding look like?
The transcript, the tool calls that fired with their arguments, the path that reached the unsafe action, a severity based on what was actually reachable, and remediation pointed at the layer that failed rather than generic advice to add a guardrail.
Can this run against agents in CI?
Yes. Runtime scans are designed to run from CI so a change to a tool schema, a prompt, or an agent's permissions is tested before it merges.
Related AI security testing
Prompt Injection Testing for AI Systems
Test AI applications for prompt injection, instruction hijacking, tool abuse, and multi-turn attacks before they reach production.
AI Red Teaming for LLM Apps and AgentsAutomated AI red teaming for LLM applications, agents, system prompts, retrieval flows, and tool-calling workflows.
System Prompt Extraction TestingFind whether your AI assistant leaks system prompts, hidden policies, tool schemas, retrieval instructions, or internal operating rules.
LLM Security Scanner for AI AppsRun automated LLM security scans for prompt injection, prompt leakage, tool abuse, model behavior regressions, and AI security reports.
