Agentic Security Review and Pentest Scoping Framework

Customer profile

• Customer: Multi-Industry (productized offering)
• Industry: Technology / Security Engineering (target segments include security engineering teams, platform teams, AI-forward dev organizations, and compliance-driven organizations subject to SOC 2, ISO 27001, GDPR, or HIPAA)
• Geography: Global (United Kingdom delivery base; cloud marketplace and private-offer routes for cross-region procurement)
• Approximate size: Not disclosed (covers small security teams under five engineers up to large regulated engineering organizations)
• Engagement window: 2025-11 to 2026-05 (productization, pilot engagements, and AWS Partner Network preparation)
• CloudIgnyte AWS Partner tier at time of engagement: Select

The framework was productized to address a recurring pattern observed across CloudIgnyte's security advisory engagements: customers wanted the depth of a human-led security audit at a quarterly cadence, but no existing tool combined defensible evidence chains with first-class coverage of GenAI and agentic systems across clouds. CloudIgnyte built the framework as a vendor-neutral operating model that customers can run inside their own cloud boundary, with optional managed delivery for organizations that lack internal AI tooling maturity.

Customer challenge

Off-the-shelf AI security review tools fail enterprise adoption for two specific reasons that CloudIgnyte's pre-engagement diligence consistently surfaced:

• Hallucinated findings. Large language models invent endpoints, IAM policies, and CVEs that do not exist in the code under review. False positives erode trust within days, and security teams stop reading the output. None of the existing AI-native code review tools impose a verification contract on the model.
• No defensible evidence chain. Output is unstructured prose with no mapping from finding to code line, no severity rationale, and no verification status. Findings cannot be triaged at scale, cannot be handed to a pentester as scoping input, and cannot be referenced as evidence in a SOC 2 or ISO 27001 audit.
• GenAI and agentic coverage gap. Traditional SAST tools do not understand GenAI flows. Runtime guardrails like prompt-injection filters do not review the code that defines tool permissions, memory isolation, retrieval ACLs, or model output validation. Customers shipping GenAI workloads were left with no design-time security review surface for their agent code.
• Pentest scoping drag. External pentest engagements consistently lost two to four weeks at the start to scoping back-and-forth: what is in scope, what is the architecture, where are the trust boundaries, what credentials does the pentester need. No existing tool produced the documentation a pentest platform requires as engagement input.
• Single-repo review context. Off-the-shelf AI security review tools scope a review to one GitHub repository at a time. Real customer environments routinely split application code, infrastructure-as-code, and shared CI/CD modules across multiple repos, so a single-repo review systematically misses any finding whose root cause is the interaction between repos: an IAM role defined in a platform IaC repo and assumed by an application in a workload repo, a shared CI/CD module in a tooling repo that grants over-broad deployment permissions to its consumers, a Terraform module published in one repo whose downstream callers in other repos pass unsafe inputs. Customers consistently surface this context limitation as the reason existing AI security tools failed to land in their environment.
• One-way report generation. Existing AI security review tools produce a one-way artifact (a PDF, a markdown report, a JSON file) that lives outside the security team's existing triage workflow. Even high-quality findings are read once and forgotten because they do not flow into the CSPM platform where on-call engineers already triage cloud signals. Customers asked for findings that land in their existing security workflow, not a parallel deliverable.
• Cost-versus-cadence trade-off. Human-led security audits remain the gold standard for depth but cost USD 50,000 to USD 250,000 per engagement and take six to twelve weeks. They do not scale to monthly or quarterly cadence for most organizations.

The success criteria the framework was designed to satisfy were (a) findings whose evidence chain survives audit scrutiny, (b) first-class coverage for GenAI and agentic systems alongside traditional appsec, (c) output usable directly as pentest scoping input, (d) a review context that aggregates infrastructure-as-code across the multiple GitHub repositories real customer solutions are spread over, (e) a closed-loop integration that lands findings in the customer's existing CSPM workflow rather than as a parallel deliverable, and (f) a deployment posture that keeps customer source code and cloud credentials inside the customer boundary by default.

Solution overview

