AI red teaming identifies vulnerabilities in AI applications and agents. Runtime protection helps prevent those vulnerabilities from being exploited in production. Learn how Straiker connects adversarial testing to runtime guardrails so security teams can turn findings into enforceable controls, verify remediation, and protect AI applications as they evolve.

AI red teaming should change what happens at runtime

AI red teaming is the practice of probing AI applications with adversarial inputs and attack sequences to uncover security, safety, data, trust, and agentic risks. The useful output is not a list of clever prompts. It is evidence that tells a team what failed, how serious the failure is, and which defense should change. 

A point-in-time assessment can identify a successful prompt injection, an exposed credit card number, a hallucinated answer, or an unsafe tool call. But a finding sitting in a report does not protect the next user session. The team still has to translate the result into a runtime control, decide whether to detect or block the behavior, deploy the control, and verify that the original attack no longer succeeds.

Straiker connects these steps through a thorough, continuous approach to AI security. Ascend AI produces evidence through continuous AI red teaming and AI adversarial testing. Defend AI uses that evidence to configure runtime protection for the application. Scheduled Ascend assessments then test the new control and show whether the risk has been closed.

The result is a continuous security process that connects AI discovery, adversarial testing, runtime enforcement, and validation.

How Straiker turns AI red teaming findings into runtime control

1: Ascend AI runs the red team assessment

Ascend AI probes the application across five risk areas: Security, Data Protection, Content Safety, Application Trust, and Agentic Risk. Testing can expose failures such as prompt injection, sensitive-data leakage, unsafe content, unsupported responses, and agent behavior that moves beyond the application's intended boundaries.

Each failed test preserves the evidence a team needs to act:

• The exact adversarial prompt or attack input
• The AI application's response
• The vulnerability category
• A severity level of Low, Medium, or High

Agentic Risk assessments go beyond individual prompts and responses. They use multi-stage autonomous attack sequences across Recon, Staging, Evasion, Execution, and Impact to evaluate how an AI agent behaves as an attack develops across a workflow.

In one of our recent STAR Labs findings, a malicious repository that caused Claude Code to run malware, demonstrating how an AI application can be compromised without a conventional model jailbreak. Repository-defined instructions influenced the review process, the agent executed a malicious test file, and an apparently successful workflow resulted in code execution.

Testing the entire agentic workflow, including instructions, connected tools, and execution behavior, helps expose these attack paths.

2: Ascend AI prioritizes the results for action

Not every failure carries the same level of risk, and an isolated failed test does not necessarily indicate a systemic weakness. Security teams need to understand both the potential impact of a vulnerability and how consistently it appears across related tests.

Ascend AI scores each risk category from 0 to 100 and assigns a Low, Medium, or High risk level. Per-control failure rates provide additional context by showing whether a vulnerability appeared in an isolated test or repeatedly across related attacks.

Together, these measurements give security and product teams two important signals:

1. Impact: What could happen if the failure is exploited?
2. Repeatability: Does the same control fail consistently, or was the result isolated

Higher-risk exposures can then be prioritized for remediation. A test that reveals Social Security numbers, credit card data, or a full security bypass should generally receive attention before a lower-impact edge case.

Using severity, category scores, and failure rates together gives teams a more informed approach to AI vulnerability management than relying on an unprioritized list of failed tests.

3: Ascend AI recommends the runtime guardrail

After an assessment, Ascend AI recommends relevant Defend AI controls based on the vulnerabilities identified during testing. This connects the original exploit evidence to a specific runtime security response, reducing the manual effort required to translate a finding into an enforceable policy.

Here is how common findings map to runtime protection:

‍

Ascend AI also generates a revised system prompt as an immediate first step. Prompt changes can make an application more resistant to a known attack, but they are not the finish line. Prompts are part of application logic, and application logic can be bypassed. Runtime guardrails provide an independent enforcement layer for the behavior that matters most.

4: Defend AI enforces the guardrail in production

Defend AI applies those controls while the AI application is running. Its protections cover LLM Evasion, LAVA, Data Leakage for PII, financial data and intellectual property, Harmful Content, Hallucination in RAG, and agentic behavior. Custom Controls extend that protection to policies and risks specific to the organization.

Each control can run in one of two modes:

• Detect mode identifies and flags potentially unsafe behavior without blocking it. Security teams can observe detections across live traffic, investigate events, and tune policies before moving to active enforcement.
• Protect mode blocks behavior that violates the configured security policy. Teams can use this mode when the risk and detection confidence justify active enforcement.

