Notifications
Clear all
Topic starter
18/08/2026 2:32 pm
TL;DR: AI changes pentesting by executing discovery, recon, testing, exploitation, and reporting at machine speed, while the real constraint becomes cost per asset and whether model-driven work is actually needed, according to CYCOGNITO. The practical implication is that automation should cover mechanical phases, while human reasoning stays reserved for creative exploitation and validation.
NHIMG editorial — based on content published by CYCOGNITO: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams use AI pentesting without creating more alert fatigue?
A: Treat AI pentesting as a validation and prioritisation layer, not a replacement for human triage.
Q: Why does pentest coverage matter more when environments change every day?
A: Because fixed-schedule testing always trails the real attack surface.
Q: What do teams get wrong about automated discovery?
A: They assume automation is enough if it can inventory assets faster than humans can.
Practitioner guidance
- Automate continuous asset discovery Refresh inventory for applications, APIs, exposed services, and identity-linked endpoints on a continuous basis so pentest scope tracks change, not annual planning cycles.
- Use deterministic scanners for repeatable checks Run recon and baseline vulnerability checks through scripted pipelines before involving a model, which keeps cost predictable and makes results easier to reproduce.
- Reserve AI for non-linear exploitation work Apply model-driven reasoning only when the test requires adapting to unusual responses, chained findings, or authentication bypass paths that scanners do not infer.
What's in the full article
CYCOGNITO's full article covers the operational detail this post intentionally leaves for the source:
- How the continuous AI pentesting workflow is structured phase by phase for practical execution
- The cost and token consumption trade-offs that determine when model-led orchestration becomes inefficient
- Examples of exploitation and reporting output that show how a real finding is validated and documented
- The webinar framing and live demonstration context behind the approach
👉 Read CYCOGNITO's analysis of continuous AI pentesting and workflow change →
AI pentesting and coverage gaps: what security teams should expect?
Explore further
18/08/2026 3:19 pm
AI pentesting is a coverage problem before it is a reasoning problem. The article shows that discovery, scoping, and baseline testing can be mechanised, but most teams still test too little of their live surface too infrequently. That is a governance failure as much as a tooling one because the weakest assets are often the least visible. For IAM and NHI teams, the lesson is to treat exposed identity-bound entry points as part of the test scope, not a separate audit concern.
A question worth separating out:
Q: What should teams do immediately when a signing key or token is exposed?
A: Contain the exposed credential path before validating anything else. Rotate or revoke the credential, identify every system and identity that can use it, and preserve evidence so you can confirm whether access was already achieved. In pentesting terms, the priority is to prove reachability without expanding impact.
👉 Read our full editorial: AI pentesting changes coverage, not the core attack workflow
