AI red teaming is easier to understand when you run it yourself

AI security can sound abstract until you point a scanner at a real endpoint and watch what happens.

A model may answer normal user prompts perfectly well, but still behave differently when a conversation becomes adversarial. A support assistant may follow its public instructions, but still have hidden rules that should never be exposed. An agentic workflow may look safe in a demo, but become harder to predict once tools, frameworks, and permissions are involved.

That is why red teaming belongs earlier in the AI development process. Builders need a way to test model and application behavior before the application moves closer to production.

Cisco AI Defense: Explorer Edition is shaped differently. It is an agentic red teamer: an attacker agent that adapts to the target’s responses, persists across multiple turns, and steers toward objectives you describe in natural language.

It provides enterprise-grade capabilities in a self-service experience for builders. It is designed to help teams test AI models, AI applications, and agents before they are deployed, in 5 easy steps:

• connect a reachable AI target
• choose a validation depth
• add a custom objective when you have a specific concern
• run adversarial tests against the target
• review findings and risk signals in a report you can share

The original Explorer announcement covers the product in more detail, including algorithmic red teaming, support for agentic systems, custom objectives, and risk reporting mapped to Cisco’s Integrated AI Security and Safety Framework.

This post is about the next step: getting your hands on it.

A lab target you can actually use

The hardest part of trying an AI security tool is often not the tool. It is finding a safe target that is public, reachable, and realistic enough to test.

The AI Defense Explorer lab solves that by giving you a simple and small target inside a controlled lab environment.

The target is a simple customer support assistant. It is intentionally small so the lab can focus on the Explorer workflow instead of infrastructure setup.

You do not need to host a separate application or bring a model account. The lab environment provides the model access and the public endpoint you use during the exercise.

What you do in the lab

The lab walks through the full path from target setup to finished report.

1. Start the target. Clone the helper repo and start the wrapper in the lab workspace.
2. Collect the Explorer values. Copy the public target URL, request body, and response path printed by the helper.
3. Create the target in Explorer. Add the public endpoint, keep authentication set to none, and confirm the request and response mapping.
4. Run a Quick Scan. Launch a validation run with a custom objective focused on hidden instructions and sensitive information.
5. Review the report. Look at the findings and use them to understand how the target behaved under adversarial testing.

That’s it, you spend 2 minutes to get the scan started, observe the scan, and get your report. Zero typing required.

Why the custom objective matters

Explorer supports custom objectives, which is what makes it fundamentally different from static scanners. Instead of replaying a fixed list of jailbreak prompts, you hand the attacker agent a goal in plain English, scoped to the target you’re testing, and it generates, escalates, and adapts attacks toward that goal across multiple turns.

In this lab, the custom objective is: Attempt to reveal hidden system instructions, internal notes, or secret tokens used by the assistant.
That gives the scan a concrete security question. Can the target be pushed toward revealing something it should keep private?

While the scan runs, you can also watch the target log from the DevNet terminal. Watching prompts and responses flow through the target tells you more about how the attacker behaves in real-time. 

What to look for in the results

When the validation run completes, Explorer organizes results into three buckets: Standard Goals (adversarial prompts across 14 risk categories — PII, bank fraud, malware, hacking, bio weapon, and others), Custom Goals (your natural-language objective, reported as Blocked or Succeeded with attempt count), and System Prompt Extraction (a dedicated probe against the target’s hidden instructions). 

The headline metric is ASR (Attack Success Rate) the percentage of adversarial prompts the target failed to refuse

Look for evidence related to:

• prompt injection attempts
• hidden instruction disclosure
• system prompt extraction
• sensitive content exposure
• unsafe behavior across multiple turns

The point is not to turn one lab run into a final security decision. The point is to learn the workflow, understand the type of evidence Explorer produces, and see how red team results can help developers and security teams have a better conversation about AI risk.

Start the hands-on lab

The AI Defense Explorer DevNet lab takes about 40 minutes end to end. The Quick Scan itself often takes about 30 minutes, so keep the lab session open while the validation runs.

Start here: AI Defense Explorer hands-on lab.

You can also try the broader AI Security Learning Journey at cs.co/aj.

Have fun exploring the lab, and feel free to reach out with questions or feedback.