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 is designed to operate safely in production environments, what it can do, what it cannot do, and what controls exist to audit its behavior.

The goal 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 a run:

• Minimal impact: the agent looks for enough evidence to confirm a vulnerability, using by default the minimum evidence necessary. When the client explicitly authorizes it, Strike can perform a controlled exploitation to validate the real impact of the finding.

• Read-only by default: it never modifies, deletes, or persists data in production as its default behavior. When a validation requires additional actions, they are only performed with the client's explicit authorization and within the defined scope.

• Strict scope: it operates only on the assets you authorize. It does not move laterally to adjacent systems or access resources outside the defined scope.

• External attacker posture: except when you configure test credentials to test what is behind the login, 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 applies the techniques a professional pentester would use on your assets, within the limits of the authorized scope:

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

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

• Impact validation: by default, the agent demonstrates that access is possible without extracting data. When the client explicitly authorizes it, Strike can perform a controlled exploitation to validate the real impact.

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

About privilege escalation

Yes, the agent may attempt to escalate privileges when necessary to validate the real impact of a vulnerability, always within the authorized scope and with the least possible impact.

Certain families of vulnerabilities (such as 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 is why the agent may attempt to escalate privileges when it is the only way to quantify the real impact of the finding.

What the agent never does with the privileges it obtains:

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

• Access resources that are not explicitly authorized.

• Persist access, install backdoors, or keep sessions active beyond the run.

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

What the AI agent never does

These behaviors are explicitly prohibited in the rules that govern the agent and are part of the system design.

It does not access other clients' accounts in production

On multi-tenant platforms, any data or account belonging to other clients or tenants is explicitly out of scope for the agent. 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 run, or with test accounts your team provides. It does not use, and has no way to use, real accounts of other users of your platform.

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

• If during a run it detects a vulnerability that could allow access to third-party data (for example, an IDOR that exposes other users' records), the agent documents the existence of the problem with minimal evidence. It typically confirms that the endpoint is vulnerable and obtains one record or a count, but it does not download or extract real data from other clients.

It does not destroy or modify data in production

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

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

• It does not modify existing data (it does not edit other users' records, change system configurations, or alter the state of transactions).

• 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 records why the action was not completed.

It does not move outside the authorized scope

Each Threat Emulation has a scope defined by the assets it includes, the restrictions you set and, in a Change-based Threat Emulation, the linked repositories. The agent does not move to:

• Other assets that are not included in the Threat Emulation, even if they are reachable from an asset in scope.

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

It does not persist access

The agent does not install backdoors, create new users with elevated privileges, leave webshells, or keep sessions active beyond the run time. Each run is a self-contained event that starts 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 access was possible, not the real 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. This includes the hard limits mentioned above (not touching other clients' accounts, not destroying data, not leaving the scope, among others).

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

• Configured technical scope: the assets you include in the Threat Emulation, their credentials and technical documentation, and the restrictions you define limit 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, and 100% of critical findings are also manually reproduced and validated. Triage includes validating that the agent operated within the agreed scope and that the evidence collected is proportional to the finding.

Full traceability

Each run is recorded with:

• Traces of each step: the Trace tab within each run shows the complete log of the agent's actions: which endpoints it touched, which payloads it sent, which responses it received, and which decisions it made.

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

• PRs covered: in a Change-based Threat Emulation, the PRs tested tab of each run details exactly which code changes were included.

This means that if your security or compliance team asks "what exactly did the agent do on the asset?", the answer is in the run's trace. You do not need to rely on what the agent says it did.

How to present this to your security team

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

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

• Read-only by default: it never modifies production data. The only write actions it performs are those needed to maintain its own session (for example, registering a test account), when it is explicitly asked to validate a specific flow in a Focused Threat Emulation, or when the client explicitly authorizes a controlled exploitation as part of the validation.

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

• Limited and controllable scope: you define which assets, which restrictions, and which credentials. The agent does not move outside of that.

• Human triage by the Strike team: no finding is published without human validation, and critical findings are also manually reproduced.

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

Frequently asked questions

Can Strike delete data from my database during a run?

No. The agent is prohibited from any destructive action on production data. If during a run 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 performs the deletion.

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

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

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

The agent may generate traffic to your assets during a run, which in some cases may involve service consumption. That traffic is limited by the Threat Emulation restrictions (rate limit, schedule restrictions, and excluded test types). If your asset depends on paid external services that are sensitive to volume, configure the corresponding restrictions in the Threat Emulation.

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

The agent is designed to minimize the impact on availability: it respects rate limits, avoids techniques that cause DoS, and prioritizes depth over volume. If you still detect an availability problem, you can stop the ongoing run with Cancel execution and contact your Customer Success Manager to review the incident. For more details, see How to pause a Threat Emulation or cancel a run.

Who decides which assets and which scope?

You do. Strike only tests the assets you include in your Threat Emulations. The scope of each Threat Emulation is defined by the configuration your team sets up in the platform.

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

Open the Threat Emulation, go to the run from the Executions tab, and review the Trace tab. You will see the complete log of the agent's actions: endpoints accessed, payloads sent, responses received, and decisions made. In addition, each finding includes the exact reproduction steps.