CloudIgnyte built the framework as a set of versioned steering documents and operating-model definitions that turn an agentic coding assistant (any Model Context Protocol-compatible AI coding assistant) into a structured security auditor. The framework itself is metadata: it ships as a signed, versioned package that the customer drops into their AI runtime's configuration directory. It is not a runtime SaaS service that ingests customer data.

Time compression

The framework compresses what traditionally takes 3-6 weeks of senior security-engineer time per project review into about a day of agent-driven work, followed by several hours of human review (typically at least four) and a findings walkthrough with the client. The compounding saving is that bottleneck activities such as threat modelling, deployed-state cross-checks, and multi-source correlation are the ones that traditionally get cut short under deadline pressure; those are the activities the agent never skips.

Agent compute is only part of the picture. The per-activity figures above are raw model time; the single-cycle delta total of about a day includes multi-agent orchestration, tool-sweep execution, and the iterative refutation passes that run between steps. Every review is then followed by a human review pass (at least four hours) and a session walking the client through the findings. The speedup applies to mechanical activities; human judgement is preserved at high-leverage points: severity reconciliation, novel scope decisions, the human approval gate before any finding is written to a tracker, and methodology evolution.

Multi-agent orchestration

A review is not a single-agent task. The framework spawns 4-7 parallel sub-agents from an orchestrator, each scoped to one finding domain:

• Code-delta agent: git log analysis, file-level review
• IaC + CI/CD delta agent: Terraform, GitHub Actions workflows
• External-repos agent: each cross-repository symlink
• CSPM delta agent: cloud posture issues, findings, pentest tracker
• SAST agent: static analysis tooling
• SCA agent: dependency scanning
• SBOM + CI/CD analysis agent: CycloneDX generation, workflow linting

Each sub-agent receives a self-contained scope brief and returns a structured report. The orchestrator consolidates, cross-references against the existing baseline and CSPM pentest tracker, applies EPSS prioritisation, and writes the synthesis documents.

Assertion-Based Validation

Every finding is structurally an assertion: "claim X is true about target Y with evidence E, and its security impact is S." A finding survives the review only if that assertion withstands an attempt to refute it on four falsifiable grounds:

Critical and High findings undergo lens-diverse validation (four independent validators, one per claim). Medium and Low findings undergo single-lens composite validation. Findings that fail refutation are downgraded, deferred, or dropped, with the refutation evidence recorded as audit trail. This eliminates the hallucinated-finding problem that erodes trust in competing AI security tools.

Multi-repo IaC aggregation

A core capability of the framework's agent is multi-repo IaC aggregation: the agent reads infrastructure-as-code spread across multiple GitHub repositories as a single logical solution and brings the full IaC context to the scan. Existing single-repo AI security review tools miss findings whose root cause is the interaction between IaC modules in different repos (for example a Terraform module in a platform repo defining an IAM role consumed by an application in a workload repo, or a shared CI/CD module in a tooling repo that misconfigures a workload repo's deployment). Stitching multiple repos into one review context surfaces that class of finding by design.

The architecture follows cloud-native multi-account best practices and the cloud shared responsibility model: the customer holds all credentials and operates the AI runtime, the framework imposes the operating contract that constrains the AI's output, and CloudIgnyte is not in the data path under the default Customer-managed deployment pattern. The bidirectional write path into the CSPM platform uses the customer's own credentials, configured during MCP setup; CloudIgnyte never holds those credentials.

The framework is composed of three interlocking modules:

