October is Cybersecurity Awareness Month, making it an important time to bring renewed attention to how organizations protect their systems and data. For aerospace software teams adopting artificial intelligence (AI), that conversation should extend beyond traditional cybersecurity concerns to a critical question: Who has access to the data those AI tools touch — and where does that data go?
This year’s Cybersecurity and Infrastructure Security Agency (CISA)-led theme, Securing the Next 250, points toward strengthening the country’s infrastructure for the long term, marking over 20 years of the campaign and looking ahead to the next 250 years of building a more secure digital foundation. That long-term thinking extends to AI: one of the priorities laid out for America’s next 250 years is leading the world in AI while ensuring it’s secure by design.
The aerospace and defense sectors are already moving in that direction —85% of aerospace and defense leaders are prioritizing it, according to a Xometry-commissioned survey released in February 2026, compared to 63% in general industry. But any use of AI that touches proprietary requirements, source code, or program data introduces a security surface of its own — one defined by who can access that data.
Federal Guidance on AI Data Security
In May 2025, the National Security Agency’s (NSA) AI Security Center, CISA, the Federal Bureau of Investigation (FBI), and cybersecurity authorities from Australia, New Zealand, and the UK jointly published a Cybersecurity Information Sheet (CSI) on securing the data used to train and operate AI systems. It was written primarily for Defense Industrial Bases, National Security System owners, federal agencies, and critical infrastructure operators.
The guidance centers on three risk areas: vulnerabilities in the data supply chain, maliciously modified or “poisoned” data, and data drift over a model’s lifecycle. Recommended mitigations include data encryption, digital signatures, data provenance tracking, secure storage, and operating within trusted infrastructure. One specific technical recommendation is to run AI workloads inside a trusted computing environment that leverages Zero Trust architecture, with secure enclaves for data processing.
In April 2026, CISA, NSA, and cybersecurity authorities from Australia, Canada, New Zealand, and the UK jointly published guidance on agentic AI systems, warning organizations against granting broad or unrestricted access to sensitive data or critical systems. The following month, NSA’s AI Security Center released security design considerations for the Model Context Protocol (MCP) — a standard that lets AI systems connect to external tools and data — warning that adoption has outpaced the protocol’s security model, and calling for treating every session as untrusted until verified, with access enforced on a least-privilege basis.
The Stakes on a DO-178C Program
DO-178C programs carry sensitivities that most software projects don’t, which raises the stakes on the risks outlined above. Program data is frequently controlled or export-restricted under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). The software is also developed to a system’s assigned Design Assurance Level (DAL) — the Federal Aviation Administration’s (FAA) five-tier classification (A through E) reflecting how a system failure could affect flight, from catastrophic to no safety effect.
The stakes remain the same whether the work is done in-house or by an outsourced DO-178C development supplier, and whether an artifact is produced with or without AI assistance.
As the FAA’s Roadmap for Artificial Intelligence Safety Assurance puts it, companies remain responsible for their products, their compliance, and demonstrating that compliance, regardless of how the underlying artifacts were created.
Controlling who can access the data behind those artifacts is a separate but related responsibility. Before adopting any AI tool on a certification program, engineering teams need to consider a few questions:
- Who has access to the tool, and is that access individually scoped or shared broadly?
- Can access be revoked when an engagement ends, or does it persist by default?
- Is there an auditable record of who accessed what, and when?
- Does the tool run in a trusted, Zero Trust-aligned environment, or does data leave your environment entirely?
Performance Software’s Approach: Engineer-Led, AI-Accelerated
Clients rely on Performance Software engineers to augment teams with certification expertise, specialized domain knowledge, and the capacity to meet critical program demands. To further increase efficiency, we selectively apply AI-assisted engineering — with program approval — to accelerate development of demanding safety-critical systems without compromising certification-level rigor.
Elevate™, Performance Software’s AI-assisted engineering platform for DO-178C programs, runs on zero-trust API access scoped to each engineer’s needs. Access is auditable, revocable at any time, and ends automatically when an engagement does, with a clear record of who had access to what and when.
That same principle governs our approach to AI-assisted engineering more broadly: AI is a tool engineers use, not an entity with independent access or accountability. Engineers remain responsible for outcomes, including how program data is accessed, protected, and used.
Available wherever it fits a program’s needs, Elevate™ is already helping engineers on real-world programs reduce manual effort, identify gaps earlier, and move faster while maintaining certification-level rigor.
See what Elevate™ can do for your program: https://www.psware.com/elevate-ai-engineering/
