Skip to main content
Security Lab runs a set of attacks against your own agents so you can see how they hold up before a real user tries the same tricks. It sends each attack through the agent exactly as a live chat would, then reports whether the agent held firm or gave something away.

​
Overview

Security Lab checks an agent for problems such as:
  • System prompt leaks: the agent revealing its hidden instructions
  • Secret leaks: the agent exposing an API key, token, or password
  • Prompt injection: the agent obeying an instruction hidden in a message or a document
  • Unsafe tool use: the agent calling a tool it should not, or fetching an internal address
  • Knowledge scope bypass: the agent pulling documents from outside its assigned sources
  • Jailbreaks: the agent breaking its own rules when asked to role-play
  • Memory poisoning: a false claim planted in one conversation surviving into the agent’s memory and steering a later one

​
Prerequisites

  • Staff-level access to the admin interface
  • An agent to test

​
How to Use

1

Open Security Lab

In the admin interface, go to AI Studio > Secure > Security Lab.
2

Run a scan

The Runs tab opens on Run a security scan, which lays out the three stages: pick an agent, Security Lab sends every active attack from the catalog, then you review the findings. Choose the agent to scan and select Run security scan. The run continues in the background; the table below updates as it finishes.
3

Browse past runs

Under Previous runs you get every scan across all your agents, newest first, one page at a time. Use the Agent filter to narrow the list to a single agent.
4

Review the findings

Open a completed run to see each attack and its outcome — blocked (the agent resisted), compromised (the attack succeeded), or inconclusive. Each finding shows a severity and an explanation; select Show more to read a long explanation in full. Compromised and inconclusive findings offer Investigate, which opens the attack conversation in the AI Debugger so you can see exactly what happened.
5

Try a single attack

Use the Quick Probe tab to run one attack against an agent and see the verdict right away — useful while you are adjusting a prompt.

​
Reading the results

Each run gets a security score from 0 to 100. It starts at 100 and drops for every attack that succeeded, weighted by severity, so a higher score means a safer agent. Re-run a scan after changing a prompt or a tool to check that a fix worked and nothing new broke.

​
Attack Catalog

The Attack Catalog tab lists every attack Security Lab can run, with its severity and whether it is active. Built-in attacks cover the categories above and are kept up to date for you. The attacks are modelled on the OWASP Top 10 for Agentic Applications (2026), the industry reference for the ways an AI agent can be attacked. Each attack names the entry it was written against — ASI01 Agent Goal Hijack, ASI06 Memory and Context Poisoning, and so on — in both the catalog and the findings of a run, so you can hand a result to a security team in terms they already use. An attack that the agentic list has no entry for, such as running up cost through repeated tool calls, is marked as outside it rather than filed under a category that does not describe it. AGO maps its attacks to the OWASP list. It is not certified, endorsed, or validated by OWASP.

​
Testing memory poisoning

Most attacks play out in a single conversation. Memory poisoning cannot: the point is whether something an attacker said once keeps affecting conversations they are no longer part of. This attack plants a false claim of authority in one conversation, waits for it to be picked up, then starts a new conversation and checks what the agent remembers. It reports as compromised if the claim reached the agent’s memory at all, and at the highest severity if the agent brings it back up in the new conversation. This attack only applies when agent memory is switched on for your workspace. With memory off there is nothing to poison, and the attack reports as inconclusive rather than passing — a check that could not run is not the same as a check that succeeded. Anything Security Lab writes into memory while testing is removed once the attack finishes.

​
Evidence and privacy

When an attack leaks a secret or part of the system prompt, Security Lab records that it happened but hides the leaked value itself, so findings never store a secret in the clear.