• Module 1: Full-project security review. An eight-step iterative operating model that maps project structure, identifies trust boundaries, traces attacker-controlled input to sensitive sinks, reviews authentication and authorization paths, reviews GenAI and agentic flows (tool execution, memory isolation, retrieval ACL, prompt-to-tool boundaries), reviews IaC, CI/CD, and infrastructure configuration, extracts concrete evidence before forming conclusions, and filters speculative or low-confidence issues. The agent operates on multiple GitHub repositories as one logical solution, so cross-repo IaC interactions (an IAM role defined in a platform repo and assumed by an application in a workload repo, a shared CI/CD module that grants over-broad deployment permissions to its consumers, a Terraform module published in one repo whose downstream callers in other repos pass unsafe inputs) are reviewed in a single pass. Single-repo competitors miss this class of finding by design; the framework surfaces it as a first-class output.
• Module 2: Pentest scoping pack generator. A second operating model that produces an eight-file, date-stamped vendor-handover pack covering system components, usage scenarios, external interfaces, scope and goals, assets and risk assumptions, testing approach, sizing and identification (with resolved commit SHAs and container digests), and cloud security verification.
• Module 3: CSPM-augmented verification (bidirectional). A tool-selection guide and Model Context Protocol integration layer that maps security questions to specific CSPM queries. The current implementation targets cloud-native security services and leading CSPM platforms; the same pattern extends to any CSPM or cloud security tool accessible via API. The integration is bidirectional: the framework reads deployed cloud state from cloud-native security services and CSPM APIs to cross-reference code-level findings against runtime posture, and it writes findings back into the customer's CSPM platform, tagged to the project, so customer security teams can triage framework output in the same workflow they already use for native CSPM signals. Code- level findings are paired with deployed cloud state so a single deliverable shows both layers in one narrative.

The verification-tiered output contract is the durable advantage. Every finding carries a verification class (Code-only, CSPM-confirmed, Cloud-API-confirmed, Multi-source confirmed, or Unverified). Severity is capped by verification tier: Critical findings always require multi-source evidence, and Code-only findings are capped at Medium. Confidence scoring filters speculative output before it reaches the customer, with only scores of eight or higher reaching the report by default. Explicit anti-hallucination rules force the AI to say "not observed in reviewed code" rather than fabricate.

Implementation approach

The productization engagement ran across approximately six months and was structured as five phases: discovery, design, build, validate, and handover.

Phase 1: Discovery

CloudIgnyte profiled the existing AI security tooling landscape across six adjacent categories (traditional SAST, AI-native code review, GenAI-specific runtime tools, CSPM platforms, pentest platforms, managed security services), identified the consistent failure modes that block enterprise adoption, and validated the verification-tiered output contract against representative customer engagements. The team catalogued every place where existing tools either hallucinated or produced output that could not be defended in audit, and used those patterns as the input to the operating-model design.

Phase 2: Design

Architecture decisions were anchored to cloud-provider security frameworks (the AWS Well-Architected Security Pillar, the Microsoft Azure Well-Architected Framework, and the Google Cloud Architecture Framework) and to OWASP GenAI Project guidance. Key trade-offs:

• Operating-model contract versus prompt engineering. A formal operating model with verification tiers, severity caps, confidence scoring, and explicit anti-hallucination rules was selected over ad hoc prompt engineering because the contract is testable, versionable, and reviewable.
• Customer-managed default versus vendor-managed default. Customer- managed was selected as the default deployment pattern because it keeps customer source code, IaC, and CSPM data inside the customer boundary and qualifies CloudIgnyte as a non-processor under GDPR for the bulk of engagements. Vendor-managed and Hybrid patterns are available where customer organizational maturity demands them.
• Model Context Protocol versus bespoke connectors. MCP was selected for CSPM and cloud-API integration because it is the emerging standard for tool integration with agentic AI runtimes and avoids vendor lock-in to any single CSPM platform.
• Deliverables in plain markdown rather than vendor-proprietary format. Every deliverable (findings report, scoping pack, CSPM cross-reference) ships as plain markdown plus structured data, so customer right-of-export is preserved and no proprietary format locks content in.

The framework's GenAI and agentic coverage was designed against the OWASP GenAI Security Project taxonomy: tool-execution authorization, memory isolation, retrieval access control, prompt-to-tool boundary enforcement, and treating model output as untrusted input. Coverage was specified at the code level rather than at the runtime-guardrail level, because runtime guardrails do not see the code that defines the authorization controls in the first place.

Phase 3: Build

CloudIgnyte authored the framework as a versioned package containing:

