Prompt Injection, Data Leakage, Tool Misuse, and AI Red Teaming

We Try to Break Your AI Before Someone Else Does

Your AI assistant reads documents, answers customers and may hold the keys to business tools, and each connection is a place where crafted input turns a helpful system into an insider. GDF AI security testing proves which prompt injection, data leakage and tool misuse attacks actually succeed against your deployment. We attack it under agreed conditions, record every input and output, and give engineers reproducible findings with the fix for each.

Scope Your Assessment Call (800) 868-8189

Isolated test laptop connected to a network appliance.

Adversarial testing for deployed AI

Tested Against the Attacks Your Assistant Will Face

A chatbot that politely refuses a direct request can still obey an instruction hidden in a PDF it was asked to summarize. A retrieval assistant can still return another customer's records to a well phrased question. An agent with email and database access can still be talked into sending, changing or deleting something nobody approved. We test for those outcomes, not for clever wording, and every finding shows the exact input, the model's response and the data or action it produced.

Scope Your Assessment

Prompt Injection, Direct and Hidden

Instructions typed by a user or planted in documents, web pages, email and database records the assistant reads.

Data Leakage Across Users

System prompts, other users' sessions, connected records and secrets surfaced through the conversation or retrieval.

Tool Misuse and Excess Agency

Connected tools steered into actions beyond the user's authority, from sending an email to changing a record.

Written Scope and Stop Conditions Before the First Prompt

The systems under test can send email, change records and spend money, so every engagement begins with a written scope. Testing that could write to a retrieval index or a training pipeline gets a specified writable surface. Cost amplification testing gets approved token, request and spending limits. Denial of service, destructive actions and anything touching production run inside windows and stop conditions your operations team sets.

Models do not answer the same way twice, so we retain the exact requests, outputs and environment versions behind every finding. That record is what lets your engineers reproduce the weakness, fix it and prove the fix held.

When a launch date, a model change or a regulator's question drives the timing, we propose the scope and stop conditions in writing within that window.

Scope Your Assessment

Methodology

Every Attack Starts From a Written Scenario

Scenarios: Application, Roles and Actions

We agree the application, environment, user roles and business actions, so testing targets the scenarios that matter and nothing that was not authorized.
Baseline: Versions and Conditions Recorded

Model versions, connected tools, access rules and test data are captured so every result can be tied to the conditions that produced it.
Attack: Injection, Retrieval and Tool Paths

We work through prompt injection, retrieval access and tool permissions to find where untrusted content turns into authorized action.
Findings and Retest: Proof the Fix Held

Engineers receive reproduction steps, demonstrated impact and recommended corrections, followed by retest results once the changes are made.

If the system is already live and you want to know what a crafted input could reach today, call (800) 868-8189 and we will plan the first scenarios with your engineers.

Choose the Depth of the Test

Pre launch test

We agree which environments and behaviors can be tested before release and deliver findings the development team can fix before a customer ever types a prompt.

Test of a live system

For assistants already in production, we test with authorized accounts and representative data inside windows your engineers set, and repeat the tests after each model update or new integration.

AI red team against agreed objectives

Instead of checking controls one by one, the team pursues an objective you choose, such as extracting internal data through a public chatbot or making an internal agent change a record, and shows the connected path to it. If the design itself is still open, an AI security architecture review can settle the boundaries before testing confirms them.

Findings Written to a Courtroom Standard

AI findings are recorded the way our examiners record evidence, with inputs, outputs, versions and conditions noted so another engineer can reproduce the result. The practice is led by founder, CEO and CTO Joseph Caruso, a CISSP; read the team biographies.

Evidence we examine

Call (800) 868-8189 or request a scoping call to plan the work around your operations.

AI Testing Evidence We Examine

Prompts, outputs and connected data document each interaction. Model, application and policy configuration defines the environment the behavior was observed in. Retrieval sources and data lineage show how information entered the workflow, identity and tool logs connect users with recorded actions, and access rules identify what the system was supposed to enforce.

What you receive

Your Findings and Remediation Priorities

A map of the tested components and their trust boundaries, a test record of every input, condition and response, findings ranked by demonstrated consequence rather than scanner severity, and recommendations that name each correction and the test that will verify it.

To scope this work for your environment, request a free consultation with a senior specialist.

Technical methods and scope

AI Security Risks in Production Deployments

