AI AGENT & CYBERSECURITYScope a test
01 / Model layer
02 / Stack layer
03 / Company
Scope a testNederlands

02 / Stack layerCLOUD & INFRA

Cloud penetration testing for AWS, Azure and GCP.

A cloud penetration test is an authorized attack on your cloud account from the positions an attacker could actually hold: an exposed service, a leaked key, a compromised workload or a low-privilege user. We test identity and privilege paths, exposed storage, secrets, build pipelines and workloads on AWS, Azure and Google Cloud, and report how far one weak spot reaches.

Scope a testSee a sample report

For teams whose customers ask how the platform is run, not only how the app behaves.

Package
CLOUD & INFRA
Range, excl. VAT
Quoted per scope
Testing days
Set in the scoping call

ROLE CHAIN / FICTION / ONE CLOUD ACCOUNT04 ROWS READ / 1 FOUNDSAMPLE

FROM A WORKLOAD TO THE CLAIMS STORE

  1. WORKLOAD ROLEThe claims API’s own identity
  2. CAN ASSUMEDeploy role, through a trust policy wider than needed
  3. DEPLOY ROLERead access to every bucket in the account
  4. CLAIMS STOREClaim documents of every customer

HOP 02 / TRUST WIDER THAN THE TASK / LEAST PRIVILEGE

One trust policy lets the workload become a role it never needs, and that role reaches every bucket. We test identities and the paths between them, then report how far one weak spot reaches.

How does a cloud penetration test run?

Inside the providers’ rules, from the positions an attacker could actually hold.

  1. 01Provider rules

    We confirm what each provider allows.

    AWS allows penetration tests of a listed set of services without prior approval and prohibits denial of service and flooding. Microsoft has not required pre-approval for Azure since June 2017, but its rules of engagement apply. Google does not ask to be contacted before you test your own projects. The rules of engagement we sign with you follow all three.123

  2. 02Read the account

    We start with a read-only review.

    A read-only audit role gives us identities, policies, storage, network and logging configuration. Our tooling builds the graph of who can do what; a person reads it for the paths that matter to your data and your customers.

  3. 03Assumed breach

    We test from the positions an attacker could hold.

    An exposed service, a key leaked from a repository, a compromised container, a developer’s low-privilege user. From each starting point you agree to, we test how far the access reaches, with test identities you create for the purpose.

  4. 04Follow the path

    We follow privilege, not hosts.

    In a cloud account the path is made of permissions: one role that may assume another, one function that may read a secret. Every step we take is logged with its time and identity, so your team can match it to their own logs afterwards and see what they would have caught.

  5. 05Report the reach

    We report how far one weak spot reaches.

    Findings carry the ATT&CK technique, the exact permissions involved and the smallest policy change that closes the path, so the fix is usually a pull request, not a rewrite.

What do we test in a cloud account?

Twelve categories, each tied to the MITRE ATT&CK techniques an attacker would use against it. A configuration review lists what is wrong; a penetration test shows what an attacker could do with it.4

Every row is a category in our test catalogue. Ids link to the framework that defines them.
No.CategoryWhat we checkMapped to
01Least privilege for users, roles and service accountsUsers, roles and service accounts with more permissions than their job needs, and long-lived keys nobody owns.
02Privilege escalation paths and cross-account trustPaths from a low-privilege identity to an administrator, and trust between accounts, subscriptions and projects.
03Sign-in hardening: federation, MFA and conditional accessFederation, multi-factor and conditional access, and the exceptions that were added once and never removed.
04Object storage exposure and access policiesBuckets, blobs and shares: what is public, what can be listed, and which policies allow more than intended.
05Secrets in code, images and secret storesSecrets in code, container images, environment variables and secret stores, and who can read them.
06CI/CD pipeline integrity and build permissionsWho can change what your pipeline builds and deploys, and which credentials the pipeline runs with.
07Instance metadata and workload identity protectionWhether workloads can reach instance metadata and borrow the identity attached to them.
08Container and Kubernetes configurationContainers and Kubernetes: privileged workloads, service account tokens, cluster roles and the paths out of a container.
09Serverless functions and event triggersServerless functions and their triggers: what can invoke them, and what their roles can reach.
10Hosted AI services: model endpoints, keys and quotasHosted AI services: model endpoints, API keys and quotas, and who can spend them.
11Logging and audit trail coverageWhether the logs an investigation would need exist, are complete, and cannot be switched off quietly.
12External infrastructure: exposed hosts, services and remote accessHosts, services and remote access exposed to the internet, tested from the outside in.