• The eight-step security-review operating model.
• The eight-file pentest-scoping operating model with Mermaid trust- boundary diagrams auto-generated from observed architecture.
• The CSPM tool-selection guide and MCP server configurations for cloud-native security services and leading CSPM platforms, with extension points for additional cloud security tools via MCP. The CSPM integration is bidirectional: it includes a write path that publishes framework findings back into the customer's CSPM platform tagged to the project, using customer-supplied platform credentials configured at MCP-setup time.
• Output templates for the findings report (per-vulnerability format with file:line evidence, exploit scenario, verification class, severity, confidence score, and minimal-effective-fix recommendation), the eight-file scoping pack, and the CSPM cross-reference report.
• The verification-tier rules, severity caps, and confidence-score filter as machine-readable contracts the AI must satisfy.
• A reference engagement walkthrough and onboarding documentation.
• Security and audit collateral including a data flow diagram, deployment-pattern documentation, and evidence-chain documentation suitable for SOC 2 and ISO 27001 due diligence.

The framework artifact is signed and versioned under semantic versioning. Security-relevant updates ship as patch releases with an accompanying advisory. Framework files contain no embedded secrets, no embedded credentials, and no telemetry callbacks; this is enforced by the framework's own redaction-rules artifact and a continuous integration property test that scans for credential-shaped strings before any release tag is cut.

Phase 4: Validate

Validation against the success criteria was both qualitative and quantitative. CloudIgnyte ran the framework against a representative multi-component application covering an order API, a payments service, infrastructure-as-code, and a customer-facing chat agent. The resulting findings report demonstrated the verification-tiered output contract working end-to-end:

• A header-trust authentication bypass surfaced as a Code-only finding at High severity with confidence score nine, with a complete file:line evidence chain and an exploit scenario the customer's security team could reproduce.
• A publicly readable storage bucket containing personally identifiable information surfaced as a Multi-source confirmed finding at High severity with confidence score ten, cross-referencing Terraform source, the CSPM platform's classification, and a direct cloud-API confirmation.
• A tool-handler authorization gap in the chat agent surfaced as a Code-only finding at High severity, demonstrating GenAI and agentic coverage that traditional SAST tools do not provide.
• A logging-data-exposure finding in the payments service surfaced as a CSPM-confirmed finding at Medium severity, with the CSPM platform's secret-classifier output as the corroborating evidence.

The framework's exclusion rules (no DoS speculation, no theoretical races, no framework-default-escaped XSS, no dependency CVEs without exploit path) were validated against the same representative application; observed-but-excluded items were enumerated in a supplementary inventory available on request, and that enumeration was itself produced by the framework rather than by hand.

CloudIgnyte additionally produced an internal threat-model analysis of the framework itself per the project's security-best-practice steering, covering the framework artifact distribution surface, the customer- managed deployment trust boundary, the optional managed-delivery infrastructure, and the subprocessor surface (model provider, cloud provider, customer-chosen CSPM). The threat model was reviewed by CloudIgnyte's security lead before the AWS Partner Network registration was prepared.

Phase 5: Handover and run

CloudIgnyte produced runbooks for the highest-frequency operational tasks (installing the framework into a customer AI runtime, configuring CSPM MCP credentials, running a first scoping pack, running a first full review, triaging a finding, dismissing a false positive with a per-line allowlist comment, requesting a custom CSPM mapping, requesting a custom integration). Three deployment patterns are supported in production today:

• Customer-managed (default). Customer deploys the AI runtime in their own environment, drops the framework into the runtime's configuration directory, and runs reviews in-house. Source code, cloud credentials, and CSPM data never leave the customer boundary.
• Vendor-managed (managed delivery). CloudIgnyte runs the engagement on the customer's behalf inside a customer-controlled environment using a scoped, time-bounded read-only IAM role. The customer receives the deliverables without operating the AI runtime themselves.
• Hybrid (framework plus advisory). CloudIgnyte supplies the framework, training, and ongoing advisory; the customer operates the AI runtime in-house and CloudIgnyte reviews quarterly output for calibration, ships steering-file updates for emerging vulnerability classes, and provides escalation support for high-severity findings.

Three pricing models are aligned to cloud marketplace listing categories: per-engagement (Professional Services), annual subscription (SaaS Contract), and usage-based metered (SaaS Metering); enterprise terms are available via Consulting Partner Private Offer.

Quantified outcomes

