Summary

News

About

CYSE 587: Cyber Security Systems Engineering. 3 credits.

This course addresses cyber security from the standpoint of systems engineers. It introduces core principles for the design and management of resilient and robust systems throughout their complete lifecycle.

Topics include but are not limited to lifecycle assurance of systems, risk analysis, models for secure systems development and management, gap analysis, quantitative methods for cyber security, and special topics in cyber security.

The course also covers distinct technologies for assessing system vulnerabilities, measuring and modeling risk, reducing uncertainty in risk management, and others.

Target audience consists of engineers who want to expand their skill sets to better align with the demands of current cyber security jobs, as well as those who intent to work on cyber security research. Cyber security professionals would also benefit from the course by being exposed to a systems engineering, holistic perspective on cyber security design, development, and management.

Offered by Cyber Security Engineering. May not be repeated for credit. Equivalent to CYSE 787, SYST 687, SYST 787.

Registration Restrictions:
Enrollment limited to students with a class of Advanced to Candidacy, Graduate, Junior Plus, Non-Degree or Senior Plus.
Students in a Non-Degree Undergraduate degree may not enroll.

Schedule Type: Lecture

Grading:
This course is graded on the Graduate Regular scale.

Media Release & Creative Commons Consent Form

See Dr. Barreto for release form to sign. Below is a copy of the form’s contents.

Project/Course Name: CYSE 587/SYST 687 Cyber Security System Engineering

Instructor: Prof. Alexandre Barreto

Platform: ONAIR GMU Cyber Security Hub and related project sites

Consent for Recording, Public Distribution, and Licensing

By signing this document, I, ____________________________________________________, grant permission to Prof. Alexandre Barreto to record my voice and image during the project presentation for the above-mentioned course and agree to the following conditions:

1. Public Distribution: I authorize the publication of the recording and project materials on the ONAIR GMU Cyber Security Hub portal and any associated project websites for educational and academic showcase purposes.
2. Creative Commons Licensing: I acknowledge and agree that the project materials (presentation slides, documentation, and source code) will be released under a Creative Commons (CC BY-NC 4.0) license. This allows others to share and adapt the material for non-commercial purposes, provided appropriate credit is given to the original authors (the student team).
3. Rights to Image and Content: I authorize the use of my image, voice, and intellectual content presented during the session without expectation of remuneration or royalties.
4. Right to Revoke (Recording only): I understand that I may request the removal of my personal image/voice recording from the public platform by providing written notice to the instructor, should legitimate concerns regarding my privacy or safety arise. Note: Once materials are distributed under a Creative Commons license, items already shared by third parties may be outside the instructor’s control to remove.

Date: //2026 Signature: _________________________________________________

Contact

Email: School

Locations

Research Building at George Mason University’s Fairfax Campus
4400 University Drive, Fairfax, VA 22030-4444

Final Project Notebook

Course Number: CYSE-587 / SYST 687

Course Title: Cyber Security System Engineering

Instructor Name: Alexandre B Barreto (adebarro@gmu.edu) 

 GTA Name: TBD

Source:  CYSE 587 – Project Notebook Updated July 2026

What is the CYSE-587/SYST-687 Project?

The final project for CYSE 587/SYST 687 is a collaborative capstone experience designed to transform academic theory into a tangible, high-value solution. This is more than a standard assignment; it is an entrepreneurial journey that requires teams to navigate the complexities of real-world problem-solving.

At the start of the course, students will self-organize into teams of five to address a problem domain defined by the instructor. Your mission is not merely to provide a technical fix, but to innovate. Operating as a startup team, you will engage in a continuous cycle of experimentation, development, and iterative refinement.

Through this project, students will:

• Apply Systems Thinking: Integrate systems engineering principles to address modern challenges in cybersecurity, privacy, and system safety.
• Frame and Validate: Identify, frame, and justify a real-world problem before proposing a robust solution.
• Engineer with Constraints: Design secure systems that operate effectively within complex regulatory, organizational, and technical boundaries.
• Perform Rigorous Analysis: Conduct comprehensive threat modeling and risk reasoning grounded in verifiable system requirements.
• Ensure Holistic Integration: Embed security, privacy, governance, and assurance considerations directly into the architectural design.
• Master Technical Communication: Translate complex technical concepts into clear, actionable insights for both technical stakeholders and non-technical decision-makers.
• Defend Design Decisions: Justify engineering choices using evidence-based feasibility analysis, trade-off studies, and performance metrics.

