Interactive AI testing exposes command execution and cloud access paths

At a glance

What this is: Tenzai’s interactive testing workflow lets engineers guide AI hackers during live exploitation, and the example walkthrough shows command execution, data extraction, and cloud token abuse in a single chain.

Why it matters: It matters because security teams are increasingly using agentic systems to validate real attack paths, which means identity, privilege, and evidence handling need to stay under human control.

Context

Interactive offensive testing is moving from a purely autonomous exercise to a collaborative one, where a human engineer can steer exploit development, inspect evidence, and decide when to escalate an investigation. That changes the governance problem: the control point is no longer just whether a test can run, but whether the team can shape, reproduce, and safely bound what the agent discovers.

The identity angle is real here because the walkthrough crosses from application exploitation into service-account use and cloud access. That makes AI agent identity governance relevant, not as a vendor feature but as a lens for ownership, privilege scope, and handoff between human judgment and machine action.

Key questions

Q: What breaks when an autonomous security test needs human steering?

A: The test no longer behaves like a closed automation loop. Once engineers need to reproduce a finding, test a hypothesis, or bound the next action, the programme must define who can intervene, what evidence is sufficient, and when to stop. Without that structure, the test can become hard to reproduce, hard to govern, and difficult to defend to stakeholders.

Q: Why do exploited workloads often lead to cloud access?

A: Because many workloads carry runtime identities that can reach storage, export jobs, or internal services if the host is compromised. A short-lived token still creates risk when the role is broad or the metadata service is reachable. The control problem is scope, not just expiry, so teams need to minimise what the workload can do even after compromise.

Q: What are the signs that an application connector is trusting the wrong address?

A: Look for validation that checks one field while the runtime connection uses another, especially when a public value passes a guardrail but an internal value is actually consumed downstream. Dynamic hostname resolution can create the same effect if the address changes between validation and use. Those mismatches are often the opening for internal pivots.

Q: Should security teams prioritise reproducible exploit evidence over broader attack chaining?

A: Usually yes, if the goal is governance and remediation rather than pure curiosity. Reproducible evidence makes it easier to prove impact, assign ownership, and validate fixes. Broader chaining is useful when the team needs to understand scope, but it should not replace a clean proof of each stage in the path.

Technical breakdown

How interactive exploit steering changes autonomous testing

Interactive testing sits between full autonomy and manual pentesting. The agent still executes attack paths, but the engineer can redirect the next step, narrow the objective, or ask for evidence that proves a hypothesis. This matters because many exploit chains require contextual decisions that an autonomous system may not make on its own, such as whether to pursue a timing oracle, whether to preserve a target state, or whether to stop once proof is sufficient. The technical value comes from combining machine-scale exploration with human prioritisation and verification. See the Penetration Testing Guide.

Practical implication: Define when human steering is required so interactive tests do not drift into unsafe or unrepeatable exploitation.

Why request manipulation and DNS rebinding matter in validation

The walkthrough shows two common security testing mechanisms that behave differently under validation: parameter trust and DNS rebinding. Parameter trust failures happen when an application validates one value but uses another later in the stack. DNS rebinding abuses name resolution over time, letting a hostname resolve to a public address during validation and an internal address during use. Together, they demonstrate how an apparently safe connector or report function can become an internal pivot point when the application does not bind identity, destination, and trust decisions tightly enough.

Practical implication: Test for validation-use mismatches in any workflow that accepts multiple address fields or resolves hostnames dynamically.

How a compromised host can expose cloud access through metadata tokens

Once the agent reached command execution, the next step was to inspect whether the host could retrieve a service-account token from metadata. That pattern is common in cloud environments where workloads inherit a runtime identity with access to downstream resources. A short-lived token is not safe simply because it expires quickly. If the workload is compromised, the token becomes an abuse path to whatever the role permits, including storage buckets, export jobs, or internal services. The key architectural issue is workload-to-resource trust, not token duration alone. See the AI Agent Authorisation Guide.

Practical implication: Treat workload metadata access as a privilege boundary and scope service-account permissions to the minimum needed by the job.

Threat narrative

Attacker objective: The objective was to prove end-to-end compromise from application input to internal data extraction and cloud access from the same exploited host.

1. Entry began with SQL injection in a test notification workflow inside the HR application, which let the agent probe the database through response timing.
2. Escalation followed through connector confusion and DNS rebinding, allowing the reporting feature to reach an internal database and obtain superuser-level access via default credentials.
3. Impact extended when the compromised host exposed a service-account token that was then used to read a payroll export object from cloud storage.