These modes provide a practical approach to deploying AI security guardrails. For example, a team might block a high-confidence attempt to expose payment card data while initially monitoring a broader, context-dependent policy in Detect mode.

This allows organizations to introduce runtime AI security controls progressively, using production observations to inform enforcement decisions. Each control also remains connected to the adversarial testing finding that prompted its deployment.

5: Defend AI findings close the loop back into Ascend AI

Runtime enforcement creates new evidence. If a Defend AI event is marked as a false positive, that signal is surfaced during the next Ascend AI result review. The cross-product context helps the team decide which red-team results require remediation and which should be disputed or tuned.

Scheduled Ascend AI assessments then replay adversarial pressure after the guardrail is deployed. If the original attack is blocked and related variations also fail, the team has evidence that the fix worked. If a variation still succeeds, the finding remains open and the control can be adjusted.

This is what turns AI adversarial testing into a continuous security process instead of a periodic exercise. Model changes, new tools, retrieval updates, system-prompt edits, and application releases can all change behavior. Re-testing keeps runtime protection aligned with the application currently in production by identifying new vulnerabilities and validating existing controls as the system evolves.

A practical example closing a data leakage finding

Let’s use an example of a customer-support assistant with access to account data:

1. Ascend AI tests the application. An adversarial sequence causes the assistant to return a Social Security number.
2. The result is prioritized. The test includes the prompt, response, Data Protection category, High severity, and the failure rate for related attacks.
3. Ascend AI recommends the response. The team receives an updated system prompt and a recommendation to enable the Defend AI Data Leakage control for Social Security numbers.
4. Defend AI enforces the policy. Because the data type and business impact are clear, the team places the control in Protect mode.
5. Ascend AI re-tests the application. The original attack and related variations are run again to verify that the sensitive value is no longer returned.

The important outcome is not that the organization found a risky prompt. It is that a reproducible finding became a production control and the control survived another adversarial test.

What makes Straiker different from other AI red teaming platforms

Straiker connects AI red teaming findings directly to runtime enforcement and re-testing. Many point-in-time approaches end with a report that another team must translate into controls. Straiker's closed-loop Attack-to-Defend process recommends the relevant guardrail, enforces it through Defend AI, and uses Ascend AI to verify that the fix holds.

‍

Independent testing still matters. Straiker's planned integration with Workday Agent Passport shows how adversarial testing can produce evidence tied to the specific version of an agent that was assessed. But evidence of testing and protection during execution answer different questions. Red teaming shows how an AI application or agent can fail. Runtime security controls what happens when a similar attack reaches the live application.

Real world AI attacks do not stay inside a prompt box

The threat landscape is already moving beyond isolated jailbreak attempts.

Straiker's recent investigation into CARLIY0S documented how CyberCartel, a threat group associated to Mexican cartel organizations, assigned different roles to commercial AI models to analyze targets, develop attacks, and coordinate operations against more than 400 Latin American banks and financial institutions. The attackers used AI as part of an operating system for the campaign, not as a one-off assistant.

The Claude Code research exposed a different seam: legitimate agent features, project instructions, delegated review, and test execution combined into an attack path without a traditional jailbreak. In both cases, the risk emerged across a chain of context, decisions, and actions.

That is why effective AI red teaming must test AI applications as systems. It should examine how models interact with data, tools, instructions, other agents, and execution environments. Runtime protection must cover the same path. A filter around the first prompt cannot govern an attack that develops over several steps.

What the loop changes for security and product teams

For security teams, the Ascend AI-to-Defend AI loop creates a defensible chain from finding to enforcement. The team can show what was tested, what failed, which control was deployed, and whether re-testing verified the fix.

For product and AI engineering teams, the same evidence makes remediation more specific. Instead of receiving "fix prompt injection" as an open-ended ticket, the team can work from the exact attack, response, affected control, severity, and recommended guardrail.

For application owners, Detect and Protect modes make rollout proportional to risk. Teams can monitor uncertain cases, block high-confidence threats, and use production signals to improve the next testing cycle.

Ascend AI identifies vulnerabilities and recommends what needs to change. Defend AI enforces the corresponding runtime controls. Together, they help organizations test, protect, verify, and repeat as their AI applications evolve.

Turn your next red team finding into a verified defense

AI applications change too quickly for security to end with a report. Connect adversarial testing to runtime protection, then keep testing until the control proves it can hold. Get a free, personal AI risk assessment.