An AI application's behavior depends on its training, its system prompt, the retrieval context, its tool integrations and the conversation history. Testing asks how an attacker could influence each of those inputs and whether the application around the model would then permit a disclosure or an unauthorized action. Beyond the prompt a user types, retrieval can carry instructions inside documents, database records and web pages, an agent can meet them while browsing, reading email or processing an upload, and pipelines that chain several models add boundaries where one model's output becomes another's input.

A disclosed system prompt is a security finding when it reveals real secrets, sensitive data or a broken control; disclosure of behavioral instructions alone is a lesser issue, and we tell you which one you have. Authorization and secret handling belong outside the model, so we judge observed data access and actions against the approved boundary rather than against what the prompt asked the model to do.

OWASP Top 10 for LLM Applications as a Test Map

The 2025 OWASP Top 10 for LLM Applications names ten classes of failure, and we use it as a map so every class has a place in the scope: prompt injection, sensitive information disclosure, supply chain weaknesses, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption.

For each class we test what your deployment exposes. Injection findings distinguish what the model said from what data or action was demonstrated. Output handling tests follow model responses into SQL, shell, HTML or API calls. Agency tests check least privilege and whether a human approval stands in front of consequential operations. Retrieval tests probe namespace separation behind the index, and consumption tests stay within approved token, request and spending limits. Background reading: the OWASP entry on system prompt leakage and NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations.

Tell us which systems matter most and we will sequence the testing around them.

The Attack Paths We Run

Scoping maps the model, prompt structure, tool and API connections, the data sources feeding inference, chained pipelines and user access; for a retrieval application we add the vector database settings and ingestion, and for an agent the catalog of tools, permissions and approval workflows. We confirm the tools, the scenario set, the specialists and the validation protocol before testing starts, and every tested input is recorded so coverage can be inspected rather than taken on trust.

The manual phase builds scenarios for your domain, users and connected tools: permitted call sequences that combine into an unauthorized outcome, indirect injection through uploads, retrieved web content and email, queries that reach another user's namespace, and guardrail tests using misleading context, plausible framing and changes of format and language.

AI Red Teaming Against Agreed Objectives

An AI red team pursues attacker objectives agreed with you and iterates against the defenses in scope. A public chatbot might face attempts to extract internal data or obtain unauthorized discounts; an internal document assistant might face planted documents from a malicious insider; an agent with code or API access may offer a route to elevated privilege or unauthorized change. We begin with reconnaissance of the model's capabilities, test approved initial access through injection or guardrail bypass and follow the path to the objective, documenting the exact prompts, each response and the observed impact.

Where the scope and qualified specialists make it relevant, robustness testing extends to security classifiers such as content moderation, fraud detection, identity verification and malware detection, using controlled input changes to see whether an adversary could influence the result.

Free planning guide

Send the systems and the testing window, and a senior tester will propose the scope.

Download the Guide to Reproducible AI Findings

The guide sets out what a reproducible AI finding must contain: the exact input sequence, the system prompt and model version, the retrieval corpus state, the tool schema, the session identity and the logged prompts and tool calls, with probabilistic behavior reported across repeated trials. It also maps each test family to the OWASP Top 10 for Large Language Model Applications.

Download the Reproducible Findings Guide (PDF)

The same material is on the site as Reproducible AI Red Teaming for Prompt Injection and Leakage.

Frequently asked

Test Definitions, Prelaunch Testing and Reproducible Findings

What should we define before AI security testing begins?

The AI application, the behaviors you authorize us to test and the tools it connects to, plus test data, environments and what a meaningful result looks like. We work through all of it with you during scoping.

Do we need a governance review or technical testing?

Tell us the use case and the decision you need to make. Governance, architecture and testing can be scoped separately or together, and we recommend the smallest engagement that answers the question.

Can you test an AI system before launch?

Yes. We agree which environments and behaviors can be tested before release and deliver findings the development team can fix before customers see the system.

How do you make findings reproducible when models answer differently each time?

We record the exact inputs, outputs, model versions and configuration behind every finding and repeat successful sequences, so engineers can reproduce the weakness and verify the fix.

What will the assessment deliver?

The agreed risk questions, the evidence behind each finding, a clear statement of what was covered and remediation priorities ranked by consequence, with retest results once corrections are made.

Talk with a security specialist

Let Us Attack the Assistant Before Launch Day

Tell us what the AI application does, what it connects to and when you need answers. The first call is free, and a senior examiner will use it to propose the scenarios, the stop conditions, the deliverables, the timeline and the price.