AI Pentesting, Part 15: CloudSec, Privilege Analysis, and Reporting: Close the Evidence Loop

1. Build a read-only cloud review packet

Start from an approved account, subscription, or project inventory. Use dedicated read-only roles with short-lived credentials and explicit scope. Collect resource identifiers, regions, policy documents, public-access settings, network rules, encryption configuration, logging state, and ownership tags. Avoid exporting secrets or complete object contents to explain a configuration.

Tools such as existing CSPM integrations, cloud policy analysers, Prowler, ScoutSuite, and IaC scanners can provide deterministic observations. Their checks still require interpretation and version awareness. Let AI summarise a sanitised configuration snapshot and ask for missing context; do not give it a general cloud-admin tool.

Do not treat 'read only' as 'no sensitive data'. Configuration reveals topology and trust relationships. Keep credentials inside collectors, redact values, and apply the same retention and provider controls used for source code.

2. Distinguish a policy statement from effective access

A single allow statement is not the whole permission decision. AWS may involve identity and resource policies, explicit denies, boundaries, session policies, organisation controls, conditions, and service-specific behaviour. Azure and GCP have different evaluation semantics. Kubernetes RBAC may be constrained by admission and other runtime controls. Use the platform's authoritative evaluation tools and documentation instead of one universal model-generated rule.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": ["arn:aws:s3:::psc-lab-reports/*"]
  }]
}

This illustrative statement permits object reads within one named lab bucket under relevant policy evaluation. It does not by itself prove the bucket is public, establish who can assume the role, or describe every effective permission. Do not attach it to a production identity as part of this article.

Example one: an object-read allow exists but an explicit deny blocks it. Example two: a role is powerful but its trust policy prevents the reviewed principal from assuming it. Example three: an inherited project binding grants more than the local resource policy suggests. Keep those conditions explicit in the finding.

3. Analyse privilege-escalation preconditions without exploiting them

Privilege escalation is a relationship between a principal's current authority, a reachable change, and a more privileged outcome. A graph may contain principal-to-role, role-to-policy, workload-to-identity, and resource-to-secret edges. Each edge needs provenance, conditions, and a time window. Do not turn a speculative graph path into an executed escalation.

Candidate path:
principal -> can_modify_workload -> workload_uses_identity -> sensitive_resource
Validate separately:
1. Is modify permission effective in the reviewed scope?
2. Which fields are mutable, and do admission controls constrain them?
3. Is the stated identity actually attached and usable by the workload?
4. Does that identity have the claimed resource access?
5. Are approvals, conditions, or network controls missing from the graph?
Output: confirmed edges, unknown edges, evidence IDs, remediation options.

Use synthetic resources and policy simulation where supported. Do not attach a powerful role, modify a production workload, retrieve credentials, or perform a token exchange merely to make a graph path look conclusive. If active validation is necessary, it needs a separate approved lab plan.

AI can explain a candidate path and propose the cheapest missing-evidence check. Deterministic identity data and platform evaluation establish whether the edges hold. Expired temporary grants and conditional role activation must not be treated as permanent access.

4. Apply the same method to host privilege review

For Windows, inspect the current account's groups, token privileges, integrity level, service configuration, and relevant ACLs using approved read-only collection. For Linux, inspect account/group membership, sudo policy through the authorised workflow, file ownership, service definitions, and capabilities. A permission name is a lead; actual object access and execution context determine impact.

whoami /groups
whoami /priv
Get-Acl -LiteralPath 'C:\PSC-Lab\service-config.txt' | Format-List

id
stat ./lab-service.conf
getcap ./lab-helper

These commands inspect the current identity and explicitly named local lab files. Some tools are platform-specific and may not be installed. Do not enumerate unrelated hosts or use discovered credentials. Do not edit service paths, replace binaries, change sudo policy, or trigger a privileged process as an automatic next step.

Example one: a writable lab configuration is not escalation if no privileged process consumes it. Example two: a powerful token privilege may be disabled or subject to a different process context. Example three: a service runs with elevated rights but its executable and configuration are appropriately protected. Ask the assistant to identify the missing consumer or permission evidence rather than invent a chain.

5. Generate reports from structured evidence

Maintain a finding object that separates observations, inference, and limitations. Give the model redacted evidence records, not an unrestricted engagement folder. Every factual sentence should map to an evidence ID. A fluent impact paragraph without that mapping is not ready for a client.

{
  "finding_id": "CLOUD-014",
  "title": "Over-broad read access to a synthetic report bucket",
  "status": "verified_in_lab",
  "affected_asset_ids": ["lab-report-bucket"],
  "observations": [{"text": "Lab role read the approved marker object", "evidence_id": "ev-014"}],
  "inferences": ["Equivalent production grants require owner review"],
  "limitations": ["No production object access was attempted"],
  "remediation": "Restrict resource scope and validate required consumers",
  "owner": "lab-platform-team",
  "retest": ["required reader succeeds", "unapproved reader denied"]
}