Project Organization and Deliverables

At the conclusion of the course, students will participate in a Shark Tank–style seminar that synthesizes technical proficiency, cybersecurity systems engineering, and entrepreneurial thinking. Teams are expected to identify a critical real-world cybersecurity challenge, propose an innovative system-level solution, demonstrate technical feasibility, and present their work persuasively to an expert evaluation panel.

To ensure the development of a high-quality, defensible project, the semester is structured around three iterative milestones. These are not separate topics; each builds upon the previous submission by adding technical depth and refining the value narrative. By the final Shark Tank, teams are not introducing new arguments, but defending a mature project.

Detailed grading rubrics are available in the course syllabus; this section defines the requirements for each artifact set and the core Value Proposition Checkpoint for each phase.

Deliverable 1 (Week 5): Problem and Threat Foundation

• Artifacts: A system framing brief (ADOP boundary, stakeholders, mission) and an initial Value Proposition Canvas (Hypothesis). This is supported by an initial threat model applying generalized STRIDE, integrated with the AI/agentic trust boundary (MITRE ATLAS, OWASP LLM/ASI Top 10).

• Value Proposition Checkpoint: You must articulate your initial value hypothesis. This input serves as the foundation for your Cyber Security Canvas. The goal is to identify your primary stakeholder and the specific pain they face, and to test whether you are solving a genuine, high-stakes security gap or merely performing a technical exercise.

Deliverable 2 (Week 10): Risk-Justified Architecture

• Artifacts: The refined threat model from Deliverable 1, supplemented with contextual risk reasoning (addressing the limitations of CVE/CVSS and incorporating the NIST AI RMF) and a mitigating architecture explicitly traceable to the identified threats.

• Value Proposition Checkpoint: Your architecture must prove that it reduces the cost, liability, or operational risk identified in your initial hypothesis. Create a Cyber Security Canvas to demonstrate how your technical design explicitly maps to the identified threats as a “Gain Creator” and “Pain Reliever.” This is where technical credibility is tested against business feasibility.

Deliverable 3 (Week 13): Full Value Proposition Package

• Artifacts: The revised architecture from Deliverable 2, augmented with a privacy and governance layer, and a finalized Cyber Security Canvas.

• Value Proposition Checkpoint: Your Cyber Security Canvas must synthesize the cumulative technical work, threat intelligence, and risk justifications into a cohesive narrative. The project is now evaluated as a sophisticated engineering artifact with viable business logic. You must clearly define what pain is relieved, what gain is created, and for whom.

Shark Tank Final (Week 16): Value Proposition Demonstration

• Artifacts: No new technical content. The full package is polished into a high-stakes, live pitch accompanied by a functional Proof of Concept (PoC) demonstration.

• Value Proposition Checkpoint: Teams must defend the complete case live. You are expected to seamlessly integrate your technical assurance narrative with your business value proposition. The panel will evaluate your ability to answer rigorous inquiries that test both the robustness of your engineering design and the viability of your business rationale.

Publication, Discussion, and Distribution Channels

To ensure both the artifact record and the Shark discussion maintain a single, persistent home, each deliverable moves through these three channels in the following order:

• Canvas (Submission): This is the official channel for publishing course deliverables. For each submission, students must provide:
• A 10-minute pitch video: Once submitted, the instructor will transfer this to the Course YouTube Channel.
• Peer Evaluation: Refer to the course syllabus for detailed requirements.
• A link to the team’s OnAir Project Website/Post: See below.
• OnAir Cyber CYSE Hub (Persistent Record): Every team must maintain a single, evolving project post on the OnAir Cyber CYSE Hub. This post serves as the team’s persistent public record, containing the written artifacts: system framing brief, threat model, architecture diagram, risk memo, privacy documentation, and Value Proposition Canvas.
• Shark Engagement: This is where Sharks will review work and provide feedback between deliverables leading up to the live final defense.
• Course YouTube Channel (Integrated Media): Following the submission of the pitch video on Canvas, the instructor will publish it to the official Course YouTube Channel. Teams are then responsible for updating their OnAir Hub post with the provided YouTube link. This ensures each post remains a complete, citable, and unified record of the project stage, housing both written artifacts and video content in one location.

