feat:implement APTS-MR-024: Final LLM Output Sanitization and Validation

README.md

@@ -34,7 +34,7 @@ APTS is not a testing methodology. It complements PTES, OWASP WSTG, and OSSTMM b
 - **Tier 2 (Verified)**: 85 additional (157 cumulative). Full transparency, tamper-proof audit trails, and independently verifiable findings.
 - **Tier 3 (Comprehensive)**: 16 additional (173 cumulative). Highest assurance for critical infrastructure and L4 autonomous operations.
 
-Nineteen additional advisory practices live exclusively in the [Advisory Requirements appendix](./standard/appendix/Advisory_Requirements.md) under the `APTS-<DOMAIN>-A0x` identifier pattern. Advisory practices are not counted toward any tier and do not affect conformance.
+Twenty additional advisory practices live exclusively in the [Advisory Requirements appendix](./standard/appendix/Advisory_Requirements.md) under the `APTS-<DOMAIN>-A0x` identifier pattern. Advisory practices are not counted toward any tier and do not affect conformance.
 
 APTS has no certification body, no mandatory third-party audit, and no fee. Platforms are assessed against the requirements and conformance is documented. The standard does not prescribe who performs the assessment; internal self-assessment, independent internal review, and external third-party assessment are all valid approaches, and the choice is left to the reader.
 

index.md

@@ -45,7 +45,7 @@ APTS is not a testing methodology. It complements PTES, OWASP WSTG, and OSSTMM b
 - **Tier 2 (Verified)**: 85 additional (157 cumulative). Full transparency, tamper-proof audit trails, and independently verifiable findings.
 - **Tier 3 (Comprehensive)**: 16 additional (173 cumulative). Highest assurance for critical infrastructure and L4 autonomous operations.
 
-Nineteen additional advisory practices live exclusively in the [Advisory Requirements appendix](./standard/appendix/Advisory_Requirements.md) under the `APTS-<DOMAIN>-A0x` identifier pattern. Advisory practices are not counted toward any tier and do not affect conformance.
+Twenty additional advisory practices live exclusively in the [Advisory Requirements appendix](./standard/appendix/Advisory_Requirements.md) under the `APTS-<DOMAIN>-A0x` identifier pattern. Advisory practices are not counted toward any tier and do not affect conformance.
 
 APTS has no certification body, no mandatory third-party audit, and no fee. Platforms are assessed against the requirements and conformance is documented. The standard does not prescribe who performs the assessment; internal self-assessment, independent internal review, and external third-party assessment are all valid approaches, and the choice is left to the reader.
 

standard/6_Manipulation_Resistance/Implementation_Guide.md

@@ -440,6 +440,116 @@ Where reasoning traces are available, scan eval-side transcripts for evaluation-
 
 ---
 