Use separate technical and executive outputs. The technical report includes scope, prerequisites, reproduction, observed/expected results, root cause, remediation, and retest. The executive summary connects verified risk to business decisions without adding unobserved compromise claims. Have a human reviewer own severity, legal wording, and final scope statements.

Draft from supplied finding objects only.
Each factual claim must cite an evidence ID in the working draft.
Keep observations, inference, and limitations separate.
Do not invent affected assets, CVEs, compliance failures, or exploit results.
Return unresolved questions before the executive summary.
Do not include secrets or personal data in either output.

6. Close findings with positive and negative controls

A cloud fix may remove access needed by a legitimate job. Retest both the required consumer and the previously over-permitted principal. Verify inheritance, role sessions, cached tokens, propagation delay, and alternate regions or replicas. For host controls, confirm protected files remain usable by the service and unwritable by the lower-privilege lab user. A single access-denied screenshot is not enough.

For reporting automation, test fabricated evidence IDs, missing observations, contradictory results, and text that asks the model to remove limitations. The pipeline should refuse unsupported assertions and preserve unresolved status. Sanitise exported CSV cells if reports are opened in spreadsheets; untrusted leading formula characters can become active spreadsheet content. Render report HTML with escaping, not raw model output.

Preserve the original evidence, reviewed report revision, owner decision, remediation change, and retest outcome under the agreed retention policy. Record exceptions and accepted risk explicitly rather than quietly deleting a finding.

7. The end-to-end capstone and completion checklist

1. Use Part 1's scope and source-backed asset ledger.
2. Exercise Part 2's synthetic identity-verification scenario.
3. Apply Parts 3 to 5 to one lab API and browser flow.
4. Run Part 6's synthetic advisory triage and Part 7's local marker scan.
5. Validate the selected Burp workflow from Part 8 without expanding scope.
6. Run the benign endpoint and read-only MCP fixtures from Parts 9 and 10.
7. Analyse the same parser across Parts 11 to 13 and preserve disagreements.
8. Use Part 14's policy/verifier model to control the workflow.
9. Review cloud/host permissions, draft evidence-backed findings, fix, and retest.

Additional useful AI tasks include IaC change explanations, log-query drafting against synthetic events, remediation-ticket deduplication, executive translation, and lessons-learned clustering. Each needs the same input trust, privacy, validation, and human-ownership rules. More automation is justified only when evidence quality improves without increasing uncontrolled authority.

Final acceptance: all tested assets were authorised; every active action is attributable and bounded; each finding has reproducible evidence; unknowns remain visible; fixes retain required functionality; all fifteen parts' artefacts can be replayed without the original assistant conversation. The series ends where a professional assessment should: with a verifiable reduction in risk, not merely a larger report.

8. Step-by-Step Lab: Review a Permission Path and Produce a Defensible Finding

Prerequisites: A sanitised configuration snapshot from an owned lab, an approved read-only collection role, a synthetic resource, and a known intended-access policy. The offline evidence validator below does not call a cloud API or implement any cloud provider's permission semantics.

1. Record the account/subscription/project, exact resource, principal, role/session state, collection time, and intended policy. Keep credentials inside the collector and remove personal data before model analysis.
2. Separate policy statements from effective access. Use the platform's authoritative evaluation path and account for conditions, inherited grants, explicit denies, trust relationships, boundaries, and service-specific behaviour.
3. For a potential privilege path, enumerate each edge and its preconditions. Mark missing consumer identity, mutable-field constraints, or resource access as unresolved rather than completing a chain from intuition.
4. Use a synthetic resource and approved non-destructive check to establish the allowed and denied principals. Do not modify a production workload, retrieve credentials, or perform a token exchange to make a graph look conclusive.
5. Draft a finding object separating observation, inference, and limitation. Run the evidence-reference validator below and reject invented IDs before generating prose.
6. Assign an owner-approved least-privilege fix. Retest both the required consumer and the previously over-permitted principal after the relevant propagation and session conditions are understood.
7. Produce technical and executive outputs from the reviewed object. Preserve limitations, exception decisions, remediation revision, and retest evidence, and remove temporary sensitive exports according to retention rules.

const evidence = new Set(["policy-021", "allowed-control", "denied-control"]);
function referencesExist(finding) {
    return Array.isArray(finding.evidence_ids) && finding.evidence_ids.length > 0
        && finding.evidence_ids.every(id => evidence.has(id));
}
const valid = { evidence_ids: ["policy-021", "denied-control"], limitations: ["lab only"] };
const invented = { evidence_ids: ["production-compromise-999"] };
if (!referencesExist(valid) || referencesExist(invented)) throw Error("evidence-reference mismatch");
console.log(JSON.stringify({ knownReferences: referencesExist(valid), inventedReferences: referencesExist(invented) }));

Expected result: Known references pass and invented references fail. Existence of an evidence ID does not prove that the evidence supports the sentence; a reviewer still checks semantics, scope, timestamp, and identity. The example is an evidence-integrity gate, not a severity calculator or effective-access evaluator.