Observation: Students must sign the Media Release Form by Week 2.

Shark engagement is open throughout the project on a voluntary basis and becomes more structured as the project matures. For all prior deliverables, Sharks are invited but not required to engage. From Deliverable 1 onward, any Shark is welcome to follow a team’s work and leave feedback if their schedule allows, though the instructor and TA carry primary responsibility for review at this early stage. Teams are encouraged to treat any Shark engagement on Deliverables 1 through 3 as a valuable, if voluntary, preview of the scrutiny they will face at the live final defense, where the full Shark panel’s participation is required.

The Problem: Study, Agentic Development and Operations Platform Using MCP

Background

A mid-size technology organization operates an internal Agentic Development and Operations Platform (ADOP) built on the Model Context Protocol (MCP). The platform connects an AI agent host to a fixed set of official reference tool servers: Filesystem, Git, Fetch, and Memory, used by engineering teams to triage issues, draft patches, manage repository state, and retrieve external context in day-to-day software delivery.

In December 2025, three vulnerabilities were disclosed in Anthropic’s own reference Git MCP server, the canonical implementation most developers copy: an unrestricted git_init capability, a path validation bypass, and an argument injection flaw in git_diff (CVE-2025-68143, CVSS 8.8, and CVE-2025-68144, CVSS 8.1). These can be chained with the Filesystem server for remote code execution when the agent processes untrusted content, such as a malicious README or a poisoned issue description, without credentials or direct interaction with the target system. Despite ADOP’s operational maturity, trust and governance were addressed reactively, only after these disclosures prompted an internal review.

Engineering leadership has commissioned a Cybersecurity Systems Engineering review of the ADOP-based development workflow. You are part of the Agentic Systems Trust and Assurance Task Force.

To ensure both the artifact record and the Shark discussion maintain a single, persistent home, each deliverable moves through these three channels in the following order:

Mission and System Objectives

The mission of the ADOP-based system is to enable safe and efficient software delivery; support the autonomous execution of routine tasks without unchecked agency; maintain the integrity of source code and infrastructure state; and protect the confidentiality of data accessible through agent tool calls, in compliance with organizational policy. 

We can summarize the mission of the system in these items:

• Enable safe and efficient software delivery
• Provide engineers with reliable, agent-assisted tooling
• Support autonomous execution of routine tasks without unchecked agency
• Maintain the integrity of source code and infrastructure state
• Protect the confidentiality of internal data reachable through agent tool calls
• Comply with organizational security policy and, where relevant, regulatory obligations tied to the code and data the agent handles

This system is mission-relevant to engineering operations. Failures may result in:

• Unauthorized code execution or system compromise
• Corruption or loss of source code integrity
• Exposure of internal or customer data
• Cascading failures across CI/CD and downstream systems
• Loss of engineering trust in agent-assisted tooling

Agentic Development and Operations Platform (ADOP) Based on MCP

In this case study, the Agentic Development and Operations Platform (ADOP) is implemented using an MCP-compatible agent host as the core execution and reasoning layer. ADOP is a mission-relevant socio-technical system that integrates autonomous task execution, source code management, and external content retrieval to support software delivery.

Within ADOP, the agent host receives natural-language tasks, such as triaging an issue, applying a patch, or summarizing recent commits, and invokes the appropriate MCP servers to observe and modify the system state. These functions are implemented through tightly coupled subsystems: the Filesystem server, which exposes repository and workspace files; the Git server, which exposes version control operations; the Fetch server, which retrieves external content such as issue descriptions, documentation, or web pages; and the Memory server, which maintains cross-session persistent context.

In parallel, ADOP includes an Observability and Audit Layer that consumes tool-call telemetry to support monitoring, compliance, and incident response. This subsystem typically relies on a separate logging or audit store, optimized for retrospective analysis rather than real-time task execution.

