What to include in an asset's context

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

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 don't need to explain it.

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

A well-built context produces testing objectives focused on what is unique to your system. A noisy context makes the agent lose focus on what really matters.

What you don't need to include

Don't repeat standard pentest knowledge. If you can find it in any OWASP guide or 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 finding structure

• Generic pentest methodology

Including all of this adds information the agent doesn't need. A curated detail about what matters produces a higher-quality context—and higher-quality objectives.

What does need to be there

The rule is simple: if it isn't in the context, the agent can't infer it.

Include the information specific to your organization:

• Roles and permissions: each user role with its concrete actions: what it can view, create, modify, and execute. No generic names: what this Admin does in this application.

• Business modules: your system's own modules with their specific logic: approval flows, financial limits, authorization chains, operations that involve real money.

• Applicable regulations: only the ones that actually apply to your case. Don't list every regulation that exists; indicate which ones are mandatory and why (industry, country, data type).

• Test accounts: one real user per role to be evaluated. If the credentials are provided separately, note in the context that they are available and under what name.

• Operational restrictions: whether the scope is production, whether real transactions are at stake, the permitted hours, or whether there's a WAF bypass for the test IPs.

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

Annotated example

The same context, with each part classified by whether it adds value or not.

Special case: production with real operations

⚠ If the scope includes production with real transactions (PIX, payments, transfers), you must state this explicitly in the context and confirm whether a sandbox environment exists. Without this note, the agent may execute operations with real financial impact during the test.

Include when real money is at stake:

• Environment: production, staging, or sandbox. If it's 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's as important as the scope: without defined limits, the agent has no anchor to stop at.

Quick checklist

Before sending the context, check that it includes the following:

• One test user per role

• The concrete actions and permissions of each role

• The business modules with their specific logic

• The out-of-scope defined explicitly

• The regulations that apply and why

• If there's production: the note about real operations

• The time or WAF restrictions, if applicable