How Strike's AI agent operates on your assets: scope, limits, and controls

Strike's AI agent is the agent that runs threat emulations on your assets. This article explains how it's designed to operate safely in production environments, what it can do, what it can't do, and what controls exist to audit its behavior.

ℹ The goal of this article is to give you full visibility into how the agent interacts with your systems, so you can confidently present Strike internally to security, compliance, and leadership teams.

Operating principles

The AI agent operates under four principles that guide every decision it makes during an execution:

• Minimal impact: the agent gathers sufficient evidence to validate a vulnerability using, by default, the minimum evidence required. When explicitly authorized by the customer, Strike can perform controlled exploitation to validate the real-world impact of the finding.

• Read-only by default: by default, the agent never modifies, deletes, or persists data in production. When a validation requires additional actions, they are only performed with the customer’s explicit authorization and within the defined scope.

• Strict scope: operates only on the assets you authorize. It doesn't move laterally to adjacent systems or access resources outside the defined scope.

• External attacker posture: except in whitebox pentests, where test credentials are provided to it, the agent acts as an external attacker with no prior privileges. It only accesses what any external actor could see from outside your organization.

What the AI agent does

The agent runs the techniques a professional pentester would apply on your asset, within the limits of the authorized scope:

• Reconnaissance and enumeration: identifies exposed surfaces, endpoints, parameters, and asset behaviors.

• Vulnerability detection: tests common attack vectors (OWASP Top 10, business logic flaws, IDOR, broken access control, injections, authentication failures, among others).

• Impact validation: by default, the agent demonstrates that unauthorized access is possible without extracting data. When explicitly authorized by the customer, Strike can perform controlled exploitation to validate the real-world impact.

• Documentation with evidence: every finding is recorded with the steps followed, the payload used, and the minimum evidence that proves the vulnerability.

On privilege escalation

Yes, the agent can attempt privilege escalation when necessary to validate the real-world impact of a vulnerability, always within the authorized scope and with the least possible impact.

Certain families of vulnerabilities (like IDOR, broken access control, or privilege flaws) can only be confirmed by testing with multiple user contexts. Saying "this endpoint looks vulnerable" is not the same as demonstrating "this user can access data from role X". That's why the agent may attempt to escalate privileges when it's the only way to quantify the actual impact of the finding.

What the agent never does with the privileges it obtains:

• Use the obtained access to move laterally to systems outside the scope.

• Access resources that aren't explicitly authorized.

• Persist the access, install backdoors, or maintain active sessions beyond the execution.

The goal is always to demonstrate risk with the least possible impact—not to abuse the access obtained or exceed the authorized scope.

What the AI agent never does

These behaviors are explicitly forbidden in the rules governing the agent and are part of the system's design:

It does not access other customers' accounts in production

On multi-tenant platforms, the agent has explicitly out of scope any data or account belonging to other customers or tenants. This is guaranteed by several layers:

• The agent operates as an external attacker with no prior privileges. It works with accounts it registers itself during the execution, or with test accounts your team provides. It does not use — nor does it have any way to use — real accounts from other users on your platform.

• In its operating rules, accessing other customers' accounts or data is marked as a hard limit: the agent is not authorized to attempt it, even when technically possible.

• If, during a test, it detects a vulnerability that could allow access to third-party data (for example, an IDOR exposing records from other users), the agent documents the existence of the issue with minimal evidence — typically confirming the endpoint is vulnerable and obtaining a single record or a count, not downloading or extracting real data from other customers.

It does not destroy or modify data in production

The agent is forbidden from any destructive action on production data:

• It does not delete records, files, or configurations.

• It does not modify existing data (it doesn't edit other users' records, change system configurations, or alter transaction states).

• It does not send emails, notifications, or real actions on behalf of real users.

• It does not perform financial transactions or operations with economic effects.

When a theoretical vulnerability would require a destructive action to be confirmed, the agent documents the finding with the evidence it has up to the point before the destructive action, and notes why the action was not completed.

It does not move outside the authorized scope

Every threat emulation has a clearly delimited scope by the configured asset, the defined restrictions, and the linked repos (in the case of Change-Based Tests). The agent does not move to:

• Other unauthorized assets, even if they're accessible from the asset under test.