+### APTS-MR-A04: Final LLM Output Sanitization and Downstream Context Isolation
+
+> This section provides implementation guidance for the advisory practice [APTS-MR-A04](../appendix/Advisory_Requirements.md#apts-mr-a04-final-llm-output-sanitization-and-downstream-context-isolation-advisory). It is not required for conformance at any tier.
+
+**Implementation:** Implement a context-aware output validation and encoding layer at the platform's emission and execution boundaries. The layer intercepts all LLM-generated artifacts—findings, PoC scripts, evidence bundles, exported telemetry, web dashboard views, integration webhooks (e.g., Jira, Slack, SIEM), and internal pipeline channels (scoring, evidence, audit)—before they reach execution engines, presentation DOMs, or external sinks.
+
+**Architecture Pattern: Context-Specific Output Validation & Parameterized Dispatch**
+
+The implementation separates output handling into two complementary mechanisms: schema-enforced contextual encoding for data deliverables, and parameterized argument vector (`argv`) validation for executable deliverables.
+
+```python
+import html
+import ipaddress
+import socket
+import subprocess
+from urllib.parse import urlparse
+from pydantic import BaseModel, field_validator
+
+# 1. Data Deliverable Validation (Reporting, Exports, Webhooks)
+class FindingExportPayload(BaseModel):
+    title: str
+    description: str
+    target_url: str
+    severity: str
+
+    @field_validator("title", "description")
+    @classmethod
+    def escape_html_entities(cls, v: str) -> str:
+        """Prevent Stored XSS in customer reporting dashboards and HTML/PDF exports."""
+        return html.escape(v, quote=True)
+
+    @field_validator("target_url")
+    @classmethod
+    def validate_egress_url(cls, v: str) -> str:
+        """
+        Prevent SSRF / Cloud Metadata endpoint poisoning in integrations and exports.
+        Resolves hostnames to IP addresses and rejects private, loopback, link-local,
+        reserved, multicast, and provider-specific metadata destinations.
+        """
+        parsed = urlparse(v)
+        if parsed.scheme not in {"http", "https"}:
+            raise ValueError(f"Disallowed URL scheme: {parsed.scheme}")
+        hostname = parsed.hostname or ""
+
+        # Parse direct IP or resolve hostname
+        try:
+            ip = ipaddress.ip_address(hostname)
+        except ValueError:
+            try:
+                ip = ipaddress.ip_address(socket.gethostbyname(hostname))
+            except socket.gaierror:
+                raise ValueError("Could not resolve egress destination")  # fail closed
+
+        # Block RFC 1918 private IPs, loopback, link-local (AWS/Azure/GCP 169.254.169.254, ECS 169.254.170.2),
+        # reserved, multicast, and Alibaba Cloud metadata (100.100.100.200)
+        if (
+            ip.is_private
+            or ip.is_loopback
+            or ip.is_link_local
+            or ip.is_reserved
+            or ip.is_multicast
+            or str(ip) == "100.100.100.200"
+        ):
+            raise ValueError("Forbidden internal or metadata egress destination")
+        return v
+
+# 2. Executable Deliverable Validation (Synthesized PoC Commands)
+def dispatch_synthesized_poc(
+    tool_binary: str,
+    args: list[str],
+    audit_logger
+) -> subprocess.CompletedProcess:
+    """
+    Execute synthesized PoC actions using array-based argument vectors.
+    Never pass composed raw strings to sh -c or system().
+    """
+    # Enforce tool binary allowlist (backstopped by APTS-SC-020)
+    ALLOWED_BINARIES = {"/usr/bin/curl", "/usr/bin/nmap", "/usr/bin/dig"}
+    if tool_binary not in ALLOWED_BINARIES:
+        audit_logger.warning("poc_dispatch_blocked", extra={"tool": tool_binary, "reason": "unauthorized binary"})
+        raise PermissionError(f"Unauthorized tool binary: {tool_binary}")
+
+    # Parameterized execution: args are distinct array elements, preventing shell metacharacter expansion
+    return subprocess.run(
+        [tool_binary, *args],
+        capture_output=True,
+        text=True,
+        shell=False,  # Enforce no shell interpolation
+        timeout=30,
+    )
+```
+
+**Key Considerations:**
+- **Execution boundary takes precedence:** For synthesized PoC code, validation must occur at the final execution dispatch boundary. Metacharacter stripping or prompt-level instructions ("only generate safe commands") fail open against determined prompt injection. Array-based argument vectors (`shell=False`, distinct `argv` parameters) ensure shell metacharacters like `;`, `&`, `|`, `$()`, or `` ` `` cannot trigger command chaining.
+- **Context determines encoding:** A string that is safe for JSON export can be lethal when injected into an unescaped HTML report template or a markdown renderer supporting raw HTML. Apply encoding specific to the destination sink at the boundary where the sink is invoked.
+- **Isolate internal sinks:** Emitted data also flows backward into platform internals (finding scoring pipelines, structured audit trails, evidence stores). Validate and sanitize LLM output before passing it to internal sinks to prevent audit log injection (e.g., CRLF log splitting) or metric manipulation.
+- **Sandboxed presentation frames:** Web UI dashboards should render findings and PoC narratives within sandboxed frames (e.g., `iframe` with `sandbox="allow-same-origin"` or strict Content Security Policy disabling inline script execution). **Security Warning:** Never combine `allow-same-origin` with `allow-scripts` on untrusted content frames; this combination allows sandboxed scripts to programmatically remove their own sandbox attribute and execute arbitrary script in the parent origin context.
+- **Egress SSRF, DNS resolution, and IP pinning:**
+  - *Blocking DNS resolver:* `socket.gethostbyname()` is a synchronous/blocking call; use an asynchronous DNS resolver (e.g., `asyncio.get_event_loop().getaddrinfo()`) if executing validation on asynchronous pipeline loops.
+  - *Time-of-Check to Time-of-Use (TOCTOU) & DNS Rebinding:* Per the OWASP SSRF Prevention Cheat Sheet, schema-level validation of resolved IPs does not guarantee that the HTTP client uses the same IP upon connection execution. Production implementations should pin the validated IP directly to the outbound socket connection (or use a dedicated egress proxy with strict IP-level filtering) rather than re-resolving hostnames at request time.
+  - *Cloud metadata coverage:* Link-local ranges (`169.254.0.0/16`) protect AWS, Azure, GCP, and OpenStack IMDS (`169.254.169.254`) and AWS ECS task metadata (`169.254.170.2`). Explicitly include provider-specific non-link-local metadata endpoints such as Alibaba Cloud (`100.100.100.200`) and GCP internal DNS (`metadata.google.internal`).
+
+**Common Pitfalls:**
+- **Relying on upstream sanitization for executable code:** Assuming that because MR-002 sanitized input data, the LLM's generated PoC script is safe to pass to `os.system()` or `sh -c`. The model itself can synthesize arbitrary payloads from indirect cues.
+- **Decoding after sanitizing:** Performing HTML entity encoding and subsequently running a formatting pass or template engine that decodes HTML entities before rendering.
+- **Overlooking webhook and export SSRF:** Exporting findings to customer issue trackers (Jira, GitHub Issues, Slack) where an LLM-injected webhook URL or markdown image tag targets internal services (`http://169.254.169.254/latest/meta-data/`, `http://100.100.100.200/latest/meta-data/`, or internal admin endpoints).
+- **String-matching hostnames without IP resolution:** Filtering URLs by prefix string (e.g., checking for `"10."` or `"127.0.0.1"`) without resolving DNS or normalizing IP encodings, leaving the egress pipeline open to DNS rebinding, hex/decimal IP representations (`0x7f000001`, `2130706433`), IPv6 loopback (`[::1]`), and RFC 1918 `172.16.0.0/12` bypasses.
+
+---
+
 ## Implementation Roadmap
 
 **Tier 1 (implement before any autonomous pentesting begins):**

standard/6_Manipulation_Resistance/README.md

@@ -62,7 +62,7 @@ The 23 requirements in this domain fall into seven thematic groups:
 
 A platform claims conformance with this domain by implementing every MUST requirement assigned to the compliance tier it targets and to all lower tiers, with no deviation, and by either implementing every SHOULD requirement at those tiers or recording a documented justification for each deviation in its conformance claim (see the [Conformance Claim Template](../appendix/Conformance_Claim_Template.md)). An unimplemented MUST requirement or an undocumented SHOULD deviation is a conformance gap. APTS defines three cumulative compliance tiers (Tier 1 Foundation, Tier 2 Verified, Tier 3 Comprehensive) in the [Introduction](../Introduction.md); a Tier 2 platform satisfies every Tier 1 MR requirement plus every Tier 2 MR requirement, and a Tier 3 platform satisfies all three tiers.
 
-Three advisory practices relevant to this domain (APTS-MR-A01 Goal Misgeneralization and Emergent Misalignment Evaluation Suite, APTS-MR-A02 Sandbagging Detection and Behavioral Consistency Validation, and APTS-MR-A03 Multi-Turn Adversarial Conversation Resilience) are documented in the [Advisory Requirements appendix](../appendix/Advisory_Requirements.md). They are not required for conformance at any tier.
+Four advisory practices relevant to this domain (APTS-MR-A01 Goal Misgeneralization and Emergent Misalignment Evaluation Suite, APTS-MR-A02 Sandbagging Detection and Behavioral Consistency Validation, APTS-MR-A03 Multi-Turn Adversarial Conversation Resilience, and APTS-MR-A04 Final LLM Output Sanitization and Downstream Context Isolation) are documented in the [Advisory Requirements appendix](../appendix/Advisory_Requirements.md). They are not required for conformance at any tier.
 
 Every requirement in this domain includes a Verification subsection listing the verification procedures a reviewer uses to confirm implementation.
 
@@ -1064,3 +1064,5 @@ The rest of Manipulation Resistance defends against an outside attacker trying t
 > **See also:** [APTS-MR-A01: Goal Misgeneralization and Emergent Misalignment Evaluation Suite](../appendix/Advisory_Requirements.md#apts-mr-a01-goal-misgeneralization-and-emergent-misalignment-evaluation-suite-advisory). An advisory practice for platforms using fine-tuned or adapted LLM-based agents. Evaluates the agent's underlying objective alignment under distribution shift and detects emergent misalignment after fine-tuning, addressing failure modes that input-side (MR-013) and control-side (MR-020) adversarial testing do not cover. Candidate for tier-gated inclusion in v0.2.0.
 
 > **See also:** [APTS-MR-A02: Sandbagging Detection and Behavioral Consistency Validation](../appendix/Advisory_Requirements.md#apts-mr-a02-sandbagging-detection-and-behavioral-consistency-validation-advisory). An advisory practice for platforms running an adversarial eval suite under MR-020 against the same model configuration deployed in customer engagements. Measures the behavioral delta between eval context and production context on the same model snapshot tracked under AR-019, addressing eval-awareness and sandbagging that MR-020's pass-rate metric alone cannot detect. Candidate for tier-gated inclusion in v0.2.0.
+
+> **See also:** [APTS-MR-A04: Final LLM Output Sanitization and Downstream Context Isolation](../appendix/Advisory_Requirements.md#apts-mr-a04-final-llm-output-sanitization-and-downstream-context-isolation-advisory). An advisory practice for platforms generating findings, proof-of-concept (PoC) code, evidence summaries, export bundles, web dashboard views, internal pipeline state, or integration payloads from LLM outputs. Contextually encodes and validates outputs before dispatching to execution environments, storage engines, customer integrations, internal processing sinks, or presentation layers, addressing OWASP Top 10 for LLM Applications (LLM10:2026 / LLM05:2025 Improper Output Handling). Candidate for tier-gated inclusion in v0.2.0 (likely as MUST | Tier 2).

standard/Frontispiece.md

@@ -74,5 +74,5 @@ Licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/).
 
 | Version | Date | Notes |
 |---------|------|-------|
-| 0.1.0 | April 2026 | Initial release. Eight domains, 173 tier-required requirements across three compliance tiers, plus 19 advisory practices in the appendix. |
+| 0.1.0 | April 2026 | Initial release. Eight domains, 173 tier-required requirements across three compliance tiers, plus 20 advisory practices in the appendix. |
 

standard/Getting_Started.md

@@ -94,7 +94,7 @@ Depending on your role:
 ## Common Questions
 
 **Q: Do I need to implement all 173 requirements?**
-No. Start with Tier 1 (72 requirements). Tier 2 and Tier 3 add requirements progressively for cumulative totals of 157 and 173. An additional 19 advisory practices live in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md) under the `APTS-<DOMAIN>-A0x` identifier pattern; advisory practices are not required for conformance at any tier. See [Introduction: Compliance Tiers](Introduction.md#compliance-tiers) for details.
+No. Start with Tier 1 (72 requirements). Tier 2 and Tier 3 add requirements progressively for cumulative totals of 157 and 173. An additional 20 advisory practices live in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md) under the `APTS-<DOMAIN>-A0x` identifier pattern; advisory practices are not required for conformance at any tier. See [Introduction: Compliance Tiers](Introduction.md#compliance-tiers) for details.
 
 **Q: What if my platform meets most but not all Tier 1 requirements?**
 APTS does not award partial credit. A tier claim requires every MUST requirement at the claimed tier and all lower tiers to be implemented, with no deviation. Every SHOULD requirement at those tiers must be either implemented or covered by a documented justification in the conformance claim. Address MUST gaps before claiming a tier.

standard/Introduction.md

@@ -44,7 +44,7 @@ APTS does not prescribe who performs the assessment. The choice of internal self
 | 7 | Third-Party & Supply Chain Trust | TP | 22 | AI providers, cloud dependencies, data handling, foundation model disclosure |
 | 8 | Reporting | RP | 15 | Finding validation, confidence scoring, coverage disclosure |
 
-**Total: 173 tier-required requirements** (Tier 1 + Tier 2 + Tier 3) across the eight domains. An additional **19 advisory practices** live exclusively in the [Advisory Requirements](appendix/Advisory_Requirements.md) appendix using the `APTS-<DOMAIN>-A0x` identifier pattern; advisory practices are not counted toward any tier and do not affect conformance.
+**Total: 173 tier-required requirements** (Tier 1 + Tier 2 + Tier 3) across the eight domains. An additional **20 advisory practices** live exclusively in the [Advisory Requirements](appendix/Advisory_Requirements.md) appendix using the `APTS-<DOMAIN>-A0x` identifier pattern; advisory practices are not counted toward any tier and do not affect conformance.
 
 ---
 

standard/README.md

@@ -1,6 +1,6 @@
 # OWASP Autonomous Penetration Testing Standard
 
-This is the full OWASP Autonomous Penetration Testing Standard. It defines 173 tier-required requirements across 8 domains (plus 19 advisory practices in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md)) that autonomous penetration testing platforms must meet to operate safely, transparently, and within defined boundaries, whether delivered by vendors, operated as a service, or built in-house by enterprise security teams.
+This is the full OWASP Autonomous Penetration Testing Standard. It defines 173 tier-required requirements across 8 domains (plus 20 advisory practices in the [Advisory Requirements appendix](appendix/Advisory_Requirements.md)) that autonomous penetration testing platforms must meet to operate safely, transparently, and within defined boundaries, whether delivered by vendors, operated as a service, or built in-house by enterprise security teams.
 
 ## Getting Started