Internal penetration testing with autonomous AI agents

What is internal penetration testing?

Internal penetration testing assesses the attack surface reachable from an employee, service, partner, or assumed-breach position inside an organization. Unlike an external test, it examines internal applications, identity systems, management interfaces, network services, data stores, and trust relationships that are not directly exposed to the public internet.

The objective is to understand what a real internal principal can reach and what impact follows. A successful network connection is only an observation. A confirmed finding requires evidence that an authorized test identity can access, modify, or disrupt something outside its intended policy.

What should an internal penetration test cover?

Start with a network map and identity model. Inventory reachable subnets, services, applications, administrative interfaces, credentials, service accounts, and trust boundaries. Then identify paths that matter: can one identity reach a more privileged interface, can a compromised service call another system, or can a management plane be accessed without the expected control?

Not every reachable host deserves exploitation. Prioritize assets by business impact and the permissions available from the starting position. Define targets and exclusions before the run so the agent does not interpret network reachability as authorization.

Separate discovery evidence from access evidence. A scan can show that a service is reachable, but a confirmed path needs the identity, authentication step, permitted action, and resulting effect on the target. Keeping those stages distinct prevents exposure findings from being reported as successful exploitation.

Test from representative starting positions when the engagement includes both user and service identities. A workstation, CI runner, application server, and managed endpoint expose different routes and credentials. Each starting position should have its own allow list, expected trust level, and account constraints.

How do autonomous agents operate inside an internal network?

Run the agent and its tools from an isolated host inside the approved network. Give the planner an asset graph, a starting identity, a route policy, and an explicit list of allowed and excluded services. Workers can enumerate and test focused branches, while the control plane checks actions against policy.

The agent should treat network discovery as a hypothesis-building step. It records reachable assets, responds to authentication boundaries, and identifies useful trust paths. When a test could change access, credentials, or system state, the workflow pauses for a human decision.

The planner should maintain the shortest meaningful path to a security conclusion. Broad enumeration can be useful for coverage, but each additional hop increases the chance of touching an unowned service or generating operational noise. Keep the current hypothesis, supporting evidence, and exact next action visible so an operator can pause the run before it expands.

Establish a clean baseline before workers begin. Record the routes, name resolution, credentials, and expected services from the starting host. If the environment differs from the approved map, stop and reconcile it with the network owner instead of allowing the agent to improvise a route around the discrepancy.

1. 01
   Authorize

   Name the network owner, starting position, subnets, credentials, and exclusions.

2. 02
   Isolate

   Deploy workers in a controlled segment with explicit routing and egress policy.

3. 03
   Map

   Inventory reachable applications, services, identities, and management planes.

4. 04
   Test

   Validate the least invasive path that proves unauthorized access or impact.

5. 05
   Approve

   Pause before credential attacks, lateral movement, or data-changing actions.

6. 06
   Retest

   Repeat the original path from the same network position after remediation.

How do you control lateral movement and blast radius?

Use static network policy and task-level rules as the first boundary. An agent should reach only authorized assets, even if a response suggests a more attractive target. Credential use should be scoped to named accounts, and any action that expands access should require a human approval record.

Set stop conditions for unexpected production effects: service errors, authentication lockouts, new external connections, bulk data access, or attempts to reach excluded subnets. Preserve the evidence collected before a stop so the operator can understand how far the run progressed.

• Subnet and host allow lists enforced outside the model.
• Deny rules for destructive and persistence-related actions.
• Least-privilege test accounts and credential rotation.
• Approval for privilege escalation or lateral movement.
• Time limits, idle limits, and task budget controls.
• Real-time alerts for out-of-scope network activity.

When should an internal AI pentest be self-hosted?

Self-hosting is appropriate when the testing runner must reside inside a private network, target evidence cannot leave the organization, or the toolset and model provider must be controlled. ARTEX’s public source and Docker Compose deployment provide an inspectable path for that model.

The tradeoff is operational ownership. The team must secure PostgreSQL, manage model access, restrict console and worker networking, maintain the toolchain, configure evidence retention, and keep upgrades reversible. Hosting a test console internally does not remove the need for authorization or human review.

What should an internal penetration finding preserve?

Preserve the source network segment or identity, target asset, route, request or command, authentication context, observed response, and resulting access. For multi-hop paths, document which step created the precondition for the next step and where a human approval interrupted execution.

Internal findings need special care with credentials and sensitive data. Redact report surfaces while retaining controlled access to the original artifacts required for reproduction. Keep the retest tied to the same starting position and network policy so differences reflect the fix rather than a changed test environment.

A useful evidence record also distinguishes the action the agent requested from the action the policy allowed. If an approval blocked a credential attack or lateral movement, preserve the proposed command, policy decision, reviewer, and timestamp. Blocked behavior demonstrates control effectiveness and helps the team test whether the guardrails operate as expected.

Close the loop with the asset and identity owners. The remediation may require a network rule, a role change, a credential rotation, or an application fix, and the retest must confirm both the original path and the relevant neighboring path. Record residual access and accepted risk when the organization chooses not to remove a finding immediately.

What is the minimum safe internal AI pentest workflow?

The minimum workflow is an authorized network position, isolated execution, least-privilege identities, enforced subnet and action policy, approval for lateral movement, preserved evidence, human validation, and a direct retest after remediation.

Autonomous internal testing is useful when the operator can control the blast radius. Expand only after the team proves that network policy, approvals, evidence review, and task stop controls work under a safe scenario.