9. Worked Examples and Expected Outcomes

Example A: an allow statement is blocked elsewhere

A policy grants object reads, but a relevant explicit deny prevents access in the reviewed context. Preserve both statements and evaluation evidence. Do not report public exposure from one allow block or ask AI to approximate the provider's full policy engine.

Example B: a writable file has no privileged consumer

A lab configuration is writable by a low-privilege user, but no elevated service consumes it. Record the missing edge. File writability alone does not establish privilege escalation, and discovering a powerful service elsewhere does not connect the two automatically.

Example C: a least-privilege patch breaks a real reader

The unwanted principal is denied, but the approved report job also loses access. The security regression is not complete. Restore required functionality through a narrower owner-approved grant and rerun both controls rather than closing on one denial screenshot.

Finding review:
observation: exact lab policy or access result
inference: candidate impact, explicitly labelled
limitations: untested systems and unknown edges
owner: accountable team and change reference
retest: required reader works; unwanted reader denied
report: no secrets, invented CVEs, or unsupported compromise claims

10. Troubleshooting, Retesting, and Completion Evidence

Retest and completion: Retain the intended policy, sanitised configuration, authoritative effective-access evidence, edge-by-edge analysis, reviewed report, owner change, and positive/negative retests. Public HTML and CSV outputs must be escaped or neutralised appropriately; do not publish raw evidence directories, tokens, or private programme data.

11. Real Tool Workflow: Collect Read-Only Cloud Evidence and Produce a Local Report

Prerequisites: An approved AWS CLI profile for a dedicated lab account, least-privilege read access to one named synthetic bucket, PowerShell for local review, and explicit permission for identity/configuration queries. Placeholder account, bucket, and profile values must be replaced with owner-approved values. No cloud configuration change or object-content retrieval is shown.

Use reviewed releases and record the versions actually installed. Command references for this workflow were reviewed on 29 October 2026; product support and flags can change. Instructions and output shapes are not claims of a live assessment.

Step-by-Step Tool Operation

1. Have the owner create/approve the lab profile, exact bucket, region, account, and collection window through the normal access process. Keep credentials in the approved credential provider, not a prompt or command history.
2. Run get-caller-identity and compare the returned account/principal with the approved scope before any resource query. Stop if it is the wrong account; a familiar profile name is not proof of identity.
3. Read the named bucket's public-access-block settings, policy status, and encryption configuration using the explicit profile. Preserve timestamps and errors. AccessDenied means the collector lacks that observation, not that the configuration is safe.
4. For a host-review companion, inspect only the current identity and explicitly named disposable configuration file. Determine whether a privileged consumer actually uses that file before proposing an escalation relationship.
5. Give AI a redacted configuration packet and intended policy. Require evidence IDs, inherited/conditional-access questions, and unknown edges. Use the platform's authoritative evaluation path rather than approximating effective access from one allow statement.
6. Draft the finding locally, have the owner approve remediation, and retest required versus unwanted access with approved synthetic resources. Do not modify roles, bucket policy, workloads, service paths, or credentials as an automatic follow-up.

aws --version
$Profile = 'psc-lab'
$Bucket = Read-Host 'Exact owner-approved synthetic lab bucket'
if (-not $Bucket) { throw 'An approved bucket is required' }
aws sts get-caller-identity --profile $Profile
if ($LASTEXITCODE -ne 0) { throw 'Identity check failed' }
$ConfirmedAccount = Read-Host 'After comparing the returned identity with scope, type IDENTITY-APPROVED'
if ($ConfirmedAccount -ne 'IDENTITY-APPROVED') { throw 'Cloud collection not approved' }
aws s3api get-public-access-block --bucket $Bucket --profile $Profile --output json
aws s3api get-bucket-policy-status --bucket $Bucket --profile $Profile --output json
aws s3api get-bucket-encryption --bucket $Bucket --profile $Profile --output json
whoami /groups
whoami /priv
Get-Acl -LiteralPath 'C:\PSC-Lab\service-config.txt' | Format-List

Expected Evidence and Interpretation

The profile and file path are local setup examples, not resources provided by the site. Public-access-block and policy-status responses are useful configuration evidence but are not the complete permission decision: identity/resource policy, conditions, explicit denies, access points, organisation controls, and service behaviour can matter. Encryption settings do not prove every existing object has the intended properties.

The interactive confirmation is an operator checkpoint, not a cryptographic authorisation mechanism. For Azure or GCP, use their actual RBAC/IAM evaluation and resource scope rather than translating AWS semantics by changing field names. Large CSPM tools such as Prowler or ScoutSuite need separate permission, API-budget, and output-handling review before broader collection.

Troubleshooting and Cleanup

If credentials are expired, renew only through the approved provider; never paste tokens into chat. If an API returns AccessDenied or missing configuration, retain the exact error and mark the field unresolved until the owner explains it. Keep raw policies private, redact report exports, close/revoke short-lived test sessions as required, and ensure the final report preserves limitations and both retest controls.