Technical field guide
The sections below preserve the service-specific depth behind AI Security Architecture, edited for the current national practice and its documented engagement model. Methods are selected for the source, authorization, system state and assigned specialty. No single tool or artifact establishes a conclusion, and legal, regulatory or certification decisions remain with the responsible authority.
Secure AI Deployment Architecture
The architecture decisions made when deploying an AI system determine its attack surface for the entire deployment lifecycle. Organizations that deploy LLMs without a security architecture review routinely introduce vulnerabilities that are far more difficult to remediate after deployment than before: overprivileged service accounts, unsegmented model inference endpoints, system prompts that can be extracted through standard API access, and tool integrations that allow an injected model to reach production data stores.
An AI architecture review addresses security controls across the model, application, identity, data and tool boundaries. Model isolation ensures that inference compute runs in an appropriately segmented environment, with network controls that prevent the inference service from making unauthorized outbound connections. API gateway security wraps the model inference endpoint with authentication, authorization, rate limiting, and logging controls appropriate to the sensitivity of the application and the trust level of its users. Input and output filtering layers validate incoming requests and outgoing responses against policy rules, providing a defense-in-depth layer between the raw model and its users.
For multi-tenant AI deployments, GDF assesses and designs the tenant isolation controls that prevent one organization's data, prompts, and conversation history from being accessible to another. This includes namespace isolation in vector databases, session management controls that enforce context boundaries, and access control models that apply to both user-facing interfaces and administrative APIs. In environments where the AI system processes data subject to regulatory requirements, GDF designs the data handling architecture to ensure that sensitive data is retained, processed, and deleted in accordance with applicable requirements.
GDF also assesses the network architecture surrounding AI deployments: the placement of inference services relative to corporate networks and the public internet, the controls on traffic between AI components (retrieval services, tool APIs, orchestration layers), and the monitoring and logging infrastructure needed to detect and respond to security events. For organizations using third-party AI APIs, GDF reviews the security implications of sending organizational data to external inference endpoints and designs controls to minimize exposure.
LLM Governance Frameworks
A governance framework for enterprise LLM deployment defines the policies, processes, and accountability structures that determine how AI systems are approved for use, how they are monitored in production, and how security and safety issues are identified and addressed. Without a governance framework, enterprise AI deployments accumulate risk at the speed of adoption: new tools, prompts and data connections can introduce unmanaged exposure when ownership and security review are unclear.
GDF's LLM governance framework work addresses the organizational and technical dimensions of governance together. On the organizational side, this includes defining roles and responsibilities for AI system security, establishing a review and approval process for new AI deployments and significant changes to existing ones, and creating escalation paths for security findings and incidents. On the technical side, this includes access control design that enforces role-based permissions on AI system capabilities, audit logging that captures the information needed for security review and incident response, and data loss prevention controls that detect and prevent unauthorized disclosure of sensitive information through AI interfaces.
Monitoring and observability are critical governance components that many organizations underinvest in for AI systems. Unlike conventional application logs, which capture discrete transactions with defined inputs and outputs, LLM application logs must capture enough conversation context to support security analysis without themselves becoming a data liability. GDF designs monitoring architectures that give security teams visibility into model behavior, prompt patterns, and anomalous usage without requiring storage of full conversation histories containing sensitive user data.
System prompt management is a governance challenge that receives insufficient attention in most enterprise AI programs. System prompts are effectively security policy documents: they define what the model will and will not do, what data it will access, and how it will respond to adversarial inputs. GDF establishes version control, review, and approval processes for system prompt management, treating system prompts with the same rigor applied to security policy documentation.
AI Risk Assessment and Threat Modeling
GDF's AI risk assessment and threat modeling methodology adapts established threat modeling frameworks (STRIDE, PASTA, attack tree analysis) for the specific characteristics of AI systems. A conventional threat model identifies code components, data flows, and trust boundaries. An AI threat model should also address the model itself as an attack surface: the training data pipeline, the model weights, the inference environment, the prompting interface, and every external data source the model consumes.
The threat modeling process begins with architectural decomposition: mapping every component in the AI system from data ingestion through inference to output delivery. For each component, GDF identifies the assets it holds or processes, the threats applicable to it, and the existing controls that address those threats. The output is a prioritized list of threat scenarios with associated risk ratings, attack path analysis showing how an adversary could move from initial access to the target impact, and control gap analysis identifying where existing controls are absent or insufficient.
Attack surface mapping for LLM applications covers the interfaces through which adversaries can interact with the system: the user-facing prompt interface, any document or data upload capabilities, API endpoints, model management interfaces, training data pipelines, and any external integrations the model uses. For each interface, GDF identifies the threat actors who can access it (unauthenticated users, authenticated users, privileged operators, insiders, supply chain actors), the attacks they could mount, and the impact if those attacks succeed.
GDF's AI threat models include specific adversarial scenarios relevant to the client's deployment context, rather than generic risk categories. For a legal research AI with access to privileged documents, the relevant scenarios include attempts by opposing counsel to extract privileged content, insider extraction by departing employees, and injection attacks through documents filed in litigation. For a customer service AI with access to account data, the relevant scenarios include account takeover facilitated by AI-assisted social engineering, data extraction by competitors, and manipulation of the AI to authorize unauthorized transactions. This specificity makes threat models actionable rather than theoretical.
Secure RAG Implementation
Retrieval-augmented generation has become the standard architecture for enterprise AI applications that need to draw on organizational knowledge bases, customer data, or document repositories. The security of a RAG implementation determines whether the AI system enforces the same access controls as the underlying data systems, or whether it creates a new pathway to access data that bypasses those controls entirely.
GDF's secure RAG architecture addresses security at each stage of the retrieval pipeline. Vector database security covers access control at the namespace level, ensuring that each user or user group can only retrieve embeddings from documents they are authorized to access. For multi-tenant deployments, this requires namespace isolation controls that prevent cross-tenant retrieval, verified through testing of the kind GDF conducts in its AI security testing engagements. Embedding integrity controls verify that the vector representations stored in the database correspond to the documents they claim to represent, detecting embedding poisoning attacks that could cause the retrieval system to return manipulated content.
The document ingestion pipeline requires security controls at the intake stage. Documents submitted for indexing may contain malicious instructions designed to influence the model when those documents are later retrieved, an attack known as indirect prompt injection through the retrieval layer. GDF designs ingestion pipelines with sanitization controls that identify and neutralize injection attempts before documents are indexed. For high-sensitivity document repositories, GDF recommends human review workflows for documents originating from untrusted sources before they enter the retrieval index.
Retrieval controls define what the model does with retrieved context: whether retrieved documents are presented to the user alongside AI responses, whether the model is constrained to answer only from retrieved context, and how conflicts between retrieval results and the model's training are handled. GDF designs these controls to minimize the attack surface of the retrieval interface while maintaining application utility.
AI Supply Chain Security
Enterprise AI deployments depend on a supply chain that includes base model providers, fine-tuning infrastructure, embedding model providers, vector database vendors, orchestration frameworks, and a growing range of AI plugins and integrations. Each component in this supply chain represents a potential point of compromise that could affect the security of the entire AI system.
Model provenance is the foundational supply chain security control: verifying that the model weights used in production are the weights that the provider published, have not been modified in transit or storage, and were trained on data consistent with the provider's claims. GDF establishes provenance verification processes for enterprise AI deployments, including cryptographic hash verification of model weights, review of model cards and training documentation, and evaluation of provider security practices for organizations deploying models from external sources.
Fine-tuning security addresses the risk that adversaries could influence an organization's fine-tuning process to introduce backdoors or biases into customized models. GDF reviews fine-tuning data pipelines for integrity controls, assesses whether training data sources are adequately vetted, and evaluates the access controls on fine-tuning infrastructure. For organizations that fine-tune models on sensitive data, GDF designs data handling controls that prevent training data from being extractable through the fine-tuned model.
Third-party model and plugin evaluation is a supply chain security requirement that organizations with mature AI programs conduct before deploying any externally developed AI component. GDF's evaluation process assesses the security documentation published by the vendor, tests the component's behavior against relevant security scenarios, and evaluates the data handling implications of integrating the component into the organization's AI environment. This evaluation produces a risk-rated finding set that supports procurement and integration decisions.