NHI Mgmt Group analysis

Interactive testing is really a governance model for exploit validation, not just a product feature. The important change is that a human can now shape an AI-led attack path while preserving the scale advantage of machine discovery. That makes reproducibility, evidence quality, and escalation thresholds part of the control design rather than after-the-fact review. Practitioners should treat interactive offensive testing as a governed workflow with explicit stop conditions and evidence standards.

The named concept here is exploit steering with bounded autonomy. The engineer is not replacing the agent and the agent is not replacing the engineer. Instead, the testing process uses agent speed for discovery and human judgment for prioritisation, business context, and risk acceptance. That combination is powerful, but it also means teams need clearer rules for who can redirect a live test, what evidence is sufficient, and when a finding should be reproduced rather than extended. The practical conclusion is that autonomy needs operational guardrails.

This walkthrough also shows how application compromise can become identity compromise in cloud workflows. The final pivot was not just code execution but exposure of a runtime service account through the host’s metadata service. That is exactly where identity governance meets offensive testing: workload identity, storage permissions, and export jobs become part of the same attack surface. AI agent identity governance is relevant here because the test team is effectively managing machine action, privilege, and accountability in one chain.

AI-assisted offensive testing will force security programmes to distinguish discovery from delegation. An agent can discover attack paths at scale, but delegating the next step may require human review, especially when the path crosses from application evidence into data handling or cloud resources. That distinction will matter more as teams use AI systems to validate real production-like targets. Practitioners should align testing authority with the sensitivity of the next action, not just the novelty of the finding.

Offensive AI tools now expose the same trust gaps defenders already struggle with in production workloads. The connector, metadata, and cloud-access steps all depended on assumptions about what should happen next in a workflow. When those assumptions fail, the result is not just a test finding, but a map of where runtime trust is too broad. The implication is that identity scope, destination validation, and metadata access deserve the same scrutiny in test systems as they do in live environments.

Read next: AI Agent Authorisation Guide

What this signals

Bounded autonomy will become the decisive operating model for AI-led security work. Security teams will increasingly use agents to search for weaknesses, but they will also need a clear point at which human judgment reasserts control. The programme implication is that testing authority, evidence handling, and escalation rights must be designed together, not added after the agent is already running.

Exploit steering is now a governance capability. The teams that get value from AI hackers will be the ones that can direct the next test action without losing reproducibility or accountability. That means policy, logging, and approval boundaries need to track the agent’s active role in the workflow, especially when the next step crosses into data validation or cloud access.

Workload identity is part of the attack path, not just the deployment stack. When an exploited host can recover a service-account token and reach storage or export resources, the identity layer has become part of the compromise chain. Teams should expect AI-assisted testing to expose these gaps faster and use those findings to tighten runtime permissions before they are relied on in production.

For practitioners

• Define human steering thresholds for live AI-led tests Specify when an engineer must take over from autonomous exploration, especially before data extraction, cloud token use, or any action that affects external systems.
• Validate multi-step exploit chains with explicit evidence checkpoints Require the agent to prove each stage separately, such as command execution, data access, and external retrieval, so the team can reproduce the chain without guessing.
• Review workload identity exposure on exploited hosts Check whether metadata services expose service-account tokens that can reach storage buckets, export jobs, or adjacent cloud resources from a compromised workload.
• Test for validation-use mismatches in application connectors Look for cases where one field is validated but a different field is used by the downstream driver or service, then confirm whether internal addresses can slip through.

Key takeaways

• The article shows that AI-led offensive testing can move from application flaws to data extraction and cloud access in one chain, which makes governance as important as technical capability.
• The strongest control point is not the agent’s speed but the human boundary around when to steer, reproduce, or halt a live test before it crosses into sensitive actions.
• Workload metadata, service-account scope, and connector validation all sit inside the same attack surface when a compromised host can become a cloud pivot.

Related NHI Mgmt Group resources: Identity Governance for AI Agents Guide · AI Agent Authorisation Guide · AI Agents vs Agentic AI · AI Security Maturity Model

Key terms

• Interactive Testing: A security testing mode where a human engineer steers an AI-led exploit investigation in real time. The agent still executes actions, but the human decides what to try next, when to reproduce evidence, and when to stop or narrow the scope.
• Exploit Steering: The practice of directing an in-progress attack or test path by changing requests, setting objectives, or choosing the next verification step. It combines autonomous discovery with human judgment so the investigation remains reproducible, bounded, and aligned to the organisation’s risk tolerance.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect identity controls to the wider security programmes they run.