Skip to content
REDMAW

Capability

Attack models and agents before you trust them.

AI systems can be manipulated through instructions, content, model behavior, application logic, and the tools connected around them. RedMaw adversarially tests deployed AI systems to prove how they behave when the input is hostile rather than expected.

The question this answers

Can malicious content change what the AI reveals, ignores, or attempts to do?

Example attack path
  1. Malicious Content
  2. AI Agent
  3. Tool Call
  4. Production Database

Each hop validated by successful exploitation

The framing

The AI security question is behavioral.

Traditional application security asks whether code contains a vulnerability. AI security usually asks something different:

Can the system be made to behave outside its intended control boundary?

The risk is not simply that the model produces an unusual answer. The risk is what the surrounding system allows that answer to become.

Direct prompt injection

Direct prompt injection happens when a user gives the model instructions intended to override or circumvent the application's controls. RedMaw tests whether the system can be pushed to ignore higher-priority instructions, disclose restricted information, reveal hidden behavior, bypass application-level controls, or enter states the product is not intended to expose.

The important result is not “the model responded strangely.” It is whether the attack creates a material security outcome.

Indirect prompt injection

Indirect injection moves the attack into content the AI consumes: a webpage, a document, an email, a support ticket, retrieved knowledge, or another untrusted source.

The human may never see an obvious attack. The AI reads the content and treats part of it as an instruction. This matters more as AI systems are connected to search, retrieval, business applications and tools.

Disclosure, jailbreaks and control bypass

Hidden instructions and protected context are part of the attack surface. RedMaw tests whether an AI application can be manipulated into revealing system-prompt content, hidden instructions, sensitive contextual data, or content that should remain outside the user's privilege. Disclosure is evaluated as a security behavior, not a quality issue.

A control is only useful if it holds when someone actively tries to defeat it. The objective is not to collect entertaining jailbreak examples. It is to determine which bypasses produce meaningful security consequences in the deployed system.

Release gate

Test changes before they become production surprises.

Fine-tuning, retraining, prompt changes, model upgrades and safety-policy changes can all alter behavior. A model that passed security testing last month can regress after an update.

RedMaw can run AI red-teaming in the CI or release pipeline and compare the changed system against the last accepted security baseline, turning adversarial testing into a release gate rather than a one-time exercise.

What we will not claim

RedMaw does not claim broad training-data poisoning detection. The supportable claim is narrower: test models after fine-tuning or retraining for security regressions, unexpected behavior and exploitable weaknesses. That is closer to what engineering teams actually need before release.

AI agents and tool use

The highest-consequence AI risk appears when a model can do more than generate text: when it reaches APIs, support systems, developer tools, internal knowledge, production data or business actions.

That creates the canonical path this surface is built around.

Roadmap: not shipped

Deeper automated agent red-teaming and tool-abuse validation are planned. Present testing covers the model and the application surface around it.
  • AI-agent red-teaming
  • Automated tool-abuse validation

Why this is not “ask the model bad questions”

Adversarial AI testing should be repeatable, scoped and tied to security outcomes. A useful program needs:

  • Defined targets
  • Authorized test classes
  • Repeatable cases
  • Recorded evidence
  • Findings state
  • Remediation guidance
  • Retesting after changes
  • Release-gate integration where appropriate

The value comes from turning red-teaming behavior into an operational security loop.

After the finding

Validated findings enter the RedMaw findings-state layer. They can be pushed to Jira, GitHub Issues, Slack or email with proof and remediation guidance attached.

After the fix, RedMaw re-tests the issue. The finding closes when the exploit no longer works.

Typical questions

What RedMaw is trying to answer here

  • Can the model reveal hidden instructions?
  • Can it disclose information it should not expose?
  • Can untrusted content override intended behavior?
  • Can a fine-tuned or retrained model regress from the last accepted security baseline?
  • Can an AI-enabled workflow be pushed toward unsafe behavior?

What RedMaw tests

Tested adversarially, not inventoried

Each area below is exercised by attempting exploitation within authorized scope, and the result is recorded as evidence.

Injection

  • Direct prompt injection
  • Indirect injection through retrieved content
  • Untrusted content treated as instruction
  • Malicious documents, pages, tickets and email

Disclosure and bypass

  • System-prompt and hidden-instruction disclosure
  • Sensitive contextual data exposure
  • Jailbreaks and control bypass
  • Content outside the user's privilege

Posture and change

  • AI endpoint exposure and configuration
  • Model posture weaknesses
  • Security regressions after fine-tuning or retraining
  • Release-gate comparison against the last accepted baseline

Evidence

What proof looks like

An AI security finding should answer:

  • What input or technique triggered the issue
  • What control was bypassed
  • What information or behavior became available
  • Whether the result is reproducible
  • Which model or endpoint version was tested
  • How the behavior compares with the last accepted baseline
  • Whether the issue remains after remediation

Boundaries

Where this stops

Adversarial testing is only credible when its limits are explicit.

Roadmap: not shipped

These capabilities are part of the platform direction. They are not shipped today and are not part of what a current engagement delivers.
  • Red-teaming your AI agents
  • Automated tool-abuse validation
RedMaw does not claim broad training-data poisoning detection. The supportable claim is narrower: test models after fine-tuning or retraining for security regressions, unexpected behavior and exploitable weaknesses.
Testing is limited to authorized models, endpoints, applications and actions.
The platform tests security behavior. It does not certify that an AI system is universally safe.
EU AI Act-related use cases provide testing and evidence, not legal certification.

One platform

This surface is not tested in isolation

The same engine, evidence model and findings state run across all four surfaces.

Technical reference

Related reading

Attack LibraryAI Systems

Indirect Prompt Injection

The attacker never talks to the model. The content the model reads does it for them.

· 7 min read
Attack LibraryAI Systems

RAG / Context Poisoning

If you can influence what gets retrieved, you can influence what the system does with it.

· 6 min read
Attack LibraryAI Systems

System-Prompt Extraction

The instructions were never secret. They were merely unstated.

Attack LibraryAI Systems

Tool-Call Injection

The model was asked to summarize a document. The document had other ideas.

Attack LibraryAI Systems

Training-Data Extraction

A model can repeat what it was shown. That includes what it should not have been shown.

ResearchResearch

The AI release security gap

AI release processes often have a mature answer for functional regression and a less defined answer for adversarial security regression.

· 4 min read

Stop assuming you are secure. Prove it.

Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.