What to include in an asset's Description and in Additional information

Context gives Strike's AI agent the information specific to your company that it cannot infer on its own. Everything the agent already knows from its training is noise, and noise dilutes the results.

There are two places where you add context:

• Description, in the asset: describes what the asset is and how it works. It applies to all the Threat Emulations that include it.

• Additional information, in the Threat Emulation: details that apply only to that Threat Emulation.

Why what you include matters

The agent knows OWASP, PCI DSS, privilege escalation techniques, and how to test authentication. That knowledge is already built in: you do not need to explain it.

What the agent does not know is your company's architecture: what each user role can do, which business modules have critical logic, or which specific regulation applies to your industry.

Well-built context produces testing objectives focused on what is unique about your system. Context with noise makes the agent lose focus on what really matters.

What you do not need to include

Do not repeat standard pentest knowledge. If you can find it in any OWASP guide or in a security course, the agent already knows it.

Leave out what the agent already knows:

• OWASP Top 10 / OWASP API Top 10

• Authentication and session checklists

• Lists of SQLi, XSS, SSRF, etc.

• The description of what PCI DSS or ISO 27001 is

• The report format and the structure of findings

• Generic pentest methodology

Including all of this adds information the agent does not need. A curated detail about what matters produces higher-quality context, and also better testing objectives.

What must be there

The rule is simple: if it is not in the context, the agent cannot infer it.

In the asset's Description

• What the asset does: its purpose and main flows.

• Business modules: the modules specific to your system with their specific logic: approval flows, financial limits, authorization chains, operations involving real money.

• Sensitive data: what type of information the asset handles.

• Applicable regulations: only the ones that really apply to your case. Do not list all the ones that exist; indicate which are mandatory and why (industry, country, type of data).

• Multi-tenancy: if the platform serves multiple companies or customers, say so. Isolation between tenants is one of the most critical vectors and requires specific context.

• Environment and real operations: whether the asset is in production and executes real transactions, and which parts cannot be touched. See the special case below.

In the Threat Emulation's Additional information

• Critical flows that cross several assets in the Threat Emulation.

• The focus or clarifications that apply only to that Threat Emulation.

• Anything that is out of scope only in that Threat Emulation.

What has its own field

Some things do not go in the text, because they have a specific place in the platform:

Special case: production with real operations

If the asset is in production and executes real transactions (PIX, payments, transfers), state it explicitly in its Description and clarify whether a sandbox environment exists. Without this clarification, the agent may execute operations with real financial impact during testing.

Include the following when real money is at stake:

• Environment: production, staging, or sandbox. If it is production, confirm it explicitly.

• Real operations: whether the financial modules execute real or simulated transactions, and whether the payment provider has a test mode.

• Out of scope: what cannot be touched. It is as important as the scope: without defined limits, the agent has no anchor to stop at.

If something is out of scope only in a specific Threat Emulation, state it in its Additional information.

Quick checklist

Before confirming, verify that you have:

• In the Description: the specific actions and permissions of each role.

• In the Description: the business modules with their specific logic.

• In the Description: the regulations that apply and why.

• In the Description: if there is production, the clarification about real operations and what is out of scope.

• In the credentials: one test user for each role.

• In the Threat Emulation's restrictions: the schedules and excluded tests, if they apply.

• In Additional information: what applies only to that Threat Emulation.