• Roughly 10x time compression on mechanical security activities. Agent work that replaces 3 weeks of manual delta-review effort runs in about a day; full project reviews that would take 6-8 weeks of equivalent manual effort run in two to three days. Each review is then followed by a human review pass (at least four hours) and a walkthrough of the findings with the client.
• Fourteen-step iterative operating model covering source code, IaC, CI/CD, GenAI and agent flows, cloud configuration, mandatory deployed-state verification, tooling sweeps, CSPM cross-reference, post-findings chaining analysis, and pentest-tracker alignment, with explicit step ordering the AI must follow before producing findings.
• Multi-agent orchestration with 4-7 parallel sub-agents per cycle, each scoped to one finding domain. Orchestrator consolidates, cross-references, and applies EPSS prioritisation across all sub-agent outputs.
• Assertion-Based Validation with four falsifiable claims per finding (Reachability, Deployed State, Chain Context, Falsifiability) and structured verdict envelopes. Critical/High findings undergo lens-diverse validation (four independent validators); Medium/Low undergo single-lens composite. Eliminates hallucinated findings at source.
• Multi-repo IaC aggregation: the framework's agent stitches IaC spread across multiple GitHub repositories into a single review context, surfacing findings whose root cause is cross-repo (an IAM role defined in one repo and assumed by an application in another, a shared CI/CD module that misconfigures its consumers, a Terraform module whose downstream callers pass unsafe inputs). This is a class of finding single-repo competitors miss by design.
• Mandatory tooling sweeps across five categories: SCA, SAST, SBOM generation (CycloneDX), CI/CD static analysis, and deployed-state verification (cloud provider CLI). Manual code review is supplementary, never a substitute.
• EPSS scoring mandatory for every HIGH/CRITICAL CVE. CVSS-HIGH + EPSS ≤ 10th percentile is hygiene; CVSS-HIGH + EPSS ≥ 80th percentile is urgent. Without EPSS, CVSS alone over-states urgency.
• Post-findings chaining phase that assembles cross-cutting multi-finding chains, each with provable staged reproduction, per-link evidence, and an effective-severity rating.
• 17-20 markdown files + CycloneDX SBOMs per review output pack.
• Eight-file vendor-ready pentest scoping pack generated per engagement, replacing weeks of manual scoping work.
• Verification-tiered findings across four classes (Code-only, CSPM-confirmed, Cloud-API-confirmed, Multi-source confirmed) with severity caps that prevent unverified Critical findings.
• Bidirectional CSPM-augmented verification via Model Context Protocol against cloud-native security services and CSPM platforms.
• Review cost measured in dollars per cycle in compute and LLM spend versus several thousand dollars per equivalent manual review.
• IDE-agnostic delivery: runs on any MCP-compatible AI coding assistant, with identical steering content across environments.
• Alignment with six industry frameworks (OWASP GenAI Project, OWASP Testing Guide, STRIDE, CIS Benchmarks, AWS Well-Architected Security Pillar, NSA Zero Trust Implementation Guides) and the CWE taxonomy.
• Three cloud-marketplace-aligned pricing models and three deployment patterns keeping customer source code and cloud credentials inside the customer boundary by default.
• Audit-defensible evidence chain with per-finding file:line references, exploit scenarios, verification class, severity rationale, confidence score, and minimal-effective-fix recommendation, suitable for use as evidence in SOC 2 Type II CC7 and CC8 controls and ISO 27001 Annex A controls A.8.25, A.8.26, A.8.28, and A.8.29.

Partner value

