How We Red-Team Cognigy Agents for Security, Using Ziran

Conversational AI agents built on platforms like Cognigy don't sit still. Every prompt tweak, every new flow, every added tool integration changes the agent's attack surface. The instinctive response is to treat security testing like unit testing: run the full suite on every change, catch regressions immediately, sleep well.

That instinct breaks down fast once the "test" is an adversarial conversation against a live conversational AI platform. Unlike a unit test, a security probe against a deployed agent isn't free or instantaneous — it's a real session, consuming real inference calls, sometimes touching real backend integrations, taking real wall-clock time to play out a multi-turn manipulation attempt. Multiply that by a comprehensive attack library — prompt injection variants, jailbreak patterns, tool-misuse attempts, data exfiltration probes, social-engineering flows — and running the entire catalog on every change stops being a testing strategy and starts being a cost and latency problem. This is the core tension in Cognigy agent security testing: the same probes that make a test meaningful are the ones that make running all of them, always, unaffordable.

The failure mode isn't subtle. Run everything, every time, and one of two things happens: the checks get so slow and expensive that teams quietly stop running them on every change, or the checks get quietly thinned down to something fast and shallow enough to survive CI — at which point they stop catching anything real. Neither outcome is acceptable for something as consequential as agent security.

A security check that's too slow to run often, or too shallow to catch anything real, is the same failure wearing two different costumes.

What's actually needed is prioritization — a system that decides which attacks are worth running, against which changes, at which cadence, before anything touches the live platform. That's the problem the pipeline below is built to solve.

The architecture: deciding what's worth testing

The pipeline for red-teaming Cognigy agents has three conceptual phases. The first — and largest — is entirely about triage: figuring out what's worth attacking before any attack actually runs.

Change Implemented is the trigger: something about the agent changed — a flow, a prompt, an integration, a permission — and that change is what the rest of the pipeline reasons about. Nothing downstream runs in a vacuum; it runs in the context of what just moved. From there, seven planning stages decide what's worth testing:

1. 1

   Security Research Agent. Gathers context before deciding what to test — what kinds of weaknesses are known to affect systems like this one, what's changed about the threat landscape, what classes of failure are relevant to a conversational agent with this one's capabilities.

2. 2

   Threat Modeling. Turns that research into a structured picture of what could go wrong — not a generic checklist, but a model of this agent's specific exposure: what it can do, what it's connected to, where an adversarial conversation could push it somewhere it shouldn't go.

3. 3

   Knowledge Graph. Maps the threat model onto a structural representation of the agent itself — its flows, its tool chains, its decision points — so "what's exposed" is a queryable graph the rest of the pipeline can reason over, not a paragraph of prose.

4. 4

   Hypothesis Generation. Generates concrete hypotheses from that graph: specific ways an attacker might try to manipulate this specific agent, given its specific structure. This is where "prompt injection is a risk category" becomes "here are the particular paths through this agent where it might matter."

5. 5

   Risk Scoring. Scores each hypothesis — likelihood, potential impact, how directly it connects to something the agent can actually do — so the pipeline can tell a high-value target apart from a theoretical curiosity.

6. 6

   Cost Optimization. Weighs scored hypotheses against the cost of actually testing them — session time, inference spend, execution complexity — to find the set of campaigns that gives the best signal for the resources spent.

7. 7

   Campaign Selection. The output of the planning phase: a concrete, bounded set of attack campaigns to actually run, sized appropriately for the moment — a small set for a routine change, a larger set for a scheduled deep assessment.

Everything from Security Research Agent through Campaign Selection is offline, planning-stage work — it decides what to test, before anything touches the live agent. Whether that planning phase is itself LLM-driven end-to-end is still an open, actively evaluated design question, not a settled answer. It would be easy to write this section as though the reasoning chain from research to campaign selection is already a proven, autonomous pipeline; it isn't yet. What's settled is the shape — research feeds threat modeling feeds a structural graph feeds hypotheses feeds scoring feeds cost-aware selection. How much of that reasoning is automated versus assisted is still being worked out.

Actually attacking it: Ziran in action

Once a bounded, prioritized set of campaigns is selected, execution happens using adaptive AI red-teaming — Ziran, an independent open-source project. Ziran isn't something built in-house — it's a third-party engine, and campaigns selected upstream are handed to it as the thing that actually runs the adversarial conversations: multi-turn, adaptive attacks that can adjust their approach mid-conversation based on how the agent responds, rather than replaying a fixed script.

This is the one stage in the pipeline that's genuinely execution, not planning — real sessions against a real agent, driven by real (if adversarial) conversational turns. It's also exactly why the upstream prioritization work matters so much: this is the expensive, slow part, and the entire point of the planning phase is to make sure only the campaigns worth running actually get here.

Turning results into a verdict: security analysis and scoring

A completed adversarial campaign produces a transcript, not a verdict. The final stage's job is to close that gap: take what happened during execution — what the agent revealed, what it refused, where it deviated from expected behavior — and turn it into something a team can act on, a scored, categorized read on what the campaign actually demonstrated.

The tooling and metrics meant to do that are still under investigation, not finalized. Turning an adversarial transcript into a reliable, well-calibrated verdict is a hard problem in its own right, and it's being treated as one rather than assumed away. What's fixed is the role this stage plays in the pipeline — the boundary between "a campaign ran" and "here's what it means" — not yet the mechanism that fills it.

Why this is worth building: matching test depth to cadence

The payoff of this structure isn't any single stage — it's what the separation between planning and execution makes possible. Because campaign selection is cost-aware and risk-scored, the same pipeline can support genuinely different testing cadences without needing different tooling for each:

1. 1

   PR-level check. A small, cheap, high-confidence set of campaigns scoped tightly to what actually changed — fast enough to sit in a normal review loop.

2. 2

   Nightly run. A wider net, catching things too expensive to check on every single change.

3. 3

   Weekly or release-gated assessment. Goes deep — larger campaigns, more adversarial variety, closer to exhaustive within a still-bounded budget.

That's the actual alternative to "run everything, every time." Instead of one scan that's forced to be either too slow to run often or too shallow to catch anything real, the cost-optimization and campaign-selection stages let the same pipeline dial its depth to match the moment — cheap and fast where speed matters, deep and expensive where thoroughness matters, without maintaining two separate systems to get there.

There's a longer-term shape to this too: as agentic AI systems increasingly talk to other agentic systems — MCP-style tool access, agent-to-agent coordination — the attack surface stops being "one conversational agent" and starts being a graph of interacting systems. A pipeline that already reasons about an agent's structure as a knowledge graph, and already separates "what's worth testing" from "how to attack it," has real room to extend in that direction rather than needing to be rebuilt for it.

Where this fits at Shyena: Cognigy red team vs. quality testing

Shyena's core evaluation product tests Cognigy conversational and voice agents for correctness and quality. Security red-teaming, using Ziran as the execution engine, is a related but distinct capability — one built around graph-based discovery of an agent's tool chains, detection of execution-level side effects, and adaptive multi-phase campaigns rather than fixed attack scripts. Read more about how this Cognigy red team capability works on our security page. The pipeline described here is the architecture we're building toward to make that capability practical to run continuously, not a system we're claiming is fully proven end to end today — the planning-phase automation and the analysis/scoring tooling are both still active work. What's settled is the shape: prioritize before you attack, attack adaptively using Ziran as the engine, and score honestly before drawing conclusions. Teams that want this pipeline run as a managed engagement rather than built and operated in-house can see how that works on our services page.

Frequently Asked Questions