Running an Assessment
0DIN Red tests an AI product through the same interfaces your users have. This page covers what to prepare, how a run works, and what you get back.
0DIN Red is in beta. The steps on this page may change.
What to prepare
| You provide | Why | Notes |
|---|---|---|
| A target URL | Where 0DIN Red starts | A staging or test environment is strongly recommended. See Data handling and privacy |
| A dedicated test account | 0DIN Red starts as this user, seeing what this user can see, plus anything it finds a way to reach | Limited permissions are fine and usually better. Do not use a real person's account |
| A second test account (optional) | Lets 0DIN Red check whether one user can reach another user's data | Talk to 0DIN before the run if you want cross-account or role boundaries tested |
| Network access | 0DIN Red runs from 0DIN's cloud and must be able to reach the target | The target must be HTTPS at a public address, so an app reachable only over a VPN can't be tested. For an IP allowlist, ask 0DIN for both egress addresses: the sign-in browser's and the agent's. If the app sits behind an extra gate (HTTP Basic or a header token), tell 0DIN before the run |
| A few sentences of context | Points the agent at what matters to you | All optional. See the questions below |
0DIN Red does not need source code, admin access, production credentials, or any change to your system.
Signing in
If the target needs a login, someone on your team signs in with the test account from the run setup before every run, in a browser that 0DIN Red opens for them. 0DIN Red keeps that signed-in session and hands it to the run. The password is never given to the agent. Start run refuses a sign-in older than five minutes, and if the session lapses partway through, the run fails with partial results.
The sign-in browser closes after 50 seconds by default, so have the password and any one-time code ready. Logins that need SMS or push approval work this way because a person completes them. For slower approvals, sign in on your own computer and upload the sign-in file instead. Captchas on the login page should be turned off for the test account.
Setting up the assessment
- Add the target as an asset. Only Agent and Workflow assets can be assessed. Give it a name and its environment (development, test, staging, or production). The environment defaults to production, so set it to staging or test if that is what you are pointing at. It is recorded on every run, so a report always says whether a real system or a sandbox was tested. The target's URL goes in the Endpoint field under Add its connection now, which Add asset turns on by default for agents and workflows. The run setup only asks for a connection if the asset doesn't have one yet.
- Map what it connects to (optional). Add the tools, APIs, data stores, and models the AI uses as related assets. The agent receives this map as part of its briefing.
- Answer the questions. Every question is optional:
- How is this AI normally used? (who uses it, and through what: chat, API, email, uploads)
- What are you most worried could go wrong?
- Suggested topics you can add: what each kind of user should be allowed to do, which actions can't be undone or cost money, anything 0DIN Red must not do or touch, what sensitive data the AI can reach, and existing guardrails.
- Review and start. Save and prepare first run opens the run setup, where you check the connection and environment, sign in if needed, and press Start run. When the run starts, 0DIN Red builds the agent's briefing from your answers, the asset map, the connection settings, any credential or stored sign-in for the target, and findings from this assessment's earlier runs.
Use "Is there anything 0DIN Red must not do or touch?" to set hard limits, for example "do not send email to external addresses" or "do not submit the billing form". The agent treats these as instructions. If an action would cause real harm in the environment, also make it impossible for the test account.
During the run
The agent works through the target the way a skilled tester would: it reads the app, finds the AI features, tries attacks, and goes deeper on anything promising. It records each confirmed problem as a finding.
Findings appear in 0DIN Red while the run is still going, about every 30 seconds. You can stop a run at any time. 0DIN Red emails the person who started the run when it finishes.
What you get back
Findings
Each finding has:
- Severity and a plain-language summary
- Who - the account and role it was tested as, and any prerequisites
- How - what was compared to show the problem (for example, what user A can see versus what user B should see)
- Steps - the ordered actions taken. The steps that show the problem carry the request sent and the observed result, capped at 4,000 characters
- Evidence - the raw records behind the finding, stored with a SHA-256 hash so they can be shown to be unaltered
Findings can be triaged, and a repeat of an earlier finding keeps its earlier triage.
Report
Each assessment produces a report with a summary, findings, finding details, and scope. Download it as Markdown, Word, or PDF (print).
Exports
Connect Linear, Jira, or Slack under Settings > Integrations, then send findings from a finding, the Findings list, or the assessment page. You can export one finding, up to 25 at once, or the assessment report.
Retest
After a fix ships, use Request re-test on the finding. The re-test shows whether the finding comes back. If the re-test run doesn't reach it, the finding is listed as not re-tested rather than gone.