• CloudIgnyte certified delivery posture. The engagement was led by CloudIgnyte staff carrying current cloud security and architecture certifications across AWS, Microsoft Azure, and Google Cloud, with subject-matter expertise spanning cloud security posture management, identity federation, GenAI and agentic system threat modelling, and multi-cloud security-framework review.
• CloudIgnyte-authored operating model. The verification-tiered output contract, the severity caps, the confidence-score filter, and the explicit anti-hallucination rules are CloudIgnyte original work and are the durable advantage over off-the-shelf AI security tools. No competitor product imposes an equivalent contract on the model.
• Reusable CloudIgnyte capability portfolio. The framework composes with CloudIgnyte's other cloud delivery patterns (multi-account governance, centralized logging and analytics, WAF and firewall standardization, multi-account backup and recovery) so a customer engaging CloudIgnyte for the framework can extend into adjacent CloudIgnyte capabilities without changing partner.
• Cloud-native, vendor-neutral integration posture. By going through Model Context Protocol rather than bespoke per-vendor connectors, CloudIgnyte preserved customer optionality on future CSPM tooling and avoided lock-in to any single platform. The MCP integration is bidirectional where the underlying platform supports it: the framework reads from CSPM platforms and cloud-native APIs for cross-reference verification, and writes findings back into the customer's CSPM platform tagged to the project.
• CloudIgnyte-scoped review context. Before any review begins, CloudIgnyte maps the customer's full solution boundary: every repository, IaC module, shared CI/CD pipeline, and cloud account that constitutes the product. The framework then reviews that entire scope as a single logical unit, surfacing findings whose root cause spans multiple repositories or accounts. Off-the-shelf AI security tools scope a review to one repository at a time and structurally cannot detect this class of cross-boundary finding.
• Documented threat-model review. CloudIgnyte produced an internal threat-model analysis of the framework itself and of every customer engagement before delivery, covering data flows, trust boundaries, subprocessors, encryption posture, and incident response. The analysis is referenced here only as confirmation that a review took place; it is not part of this public case study.

Lessons learned

• The verification-tier contract is the product. The single highest- leverage design decision was making verification class, severity cap, and confidence score machine-checkable contracts the AI must satisfy before output reaches the customer. Customers who tried earlier AI security tools and abandoned them due to false-positive volume consistently called out the contract as the differentiator.
• Assertion-Based Validation closes the hallucination gap. Adding a mandatory refutation pass (where every Critical and High finding must survive four falsifiable challenges before reaching the report) eliminated the category of finding that eroded trust in earlier AI security tools. The validation cost is negligible relative to the credibility it buys.
• Methodology hardens through gap discovery, not upfront design. The framework iterated across multiple review cycles, with each cycle surfacing a gap and codifying its remedy: missing SAST/SCA tooling sweeps became mandatory gates, IaC-trusted-as-deployed became mandatory CLI verification, Confluence consultation became a required first step, and cross-cutting chain analysis became a mandatory post-findings phase. This iterative hardening pattern is itself a product feature: it means the methodology improves with every engagement rather than degrading.
• Multi-agent orchestration is essential, not optional. A single agent cannot hold the context of a 10-repo project, run 5+ tooling sweeps, query CSPM, verify deployed state, and synthesise findings in one pass. Parallel sub-agents with scoped briefs produce higher- quality output and fail more gracefully (a sandbox denial in one sub-agent doesn't block the review).
• GenAI coverage must be design-time, not runtime-only. Runtime prompt-injection filters do not review the code that defines tool permissions, memory boundaries, retrieval ACLs, or model output validation logic. Customers shipping GenAI workloads need both runtime guardrails and design-time review; the framework is the design-time surface.
• Customer-managed by default keeps procurement simple. Making the customer-managed deployment pattern the default qualified CloudIgnyte as a non-processor under GDPR for the bulk of engagements and shortened the vendor-risk-assessment cycle on initial customer conversations.
• MCP is the right integration substrate. Model Context Protocol removed the need to maintain bespoke connectors per CSPM platform and let the framework grow coverage by adding configuration rather than by writing code.
• Single-repo competitors miss cross-repo IaC findings entirely. The highest-severity misconfiguration findings in real customer environments are invisible to AI security tools that scope a review to a single repository at a time. This validated the multi-repo aggregation design choice early and is now the framework's clearest competitive differentiator alongside the verification-tier contract.
• Failure modes must be documented, not hidden. When tooling cannot run (sandbox denied, network restricted, tool not installed, MCP disconnected), the framework requires explicit documentation of the coverage gap and a functionally-equivalent substitute. Silent skips are structurally prevented by the pre-handover checklist. This transparency is itself a trust signal customers value.

One-sentence summary

CloudIgnyte productized the Agentic Security Review and Pentest Scoping Framework, an operating model that turns an AI coding assistant into a disciplined security auditor for cloud-native applications, GenAI systems, and multi-cloud workloads, compressing reviews that take senior engineers weeks into days while raising coverage, and delivering evidence-grounded, verification-tiered findings and pentest-ready scoping packs that flow straight into the customer's existing CSPM workflow, deployable in three patterns that keep source code and cloud credentials inside the customer boundary by default.