The ADOP platform operates continuously in a high-autonomy, high-throughput operational environment characterized by frequent commits, mixed-trust external content, and increasing cyber threat activity targeting agentic tooling. Failures in the integrity, confidentiality, or scoped behavior of the agent can propagate beyond the development environment into production systems, leading to compromised code, data exposure, and erosion of engineering trust. Consequently, ADOP must be analyzed not merely as a software tool, but as a system-of-systems in which cybersecurity, provenance, human factors, and organizational processes are tightly interdependent.

High-Level System Description

The system is a socio-technical system of systems, not just a software application. At its core sits the agent host, which reasons over a task and issues tool calls; around it sit the four MCP reference servers, which execute those tool calls against real repository, filesystem, and external-content state; and around that sits the human engineering organization, which assigns tasks, reviews outputs, and is accountable for the consequences.

Figure 1 – System Architecture

Figure 2 – System Boundary

Technical Components

The Agentic Development and Operations Platform is centered on an MCP-compatible agent host that serves as the core reasoning and execution engine for engineering tasks across the organization. The host is deployed as a long-running process accessible to engineers, who interact with it to submit tasks such as issue triage, patch drafting, and documentation review.

At the core of the technical architecture is the Filesystem server, which exposes controlled, configurable access to repository and workspace files. This server is continuously invoked by the agent host during routine development tasks. Because of its central role, the workspace it exposes represents a high-value asset whose integrity and confidentiality are critical to safe software delivery.

The Git server regulates version control operations: status, diff, add, commit, branch, and checkout. In practice, this server must balance the agent’s need to act autonomously against the risk of unreviewed, irreversible changes to the source history, and it is the component in which the disclosed reference-implementation vulnerabilities described in the background section were found.

Beyond the core execution components, the system exposes a Fetch server that retrieves external content, issue descriptions, documentation pages, or web resources, and returns it to the agent as context. This interface is commonly the origin point of indirect prompt injection, since content retrieved from an untrusted source is treated by the agent as ordinary context rather than as potentially adversarial instruction.

The Memory server constitutes another critical interface. It maintains a persistent, cross-session knowledge graph that the agent consults and updates over time. Although memory persistence is essential for continuity across long-running engineering tasks, it also introduces a durable channel through which poisoned or manipulated content can influence the agent’s behavior well after the originating task has ended.

The system also supports an Observability and Audit Layer that records tool-call telemetry: which tool was invoked, with what arguments, against what target, and with what result. These logs are essential for accountability and incident response, but in practice are often generated without systematic review, creating a gap between logging and effective risk management.

Finally, ADOP connects to the organization’s CI/CD pipeline as a downstream integration boundary. Code and configuration changes produced or approved through agent-assisted workflows eventually flow into automated build, test, and deployment systems. In the architecture described, this boundary is where agent-introduced risk can propagate from a development context into production infrastructure, expanding the system’s attack surface and trust assumptions.

Together, these components form a tightly coupled, operationally significant technical ecosystem in which failures or misuse at any interface can rapidly propagate, compromising code integrity, undermining data confidentiality, and causing organizational harm.

Human and Organizational Actors

ADOP is used by several actors with different incentives and constraints:

• Software engineers: primary users, submit tasks and review agent output, often under delivery pressure that limits scrutiny
• DevOps and SRE staff: depend on the integrity of agent-modified configuration and deployment artifacts
• Security and compliance staff: review tool-call logs and enforce policy without interrupting engineering velocity
• Engineering leadership: oversees adoption indirectly, through dashboards and reports rather than direct use
• External parties: customers, open-source contributors, and vendors are not direct users, but their issues, pull requests, and documentation become the untrusted content the agent processes

Operational Environment

Organizations operating agentic development tooling like ADOP contend with:

• Continuous delivery, with frequent commits and deployments
• Mixed-trust content ingested through Fetch, internal documentation alongside external, potentially adversarial, content
• High autonomy expectations balanced against the need for safety and reviewability
• Uneven patch cadence across an organization’s fleet of agents
• A growing, publicly documented threat landscape specific to agentic tooling and MCP servers

Known Problems and Motivating Pains (Evidence-Based)

Publicly documented issues affecting MCP-based Agentic deployments include:

