The five playbooks that ship — Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest, Active Directory Pentest — attack the systems that serve, store and train a model, not the answers the model gives. What Cracken knows about model behaviour is published as research rather than sold as a run.
AI infrastructure penetration testing is an authorised attack on everything that carries a model: inference endpoints, the cloud accounts holding weights and training data, the pipelines that write them, and the identity layer behind all three. It targets systems, not model behaviour. Jailbreak and prompt-injection resistance is a separate discipline, tested against the model itself.
Domain Recon reads certificate transparency and passive DNS for your authorised domains, resolves what it finds, and enriches each public IP with open ports, services and known CVEs — without sending anything to your hosts.
Web App Pentest dispatches one sub-operation per attack class per surface — auth bypass, IDOR, SSRF, API logic — against the inference and console endpoints you authorise.
Cloud Pentest maps IAM permissions, roles and trust relationships from whatever credential the run obtains, then walks the cross-account paths that reach training and production from dev.
Each candidate goes to a separate operation that did not propose it, in fresh context, and every action lands in a timestamped ledger you can line up against your own cloud audit logs.
One credential is the hinge. Each stage names what an intruder does, and what a run does about it.
Reads certificate transparency and passive DNS for anything that answers on your domains.
Domain Recon reads the same records, resolves every name, and enriches each public IP with open ports, services and known CVEs.
Sends one request to an inference or console endpoint that trusts it.
Web App Pentest runs auth bypass, IDOR, SSRF and API-logic classes against the endpoints in scope, one sub-operation each.
Reaches the instance metadata endpoint from the application tier and takes the serving role's token.
Takes the same route and records what that token can actually do in your live account.
Assumes the roles dev trusts, until one of them is trusted by production.
Cloud Pentest maps roles and trust relationships and walks the assumption paths it finds.
Reads the store holding model weights and the training set.
Proves the store is reachable, records the command that ran and the result it returned, and stops at the ceiling you set. Nothing is copied out.
Feeds the deployed model an input crafted to make it leak or act.
Roadmap. Prompt injection and jailbreak resistance are not among the five shipped playbooks — Cracken publishes its measurements here as research, not as a run.
An AI company's serving infrastructure: the domains in scope, the inference and console endpoints behind them, and the serving, dev, training and production accounts. The exclusions and the intrusiveness ceiling are fixed before the first request.
Written from the execution plan of the playbooks that run today — Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest, AD Pentest. A run covers the target you authorise, under the policy you set.
Domain Recon reads certificate transparency logs, passive DNS and host intelligence for the domains you authorised, resolves every name it turns up, and enriches each public IP with open ports, services and known CVEs. Nothing is sent to your hosts.
T1596.003 - Search Open Technical Databases: Digital CertificatesWhich inference, staging, notebook and registry hostnames you expose that never reached an asset register. Anything the realm allowlist does not cover halts the run.
Web App Pentest dispatches one sub-operation per attack class per surface against the authorised inference and console endpoints: auth bypass, IDOR, SSRF, API logic. Each candidate goes to a separate operation that reproduces it in fresh context.
T1190 - Exploit Public-Facing ApplicationWhether an unauthenticated or cross-tenant request reaches another tenant's inference session or job history. Nothing is recorded as a finding until it fires a second time under an operation that did not propose it.
Cloud Pentest starts from whatever credential the run obtains - an exposed key, or the instance metadata endpoint reached from the app tier - and maps IAM permissions, roles and trust relationships from it.
T1552.005 - Unsecured Credentials: Cloud Instance Metadata APIWhat the serving role can actually do in your account, as against what its policy documents suggest it can do.
The run attempts the escalation and cross-account assumption paths it found, including the ones that reach the training and production accounts from dev.
T1078.004 - Valid Accounts: Cloud AccountsWhether the account holding model weights and training data can be assumed from the account serving traffic, and what the assumed role reads once it is there.
Every action is recorded with the command that ran, the result it returned, and the artifact it produced, timestamped.
T1530 - Data from Cloud StorageWhich of these steps your CloudTrail, Activity Logs and Cloud Audit Logs registered, and which fired nothing.
What this did not prove: Prompt injection, jailbreak resistance, system-prompt extraction and training-data poisoning are not in any shipped playbook. What Cracken publishes on model behaviour today is research — RedLineBench and two arXiv papers — not a playbook you can point at your endpoint.
MITRE ATT&CK v19.0, April 2026Mainstream models decline offensive-security tasks by design. Cracken removed that refusal in one domain, published the measurements, and licensed the benchmark so you can re-run it.
Cracken's abliteration paper reports cyber refusal falling from 100% to 7% on a 1T-parameter model, with explicit-content refusal held at 100% and a 13x selectivity ratio (arXiv:2607.02714, under review at NeurIPS 2026).
RedLineBench publishes the grounded offensive-security prompts, the verification checklist behind each one, and the reference run: 9 models x 153 prompts, judged independently by two LLM judges. Clone it and point it at your own model.
Named domains, accounts, subscriptions and projects, the exclusions, and an intrusiveness ceiling that holds anything above it for a human. The first target the allowlist does not cover halts the run.
No. Cracken's five shipped playbooks - Domain Recon, Web App Pentest, Network Pentest, Cloud Pentest, Active Directory Pentest - attack systems, not model behaviour. Cracken's model-behaviour work is published as research rather than sold as a run: RedLineBench is an MIT-licensed benchmark of 153 grounded, single-turn offensive-security prompts, each carrying a verification checklist, with published results across nine models scored by two independent LLM judges. — RedLineBench README (v0.1, Cracken (open source, MIT), 2026-07-27)
Article 15(5) of Regulation (EU) 2024/1689 requires technical solutions against "attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws". Two of those five live in infrastructure: a confidentiality attack ends at the account that stores the weights, and poisoning starts at the pipeline that writes the training set. Cracken validates whether those paths are reachable. It is not a conformity assessment and it does not evaluate the model. — EU AI Act, Article 15(5) (Article 15(5), Regulation (EU) 2024/1689, readable mirror at artificialintelligenceact.eu, 2024-08-01 (entry into force))
Yes, and Cracken measured it. "Red-Teaming the Agentic Red-Team" reports that, aggregated across ten agentic red-teams, code execution is achieved in 97.8% of runs. The accompanying security analysis spans twelve agentic tools, and in ten of those twelve the escape from the sandbox led to host compromise. An agent that runs tools on your infrastructure is infrastructure, and it is in scope for the same playbooks as the rest of it. — Red-Teaming the Agentic Red-Team, arXiv:2606.24496 (Pasquini, Bazyli, Fedynyshyn, Sorokin (Cracken), arXiv preprint, 2026-06-23)
Scope, fixed before the first request: the named domains, accounts, subscriptions and projects, the exclusions, and an intrusiveness ceiling that holds anything above it for a human. Recon sends nothing to your hosts, and the first unauthorised target halts the run rather than the step. The same discipline is visible in Cracken's published benchmark, where "every target domain and public IP in the dataset is a sinkhole we own and control". — RedLineBench README, responsible-use design (v0.1, Cracken (open source, MIT), 2026-07-27)
Because it declines the work, and it declines it unevenly rather than absolutely - which is why Cracken published the measurements across nine models on 153 grounded prompts instead of asserting the gap. The offensive side carries no such constraint: ENISA's Threat Landscape 2025 records "the emergence of stand-alone malicious AI systems since the beginning of 2025" and reports that over 80% of phishing emails identified between September 2024 and February 2025 used AI to some extent. — ENISA Threat Landscape 2025, section 4.5 (v1.2 (revised 2026-01-09), ENISA (European Union Agency for Cybersecurity), 2025-10)
No. A run works from the credentials, domains and endpoints you authorise. Where an escalation path reaches a store that holds weights or training data, Cracken records the path, the command that ran and the result it returned - enough to prove the path is walkable - and stops at the ceiling you set. Every action is timestamped, so the run can be lined up against your own cloud audit logs afterwards.
Tentacles, the Cybergraph, the approval gate every action passes through, and the operation ledger that records what ran. AI companies is one playbook on top of that engine.
One playbook answers one question. The case for validating exposure at all — why a scanner score is not a finding, and what changes when something proves the path instead of ranking it — is the argument this page assumes.
This playbook hands your engineers exploits they can re-run, not a list of things that might be exploitable.
You learn which cloud identities actually reach production data, and the exact role chain each one walks to get there.
This playbook cuts the application security backlog down to the findings an attacker can actually reach.
This playbook tells you which stages of that actor's chain your controls stop, and which they do not.
Why a click rate tells you who fell for it, and what a real lure would have taken.
The case for attacking your open findings instead of ranking them, and which playbooks do it today.
Give us a staging deployment and the scope you want worked.
Cookie Consent
We use cookies to enhance your browsing experience, analyze site traffic, and personalize content.