• Adjacent systems (databases, internal services, corporate networks) that are accessible from the asset.

• URLs or endpoints explicitly excluded in the asset's restrictions.

It does not persist access

The agent does not install backdoors, does not create new users with elevated privileges, does not leave webshells, does not maintain active sessions beyond the execution time. Every threat emulation is a self-contained event that begins and ends within a defined time window.

It does not expose PII in reports

When a vulnerability involves personal or sensitive data, the agent masks the PII before including the evidence in the report. What appears in the report is proof that the access was possible, not the actual data.

How the agent's behavior is controlled and audited

The AI agent is not a black box. Its behavior is controlled by multiple layers and recorded end-to-end:

Control layers

• Operating rules (system rules): the agent operates under an explicit set of rules that define what it can and cannot do. It includes the hard limits mentioned above (not touching other customers' accounts, not destroying data, not moving outside the scope, etc.).

• Ethics layer: an additional layer applying cross-cutting principles — read-only by default, impact minimization, PII protection.

• Technical scope configured per asset: the restrictions, credentials, and files you configure at the asset level narrow the space in which the agent can operate.

• Human triage: every finding from the AI agent goes through triage by the Strike team before being published. This includes validating that the agent operated within the agreed scope and that the evidence collected is proportional to the finding.

Full traceability

Every execution is recorded with:

• Traces of every step: the Trace tab inside each threat emulation shows the complete log of the agent's actions: which endpoints it touched, what payloads it sent, what responses it received, what decisions it made.

• Evidence per finding: every reported vulnerability includes the exact steps to reproduce it, with request/response and the payload used.

• PRs covered (Change-Based): in change-based executions, the PRs tested tab details exactly which code changes were included in the scope.

This means that, if your security or compliance team asks "what exactly did the agent do on the asset?", the answer is in the execution's trace — it doesn't require trusting what the agent says it did.

How to present this to your security team

If your internal team asks for guarantees about how Strike operates on your production systems, the key points to communicate are:

• External attacker posture: the agent acts with the minimum privileges necessary, with no special access.

• Read-only by default: the only write actions the agent performs are those required to maintain its own session (for example, registering a test account), when explicitly requested to validate a specific workflow as part of a Focused Test, or when the customer explicitly authorizes controlled exploitation as part of the validation.

• Other customers' accounts out of scope: explicit in the agent's rules and reinforced by the external attacker posture.

• Bounded and controllable scope: you define which assets, which restrictions, and which credentials. The agent doesn't move outside that.

• Human triage by the Strike team: no finding is published without human validation.

• Full traceability: every action is recorded and auditable from the platform.

Frequently asked questions

Can Strike delete data from my database during a test?

No. The agent is forbidden from any destructive action on production data. If during a test a vulnerability is detected that could allow data deletion (for example, an endpoint vulnerable to SQL injection with DELETE), the agent documents the finding with the evidence prior to the destructive action — it never executes the deletion.

If the agent finds an IDOR that allows seeing other customers' data, what does it do?

It documents the existence of the IDOR with the minimum evidence necessary to confirm the finding: typically a single record or a count proving the access is possible. It does not download or extract real data from other customers. Any PII that might appear in that minimum evidence is masked in the report.

Can the agent generate costs in my account (for example, calls to paid APIs)?

The agent can generate traffic to your asset during the test, which in some cases can imply consumption of services. This is bounded by the asset's restrictions (rate limits, excluded endpoints, allowed time windows). If your asset depends on volume-sensitive paid external services, configure the corresponding restrictions in the asset configuration.

What happens if the agent affects my asset's availability during a test?

The agent is designed to minimize availability impact: it respects rate limits, avoids techniques that generate DoS, and prioritizes depth over volume. If you still detect an availability issue during a test, you can pause the execution from the platform and contact your Customer Success Manager to review the incident.

Who decides which assets and which scope?

You do. Strike doesn't discover or test assets you haven't explicitly configured. The scope of each threat emulation is defined by the configuration your team loads into the platform.

How can I audit what the agent did in a specific execution?

Open the threat emulation and review the Trace tab. You'll see the complete log of the agent's actions: endpoints accessed, payloads sent, responses received, and decisions made. For specific findings, each one includes the exact reproduction steps.