{"slug": "how-my-8-layer-autonomous-agentic-security-architecture-found-validated-in-nasa", "title": "How My 8-Layer Autonomous Agentic Security Architecture Found Validated Vulnerabilities in NASA Flight Software and Google Cloud Ecosystems", "summary": "Security researcher HM Shihabuddin Jashory (Shihab) built an 8-layer autonomous agentic security architecture that pairs a 4-tier multi-agent verification hierarchy with a sibling patch-gap engine, and used it to surface validated vulnerabilities in NASA flight software and Google Cloud ecosystems. The work produced a merged fix in nasa/fprime (PR #6299) and two P2-triaged disclosures in the Google Vulnerability Reward Program, among 10 active Google VRP disclosures, with additional audits across NASA, the Space Telescope Science Institute, Google, Bazel, ChromeDevTools, Anthropic and Cloudflare repositories. The architecture enforces that every finding be backed by a benign proof-of-concept and a git diff remediation patch, with adversarial review at the Chief Auditor tier to disprove exploitability.", "body_md": "**Author**: **HM Shihabuddin Jashory (Shihab)**\n\n**GitHub**: [`@jashory`](https://github.com/jashory) | **ORCID / Research DOI**: `10.5281/zenodo.23832719`\n\n**Canonical Gist**: `8-Layer-Agentic-Architecture-NASA-Google-Case-Study.md`\n\nMost automated security scanners drown maintainers in theoretical alerts and false positives. Over the past year, I designed and deployed an **8-Layer Autonomous Agentic Security Architecture** ([`DOI: 10.5281/zenodo.23832719`](https://doi.org/10.5281/zenodo.23832719)) built around a simple premise: **every security patch is a map to the bugs that were missed right next to it.**\n\nBy combining a **4-Tier Multi-Agent Verification Hierarchy** with a specialized **Sibling Patch-Gap Engine**, this architecture systematically audited mission-critical open-source infrastructure—resulting in:\n\n`nasa/fprime`) spacecraft flight software framework` PR #6299``@bitWarrior` from `GHSA-pq8v-c63j-wv29`` P2` triaged disclosures in Google Vulnerability Reward Program (`Google VRP`)` Issue #580130935` and `Issue #580032520`, among 10 active Google VRP disclosures).` GHSA` / `VDP`)` nasa/fprime-gds`, `nasa/CryptoLib`, `nasa/spacewasm`, `nasa/openmct`, `nasa/earthdata-search`, `nasa/harmony`), the Space Telescope Science Institute (` spacetelescope/jwql` for the James Webb Space Telescope), Google (`google/adk-*`, `google-gemini/gemini-cli`, `googleapis/mcp-toolbox`, `cdapio/cdap`, `genkit-ai/genkit`, `firebase/firebase-tools`, `google/osv-scalibr`, `angular/angular-cli`, `google/oss-fuzz`), Bazel (` bazelbuild/bazel-central-registry`), ChromeDevTools (` ChromeDevTools/chrome-devtools-mcp`), Anthropic (` modelcontextprotocol/inspector`, `modelcontextprotocol/servers`), and Cloudflare (` cloudflare/workers-sdk`).\nHere is an inside look at the architecture, why **Sibling Patch-Gap Analysis** works so reliably on hardened codebases, and how multi-agent verification eliminates the \"AI slop\" crisis in security research.\n\nTraditional SAST tools rely on fixed syntactic rules. When they scan a million-line C++ flight software repository or a distributed TypeScript cloud SDK, they flag thousands of low-impact patterns while completely missing domain-specific trust boundary violations.\n\nConversely, first-generation LLM bug-hunting scripts hallucinate attack paths that cannot actually execute because they never compile the target, never inspect runtime state, and never verify whether an upstream reverse proxy or caller already sanitizes the input.\n\nWhen I architected the **8-Layer Autonomous Agentic Security Architecture** (`DOI: 10.5281/zenodo.23832719`), I enforced two strict engineering invariants:\n\n`git diff` remediation patch.`Worker -> Supervisor -> Chief Auditor -> Tier-0 System Integrator`)\n\n```\n+-------------------------------------------------------------------------+\n| Tier-0: System Integrator (SI)                                          |\n| Final cross-check of source code, benign PoC output, and git diff patch |\n+-------------------------------------------------------------------------+\n                                    ^\n                                    |\n+-------------------------------------------------------------------------+\n| Tier-1: Chief Auditor                                                   |\n| Adversarial review: attempts to disprove exploitability & check guards  |\n+-------------------------------------------------------------------------+\n                                    ^\n                                    |\n+-------------------------------------------------------------------------+\n| Tier-2: Supervisor Agent                                                |\n| Orchestrates target scope, CWE taxonomy, and sibling commit graph audit |\n+-------------------------------------------------------------------------+\n                                    ^\n                                    |\n+-------------------------------------------------------------------------+\n| Tier-3: Specialized Worker Agents                                       |\n| Shallow clone, AST/dataflow trace, benign local harness & patch builder |\n+-------------------------------------------------------------------------+\n```\n\nWhen a security team patches a vulnerability (`CVE` or `GHSA`), human engineers naturally focus on the exact file, function, or branch reported in the advisory. However, large engineering repositories rarely implement a pattern only once:\n\n`filepath.Rel()` or `Path.resolve()` in one handler, a sibling handler—or a v2 rewrite branch—often misses the edge case (such as trailing separator absence, Windows volume-relative paths, or Git worktree alternates).\nInstead of scanning codebases blindly from scratch, the engine executes a 4-stage loop:\n\n`CVE`) and hardening commits (` fix(security):`, `Harden ...`, `Validate ...`, `Escape ...`) across target repositories.` target.startswith(base_dir)`\n`Path(target).resolve().is_relative_to(Path(base_dir).resolve())`\n`execFileSync`, `os.Open`, `git.Repo`, `fetch` redirect handlers).\n[**F´ (F Prime)**](https://github.com/nasa/fprime) is NASA Jet Propulsion Laboratory's (JPL) flight-proven software framework used for spacecraft, CubeSats, and instruments (including the Mars Helicopter *Ingenuity* heritage ecosystem).\n\nIn earlier security hardening (`PR #5320` and `PR #5850`), NASA introduced `Os::SandboxedFile` to enforce strict directory containment for flight file operations across components such as `Svc/FileUplink`, `Svc/FileDownlink`, and `Svc/FileManager`.\n\n`CWE-22` — Missing `Os::SandboxedFile` in `Svc/CmdSequencer`)\nUsing the **Sibling Patch-Gap Engine**, our architecture mapped every component in `nasa/fprime` that opens flight files by path and compared their `Os::File` declarations against the `Os::SandboxedFile` migration:\n\n`FileUplink`, `FileDownlink`, and `FileManager` had been migrated to `Svc/CmdSequencer/FPrimeSequence.hpp:237` and `Svc/CmdSequencer/FPrimeSequence.cpp:373-449`) still instantiated a raw, unsandboxed `Os::File m_sequenceFile;`.` CmdSequencerImpl::validate` / `CS_VALIDATE` / `CS_RUN`) bypassed the We reported the root cause along with a clean, flight-code-compliant remediation patch via GitHub Private Vulnerability Reporting ([`GHSA-pq8v-c63j-wv29`](https://github.com/nasa/fprime/security/advisories/GHSA-pq8v-c63j-wv29)).\n\n`CmdSequencer` had been missed during the `Update CmdSequencer's FPrimeSequence to use Os::SandboxedFile`)\nFollowing that validation, our engine expanded across NASA's broader flight and ground-data software portfolio, submitting verified defensive reports with ready-to-merge patches for:\n\n`GHSA-rm58-f49w-5c3g`)` GHSA-pfm4-7hrj-24jp`)` GHSA-3p2g-79q9-39cr`)` GHSA-mhv6-5g6q-c4jg`)` Issue #2111`)` Issue #995`)` Issue #1809`)\nAs AI agent protocols (`MCP` / Model Context Protocol) and cloud CLIs (`genkit`, `firebase-tools`, `wrangler`) rapidly adopt local HTTP servers, OAuth callbacks, and Git workspace inspection, they introduce subtle cross-boundary vulnerabilities.\n\nUsing the **Sibling Patch-Gap Engine**, we uncovered a recurring class of vulnerabilities across flagship developer tools:\n\nWhen an AI tool or CLI validates that a directory is a legitimate Git repository inside an allowed workspace, checking `Path(repo).resolve()` is not enough if the underlying Git library reads `<common_dir>/objects/info/alternates` or if linked Git worktrees (`git worktree add`) cause `git_dir` and `common_dir` boundary sets to diverge. Because Git follows `objects/info/alternates` transparently during object reads (`git show`, `git diff`), an attacker-controlled `.git` metadata directory inside an allowed workspace can point its object store to another repository outside the workspace without using a single filesystem symlink.\n\n`CWE-88`) Surviving Command-Injection Fixes\nWhen developers fix shell command injection (`CWE-78`) by replacing `execSync(\"git ... \" + userArg)` with `execFileSync(\"git\", [\"show\", \"-s\", \"--format=%B\", userArg])`, they eliminate shell metacharacter expansion. However, if `userArg` is not preceded by an end-of-options delimiter (`--`) or validated against a strict hex-SHA regex, passing `--output=<path>` as `userArg` turns `git show` or `git diff` into an arbitrary file-write primitive (`CWE-88`).\n\n`CWE-200`)\nWhen a CLI or SDK attaches `Authorization: Bearer <token>` or `x-goog-api-key` to an initial HTTPS request and relies on standard `fetch(..., { redirect: \"follow\" })`, standard runtime fetch implementations forward custom headers—or preserve `POST` bodies across `307`/` 308` redirects—to cross-origin redirect targets unless headers are stripped on a `redirect: \"manual\"` hop check.\n\n`v1`, `v2`, `next`)—for sibling functions that share the same architectural assumption.`--` (End-of-Options) Everywhere in Subprocess Arrays`execSync` with `spawn` stops shell injection (`CWE-78`), but it does `/^[0-9a-fA-F]{7,64}$/`.`.git` Metadata Inside Untrusted Archives or Workspaces`.git/` resolves within an allowed directory, plain-text Git configuration (`core.fsmonitor`, `core.sshCommand`, `diff.external`) and `.git/objects/info/alternates` can cross directory boundaries or execute commands when standard `git` subcommands run.\n**HM Shihabuddin Jashory (Shihab)** (`@jashory`) is a security researcher, systems architect, and founder of **Vision Flow**, specializing in autonomous multi-agent verification systems, supply-chain security, and mission-critical software auditing.\n\n`Zenodo DOI`)", "url": "https://wpnews.pro/news/how-my-8-layer-autonomous-agentic-security-architecture-found-validated-in-nasa", "canonical_source": "https://dev.to/jashory/how-my-8-layer-autonomous-agentic-security-architecture-found-validated-vulnerabilities-in-nasa-5hgc", "published_at": "2026-10-31 19:19:33+00:00", "updated_at": "2026-10-31 19:21:53.299153+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["HM Shihabuddin Jashory", "NASA", "Google", "Google Vulnerability Reward Program", "nasa/fprime", "Space Telescope Science Institute", "Anthropic", "Cloudflare"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-my-8-layer-autonomous-agentic-security-architecture-found-validated-in-nasa", "markdown": "https://wpnews.pro/news/how-my-8-layer-autonomous-agentic-security-architecture-found-validated-in-nasa.md", "text": "https://wpnews.pro/news/how-my-8-layer-autonomous-agentic-security-architecture-found-validated-in-nasa.txt", "jsonld": "https://wpnews.pro/news/how-my-8-layer-autonomous-agentic-security-architecture-found-validated-in-nasa.jsonld"}}