• The disclosed Git MCP server CVEs described above, chainable with the Filesystem server for remote code execution
• Indirect prompt injection through malicious README or issue content triggering unintended tool calls
• Goal hijacking, tool misuse, memory and context poisoning, and cascading agent failures, as documented in the OWASP Top 10 for Agentic Applications (2026)
• Excessive agency: agents taking actions beyond their assigned scope in production deployments
• Weak auditability and the absence of standardized human-in-the-loop gating for high-risk actions

These are documented in vendor advisories, independent security research, and frameworks such as OWASP and MITRE ATLAS, and are directly relevant to MCP-based Agentic deployments of the kind ADOP models.

Project Goal

The goal of the course project is to position students as cybersecurity systems engineers who design a standalone, externally deployable solution that improves security, trust, provenance, or governance in a real, agentic development environment. ADOP is a fixed, non-modifiable baseline: students may not alter the agent host’s core reasoning, the internal code of the MCP reference servers, or the underlying model. All solutions must interact with ADOP exclusively through approved external interfaces, tool-call and action logs, Git history and diffs, filesystem change logs, Fetch retrieval records, and any exposed audit trail.

Each team proposes and implements a Proof of Concept for one Student-Developed Agent Trust and Assurance Tool that observes ADOP from outside its boundary and turns that observation into decision-support or governance output, a risk indicator, an alert, a provenance score, a gating recommendation, for a real stakeholder. The tool must not directly alter agent behavior; it enables better oversight.

This is a cybersecurity systems engineering project, but it is graded as a value proposition rather than solely as an engineering artifact. Every deliverable must answer two questions together, not separately: what risk does this address, and why would a real stakeholder, an engineering leader, a compliance function, or an investor value this enough to adopt or fund it? 

Canonical Project Examples (Reference Solutions)

Teams may choose one of the following directly or propose an alternative of comparable scope and rigor, subject to instructor approval. Both examples assume ADOP is treated as a fixed baseline and is not modified.

Example 1: Agent Action Risk and Excessive Agency Monitoring Tool

This tool monitors ADOP’s tool-call logs and Git history to detect excessive agency, goal hijacking, and anomalous action sequences, for example, a fetch immediately followed by a file write and a commit. It scores risk against the OWASP Top 10 for Agentic Applications and produces ranked alerts and behavioral baselines for a security or engineering lead, without blocking or altering agent behavior. The value case: fewer unreviewed, high-risk agent actions reaching production and a defensible audit trail that an organization can show to a customer or a regulator.

Example 2: Tool Output Provenance and Injection Risk Governance Tool

This tool consumes Fetch retrieval records along with Git and Filesystem logs to assess whether an action was plausibly triggered by untrusted external content, scores provenance, and flags high-risk actions, such as a commit immediately following a fetch from an unfamiliar source, for human review before they are finalized. The value case: a defensible, auditable gate against indirect prompt injection, the exact failure pattern behind the disclosed Git MCP CVEs, without slowing down the majority of low-risk agent activity.

Non-Examples (Out of Scope Projects)

The following are explicitly out of scope and will be rejected:

• Modifying the agent host’s core reasoning or the internal implementation of any MCP reference server, including patching the disclosed Git server vulnerabilities directly

• Building a replacement agent host or a parallel agentic framework
• Purely analytical projects with no working Proof of Concept consuming real ADOP-derived data
• Solutions assuming unrealistic access, such as administrative control of the agent host or the ability to alter model weights
• Generic dashboards or visualizations with no substantive trust, provenance, or risk reasoning behind them

Scope, Creativity, and Innovation Guidance

The canonical examples calibrate scope and rigor; they do not constrain creativity. Teams may propose any trust, provenance, or governance tool not listed above, provided it addresses a clearly articulated, evidence-based pain point, integrates only through approved external interfaces, and produces a decision-support or governance output a real stakeholder could act on. Originality, depth of reasoning, and clarity of value proposition are rewarded, particularly when grounded in real incidents or industry frameworks.

Innovation here does not mean a larger system; it means engineering insight, an overlooked risk, a challenged trust assumption, a better way to support human decision-making. The course project is not a competition to reproduce known solutions. Thoughtful, well-justified departures from the examples are encouraged, provided they remain realistic and respect ADOP’s architectural boundary

