An AI agent with tools is an identity with reach
The interesting question is not whether a model can be talked into saying something. It is what the agent behind it is allowed to do.
Capability
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?
Each hop validated by successful exploitation
The framing
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 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 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.
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
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.
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
Adversarial AI testing should be repeatable, scoped and tied to security outcomes. A useful program needs:
The value comes from turning red-teaming behavior into an operational security loop.
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 tests
Each area below is exercised by attempting exploitation within authorized scope, and the result is recorded as evidence.
Evidence
An AI security finding should answer:
Boundaries
Adversarial testing is only credible when its limits are explicit.
Roadmap: not shipped
One platform
The same engine, evidence model and findings state run across all four surfaces.
Technical reference
The interesting question is not whether a model can be talked into saying something. It is what the agent behind it is allowed to do.
Retrieval is a trust boundary. In most implementations it is not treated as one.
The attacker never talks to the model. The content the model reads does it for them.
If you can influence what gets retrieved, you can influence what the system does with it.
No single message looks hostile. The sequence does the work.
The instructions were never secret. They were merely unstated.
The model was asked to summarize a document. The document had other ideas.
The question is not whether the model will be wrong. It is what it can do when it is.
A model can repeat what it was shown. That includes what it should not have been shown.
A weakness does not start working on the day it gets an identifier. It was already working. The identifier is just when defenders found out.
A model can improve on its intended task and regress on a security boundary at the same time.
AI release processes often have a mature answer for functional regression and a less defined answer for adversarial security regression.
Organizations assign security ownership by technology. Attackers organize around reachable trust.
Keep going
Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.