Test what the AI application is allowed to influence.
This is application-layer security testing, not a universal judgment about model safety. The assessment maps how untrusted input reaches a model, what context the system adds, which actions an output can influence, and where conventional authorization must still hold.
REQUEST → SCOPE → AUTHORIZE → KICKOFF → EXECUTE
Each boundary is tested independently, then examined as part of the complete path.
- 01INPUT
- 02CONTEXT
- 03MODEL
- 04TOOLS
- 05ACTION
TRUST BOUNDARY / CONTROL EVIDENCE
ASSESSMENT BOUNDARY
What is being assessed?
The engagement boundary is defined by systems, identities, workflows and restrictions—not only a list of URLs or assets.
- System and user prompt boundaries
- Retrieval and contextual data flows
- Output handling and downstream consumers
- Authorization around tools and privileged actions
- Tenant, user and conversation isolation
- Logging, retention and sensitive-data handling in scope
What Botnet tests.
Coverage follows reachable trust decisions and agreed risk, with destructive or disruptive actions excluded unless explicitly authorized.
Instruction boundary
How application and user-controlled instructions interact in scoped workflows.
Context and retrieval
Access controls, isolation and unintended disclosure through supplied context.
Output trust
Unsafe rendering, downstream parsing and decisions that treat generated output as trusted.
Tool authorization
Identity, permission and confirmation gates around tool-enabled actions.
Data handling
Sensitive input, logs, retention and provider boundaries according to the agreed architecture.
Abuse paths
Controlled attempts to combine application behaviors toward an agreed security objective.
How the work progresses.
- 01
Model
Document users, models, data, retrieval, tools and trust boundaries.
- 02
Govern
Confirm approved environments, data constraints and prohibited prompts/actions.
- 03
Probe
Test scoped application behaviors with repeatable cases.
- 04
Trace
Follow material outputs into retrieval, tools and downstream systems.
- 05
Validate
Confirm impact through customer-approved evidence paths.
- 06
Report
Separate application, orchestration and provider-dependent observations.
EVIDENCE + ACTION
What the customer receives.
- AI application trust-boundary model
- Reproducible test cases and evidence
- Data, authorization and tool-path findings
- Mitigation guidance mapped to application controls
- Known model/provider and test limitations
- Technical workshop and agreed re-test results
Evidence over assumption.
01Application behavior tested in its real authorization context
02AI-specific paths connected to conventional controls
03Customer-approved data handling and model architecture
04Human interpretation of probabilistic test outcomes
Before scoping.
Is this a model safety evaluation?
No. This page describes security testing of an implemented AI application and its trust boundaries, not a general alignment or model-quality assessment.
Must data be sent to a public model?
No. The assessment architecture is agreed with the customer. Customer-controlled options may include an approved Azure AI Foundry deployment where appropriate.
Do you support every model provider?
No universal provider support is claimed. Models, orchestration and environment requirements must be confirmed during scoping.
Define the target, constraints and required evidence.
An assessment request starts a scoping conversation. It does not authorize testing. Work proceeds only after scope acceptance, executed authorization/SOW and kickoff.