Out of scope Denial-of-service and load testing, the provider’s own infrastructure, and other customers’ tenants: out of scope by our own rules, whatever a provider permits.

What does a cloud finding look like?

One card per finding, with the same fields every time. This one is low, from the fictional engagement in our sample report, and it matters most on the day something else goes wrong.

SAMPLE / FICTIONAL CLIENT / REAL FORMAT

SAMPLE-01 / F-07

LOWCVSS-B 2.1STACK LAYERLogging and audit

The assistant’s tool calls are missing from the audit trail

Business impact
After an incident, nobody could tell which conversation changed which claim.
Evidence
LOG REVIEW, APPENDIX C Found by review, not by an attempt, so there is no rate to report.
CVSS v4.0 vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Fix principle
Log every tool call with its session, customer and arguments, somewhere the service account cannot change.
Retest
PARTLY FIXED 2026-09-24 Tool calls are now logged with the session; the log store is still writable by the service account.
The format every finding takes in our report. The client and the finding are fiction; the fields are not. Read F-07 in the sample report.

What does a cloud penetration test cost?

Cloud tests are quoted per scope, excluding VAT, until we publish a range for them. The four drivers below decide the figure; the scoping call counts them, and the quote follows from that count.

02 / Stack Pentest

CLOUD & INFRA

Quoted per scope

SET IN THE SCOPING CALL

What moves the price

  • Accounts, subscriptions or projects in scope
  • The number of identities, and how they are federated
  • Kubernetes clusters, serverless functions and pipelines
  • The assumed-breach starting points to test from

See all prices

Report
Scope, method, dates, findings with evidence, severity in CVSS v4.0, framework ids, fix guidance and retest status.
Attestation letter
One page that confirms scope, dates and retest status, for customers who need the result without the findings.
Coverage matrix
Every category in scope marked tested, not applicable or out of scope, so the gaps are written down too.
Evidence
For every finding, the permission path from its starting point to its impact.

Questions about cloud testing.

Do we need permission from AWS, Azure or Google for a pentest?

Usually not, but each provider has rules. AWS allows tests of a listed set of services without prior approval, Microsoft has not required pre-approval for Azure since 2017 but publishes rules of engagement, and Google does not ask to be contacted. AWS and Microsoft both prohibit denial-of-service testing, and so do we.

What access do you need for a cloud pentest?

A read-only audit role in each account, subscription or project in scope, and test identities for the starting points we agree, such as a developer user or a workload role. We never need your production administrator credentials, and you remove our access yourself when the engagement ends.

Is a cloud pentest the same as a configuration review?

No. A configuration review or posture tool lists settings that break a benchmark. A penetration test starts from positions an attacker could hold and shows which of those settings combine into a path to your data or an administrator role. The review is a good input; the path is the finding.

Do you test Kubernetes and serverless?

Yes, as part of the account. We test cluster roles, service account tokens, privileged workloads and the paths from a container to the node or the cloud account, and for serverless what can invoke each function and what its role can reach. Managed control planes are tested only as far as the provider allows.

Why is cloud testing quoted per scope?

Because cloud estates differ more than applications do. Two companies with the same product can run one account or forty, a few roles or thousands of federated identities. The scoping call counts the accounts, identities and workloads that matter, and the quote follows from them instead of from a range.

The engagement, in short.

We set the testing days in the scoping call and test on staging where we can, under the rules of engagement you sign first. Then the report and a one-page letter, and the retest once you have fixed. Every step, from the scoping call to the regression pack, is in the method.