Before a release
See what was tested on the surface that changed, and what stayed open.
CTEM/Application security testing
Trusteed Application Security Testing
On an authorized application, black-box, authenticated testing, application scenarios, and specialist checks run on their own. An analyst does not choose the next test. A finding is written from verified evidence.
Trusteed Application Security Testing is Trusteed’s autonomous application test. Black-box testing, authenticated testing, application scenarios, and specialist checks run in the same engagement. The product discovers the surface, chooses the next card, runs the check, and records the observation. A finding enters the report only with verified evidence. An untested heading is not marked clean.
Same class of autonomous pentest as Mythos and OpenAI Astra: the product chooses the next check on an authorized target. You still provide the scope and, for authenticated coverage, the test account.
Trusteed · Updated
What is Trusteed application security testing?
Trusteed Application Security Testing examines the web application and APIs you authorize, on its own. Black-box testing does not wait for source code. If you provide a test account, authenticated testing continues in the same loop. Injection, access, API, identity protocols, and specialist checks are not started one by one by hand. The product chooses the next card. The output is verified findings, plus a separate list of items that were not tested or were blocked.
Who is it for?
It is for product, security, and compliance teams that want an authorized test on a live or staging environment without waiting for an analyst to pick the order. Where no source is provided, black-box testing starts on its own. When an account, a role, or a business rule is provided, authenticated scenarios continue on their own. API, session, and multi-step flows are chosen in the same engagement.
A customer or audit question
Ask for a report that separates “scanned” from “verified.”
A repeat test
A new observation on the same target is written on top of the old record, not over it.
Which test types does it cover?
Trusteed does not make you turn each test type on by hand. Black-box testing, authenticated testing, application scenarios, and specialist checks run autonomously. They share one loop: the surface is read, a card is chosen, a check runs, and the observation is recorded. No evidence means no finding. If the check did not run, the result is not clean.
Black box
Black-box testing is an autonomous examination of an authorized scope without the application’s source code. Discovery produces the surface. Each round, the product picks a hypothesis, runs a limited check, and writes the observation to disk. A verified card becomes a finding. A refuted card is not deleted; it stays attached to the next card. Open, blocked, and deferred cards stay separate in the report.
In this mode, automated network checks are limited to reads. A write, a notification, an SMS, account recovery, or a suspicion of a third party’s data is a reason to stop. An address outside the scope is not guessed.
Authenticated testing (gray box)
Authenticated testing is the autonomous examination of the same surface with a test account, session, or role you provide. The product does not open the account. You provide it, and the product chooses the next cards. The session goes only to the address you named. Without customer data and a role definition, access and business-rule cards are deferred without a grade. This is not a separate manual track. It is the authenticated form of the same autonomous run as black-box testing.
Application scenarios
Application scenarios run autonomously. The product routes a weak signal to the relevant scenario, decides whether it fits, and runs the check on the chosen card itself. An analyst does not start scenarios one by one from a list.
| Group | What it asks | Example headings |
|---|---|---|
| Injection | Does input mix into a command, query, or template on the server? | SQL, NoSQL, command, XXE, SSTI, prototype pollution |
| Access and identity | Can a caller reach someone else’s record, role, or session? | Authentication, access control, OAuth, JWT, CSRF |
| Client and browser | Does the page write user input somewhere unsafe? | XSS, DOM, clickjacking, CORS, open redirect |
| Business flow | Does a rule break under order, replay, or a limit? | Business logic, race, file upload, cache |
| API and protocol | Does the contract or channel differ from an HTML form? | API, GraphQL, WebSocket, request smuggling, host header |
| Information and components | Do errors, versions, or configuration say more than they should? | Information disclosure, SSRF, insecure deserialization, LLM prompt |
Injection
Does input mix into a command, query, or template on the server?
A parameter named id does not prove SQL injection. Seeing JSON does not prove NoSQL. The card needs request context and a verifying observation.
Access and identity
Can a caller reach someone else’s record, role, or session?
Without your definition of customer data and roles, access and business-rule cards are deferred, not graded.
Client and browser
Does the page write user input somewhere unsafe?
A client-side check is not called a vulnerability, or called clean, until the server applies the same control.
Business flow
Does a rule break under order, replay, or a limit?
If the rule was not provided, the card is deferred. The product does not invent the rule.
API and protocol
Does the contract or channel differ from an HTML form?
A route that answers is not a finding. The card closes on a verified observation about that channel.
Information and components
Do errors, versions, or configuration say more than they should?
A version string alone does not open a CVE finding. Range, function, reachability, and the fix are shown together.
Specialist checks
Specialist checks run autonomously too. A single-purpose card that does not fit a general scenario is chosen by the product, checked, and written down.
| Check | Question |
|---|---|
| CVE | Is the seen version shown with the function reached in this app, and with the fix? |
| Service | Is an in-scope service sitting outside the expected surface? |
| Takeover | Is an abandoned name or cloud record open for someone else to claim? |
| Origin | Does the source origin match the browser policy? |
| Open redirect | Does the redirect land on an address the caller chose? |
| Configuration | Do headers, errors, or defaults give away information they do not need to? |
A version string alone is not a finding. A CVE card does not close until the version range, the code path, reachability, and the fix are shown together.
How does it work?
The engagement has six steps, and an analyst does not choose between them. Every test type walks this loop on its own. Each step reads the previous step’s record. A chat transcript is not what gets handed forward.
- 01
Authority
Scope, window, and allowed actions are written down. With no record, the test does not start.
- 02
Discovery
The permitted surface is collected. An observation becomes inventory. Discovery does not declare a vulnerability.
- 03
Sorting
The surface becomes a candidate for a scenario. A weak signal is not a decision to drop the card.
- 04
Check
The chosen card gets a limited check. The value and the effort are written down.
- 05
Record
The observation is written to disk first. Verification has to quote that observation. HTTP 200 or 400 alone does not open a finding.
- 06
Report
Verified cards enter the findings. Open, blocked, and deferred cards are listed separately.
What do you see in the report?
The report puts three things side by side: a verified finding, a card that is still open, and a heading that was not tested or was blocked. “Clean” is used only when the check for that heading ran and the opposite was not seen. A category that was not tested is not written as clean.
Finding severity and the score for “why we chose this card” are separate. A heading that cannot be seen from the outside, such as some log and monitoring checks, stays marked as not observable from the outside. A default score vector is not added to the report.
How is this different from a scanner and a classic pentest?
A signature scanner matches templates. A sampled pentest follows the flows an expert chooses. Trusteed runs black-box, authenticated, scenario, and specialist checks on an authorized scope, and writes a finding only from verified evidence.
| Question | Signature scanner | Sampled pentest | Trusteed |
|---|---|---|---|
| Start | A URL list | The flow an expert picks | Authorized scope and a discovery inventory |
| Black box | Request templates | An expert walking the app | Autonomous hypothesis, a limited check, a durable record |
| Authenticated test | A fixed account and a narrow flow | Interviews and a manual walkthrough | Autonomous; the session is yours, the next card is the product’s |
| Scenario and specialist checks | A signature match | The heading an expert picks | Chosen, run, and recorded autonomously |
| Business rules | Weak | Strong, and tied to a person | No rule means the card is deferred, not invented |
| Finding bar | A matching signature | An expert note | A row with no verification quote is not a finding |
| Negative result | Often “no issue” | Depends on the report format | An untested item is not counted as clean |
| Record | Scan output | A closing report | A record updated each round; an old observation is not deleted |
What does it not do?
Trusteed does not send requests to an unauthorized target. It does not widen the scope on its own. It stops when a third party’s data is suspected. It does not automatically try endpoints that write or notify. It does not call a client-side control a vulnerability, or call it clean, when the server does not apply the same control. The test is not used to cause harm, extract data, or keep access.
FAQ
Frequently asked questions
Short answers on autonomous application testing, what counts as evidence, and what is not marked clean.
Talk to an expert →Do the tests run autonomously?
Yes. Black-box testing, authenticated testing, application scenarios, and specialist checks all run autonomously. The product chooses the next card, runs the check, and records the observation. Scope, and a test account when you want authenticated coverage, come from you. The finding bar does not move: an observation that is not verified does not enter the report as a finding.
Does a black-box test require source code?
No. Black-box testing examines the surface an authorized scope can see from the outside, without source code. Providing source, a package, or an account opens authenticated and scenario checks in the same autonomous run. None of those inputs is a condition for black-box testing to start.
Are gray-box and black-box the same product?
They are two entries into the same autonomous product. Black-box testing starts without source or an account. Gray-box, the authenticated test, runs the identity-aware surface with a test account or session you provide. The product does not create that account.
Is this autonomous test the same as an automated scan?
No. A scanner runs signatures and request templates. Trusteed chooses black-box, scenario, and specialist cards on its own, records the observation, and writes a finding only when that observation is verified. A heading a scanner calls clean stays untested here until a check actually runs.
Why is a SQL injection or XSS name not enough on its own?
The name shows that the scenario was considered. A finding is written with the request context and a quote from the verifying observation. A parameter name, an HTTP status code, or the label SQL injection or XSS does not stand in for that quote.
Does the test disrupt production?
Autonomous checks stay within read-only actions. A suspected write, an SMS, a notification, account recovery, or another side effect stops that card. Scope, the environment, and the rate limit are written down before the test starts, so the run does not invent permission to change data.
Why does an untested item stay in the report?
Absence and an item that was never looked at are different results. Open, blocked, and deferred cards are not presented as findings. They stay visible as a coverage gap, so a heading that was not tested is not reported as clean and is not dropped from the record.
Does a CVE row open from a version number?
No. A version string on its own is not a finding. A CVE card closes only when the version range, the affected function inside this application, whether that function can be reached, and the fix are shown together in the same record.
Does our data enter the model or the report unchanged?
A suspicion of personal data is a reason to stop. The report is written with the smallest evidence and masking. A truncated body, or a body whose owner is unclear, is not passed off as clean. That does not make the product an error-free classifier of personal data.
Run the next check without waiting on a queue
Authorized scope in, verified findings and untested headings out. Mythos and OpenAI Astra sit in the same class of autonomous pentest.