Additional Information

The course provides a frozen ADOP testbed: functionally representative of a real deployment, operationally plausible in its tasks, and intentionally incomplete in its trust and governance engineering. It is neither a toy system nor a full enterprise platform.

The testbed provides a documented ADOP architecture on the official MCP reference servers pinned to specific versions, a synthetic repository with realistic commit history, a fixed set of synthetic engineering tasks, a frozen set of recorded tool-call and action logs (clean runs and deliberately poisoned scenarios reproducing the indirect prompt injection pattern behind the Git MCP CVEs), and documented trust assumptions.

Students may analyze the frozen logs and repository state, identify risks and failure modes, and build external tools against that data. They may optionally run their own harness against the live reference servers for their own PoC demo, provided ADOP’s core is never modified.

Teams

Team A

..

Team B

..

Team C

…

Team D

…

Evaluations

Shark Panel Email

Dear Sharks,
Thank you for committing your time and expertise to evaluating our Cybersecurity Systems Engineering capstone projects. Your participation is vital in bridging the gap between academic theory and high-stakes professional practice.
The Goal of the Event: The Shark Tank–style seminar is the final deliverable for our graduate students. The goal is for each team to present a professional project pitch that justifies their architectural decisions, defends their threat modeling, and articulates the value of their solution within a real-world Hospital Information System (OpenEMR). This event simulates a real-world environment in which engineers must defend their technical reasoning to senior stakeholders and decision-makers under time constraints.
How it Works

• Format: Each team has 20 minutes for their presentation and a working proof-of-concept demonstration.
• Time: 04:30 pm – 7:30 pm (EST – DC Time)
• Participation: To accommodate different schedules and locations, you may participate either in person at our campus or online via the provided link.
  • In person: Nguyen Engineering Building 1103 (GMU – Fairfax Campus)
  • Online: https://gmu.zoom.us/j/99002964828?pwd=svZxUSOF0Xo45KWeM3Y7Qm5aqcFJif.1&from=addon
• The Technical Investor Mindset: We ask that you adopt the role of a “technical investor.” While students need to be persuasive, your focus is on technical soundness, system-level reasoning, and the management of cybersecurity, trust, and governance risks. Despite the students being engineers, they were forced to adopt an Entrepreneur Mindset.

The Cybersecurity Canvas vs. Market Investigation: It is important to note that this “Shark Tank” differs from traditional business competitions. We are using the Cybersecurity Canvas (attached) framework rather than a standard business model.

• Not a Market Study: We are not evaluating market size, profit margins, or traditional “market investigation.”
• Problem Framing: The focus is on evidence-based security, privacy, and trust-related problems.
• Value Proposition: In this context, “Value” refers to risk reduction, harm prevention, and the improvement of decision-making and trust for specific healthcare stakeholders. We are looking into how the system manages the “pains” of cyber threats and operational failures.

Evaluation and Feedback: We have encouraged our students to prepare for rigorous, candid evaluations. Do not hesitate to be direct; these “crude” or blunt critiques are often the most valuable for engineering growth. The objective is to challenge their assumptions, expose gaps in their threat reasoning, and push them to refine their ideas as they move toward professional practice.
Attached you will find the evaluation rubric (Appendix 2), which covers:

1. Problem Framing & Market Pain (from a security perspective)
2. Value Proposition & Pitch Persuasiveness
3. Technical Feasibility & Architecture
4. Cybersecurity & Privacy Effectiveness
5. Threat & Risk Reasoning
6. Proof of Concept Demo
7. Professionalism

Finally, in the attachment, you can find the abstract of each group that will present the work during the event.
We look forward to your insights and to a session of robust technical exchange.
Best regards,

Prof. Alexandre Barreto, Ph.D.

Canvas Business Template

<img class=”alignnone size-full wp-image-8220″ src=”http://gmucyber.onair.cc/files/2026/01/Cyber-Canvas-.jpg” alt=”” width=”1280″ height=”720″ />

Shark Tank Panelist Performance Evaluation

…

Shark Profiles

…

DMV Cybersecurity Venture Capital

….