Technical methods and scope

Where the Controls Belong in an AI Deployment

We review controls across the model, application, identity, data and tool boundaries. Segmentation and outbound network restrictions limit where the inference service may connect. At the inference gateway we review authentication, authorization, rate limits and logging against the sensitivity of the application and the access its users hold. Input and output checks add a policy layer, and we look at how the layers behave together rather than how each one reads in a vendor brochure.

For an AI application shared by several customer organizations, we design the controls that keep each organization's data, prompts and conversation history apart, including vector database namespaces, session boundaries and the permissions on user interfaces and administrative APIs. Where external AI APIs process organizational data, we set out the data handling implications and design controls that reduce the exposure, and where regulatory requirements apply we map retention, processing and deletion controls to the obligations your advisers have identified.

LLM Governance and Accountability

Governance for large language model systems defines who approves a deployment, who owns its security decisions, how production behavior is watched and how issues are escalated. Clear ownership of each new tool, prompt and data connection is what lets a change be reviewed before its exposure goes unmanaged, and we connect those responsibilities to role permissions, audit records and the controls that detect unauthorized disclosure through the AI interface.

Monitoring needs enough conversation context to examine suspicious behavior without building a needless store of sensitive information, so we design visibility around your evidence and retention needs. A system prompt is versioned behavioral guidance, not an authorization boundary; identity, permissions, secrets and approval for consequential actions belong in application controls outside the model, because the prompt is the part an attacker will try to talk past.

Call (800) 868-8189 or request a scoping call to plan the work around your operations.

AI Risk Assessment and Threat Modeling

We adapt established threat modeling to the AI environment, treating training pipelines, model weights, inference services, prompting interfaces and external data sources as attack surfaces in their own right. For each component from ingestion to output we identify the assets, the credible threats from unauthenticated users, authenticated users, privileged operators, insiders and supply chain actors, and the controls already in place.

The scenarios follow your deployment. A legal research assistant faces attempts to extract privileged content or instructions hidden inside filed documents; a customer service assistant faces account takeover through AI assisted social engineering or attempts to trigger an unauthorized refund. You receive prioritized threat scenarios, attack paths from initial access to impact and the control gaps that need closing.

Secure Retrieval and RAG Architecture

Retrieval augmented generation connects an AI application to knowledge bases, customer data or document repositories. The central question is whether retrieval preserves the access rules that govern those documents or quietly routes around them, because an index that ignores permissions is a data exposure waiting for the right question.

We review access at the namespace and document level, separation between organizations in a shared deployment and the links between stored embeddings and their source documents, and we examine the relevant poisoning scenarios. Retrieved content is treated as untrusted, so ingestion checks, source controls, constrained retrieval, authorization enforced outside the model, tool limits and monitored output handling are designed as layers that back each other up.

Tell us which systems matter most and we will sequence the testing around them.

AI Supply Chain Security

The AI supply chain can include base model providers, fine tuning infrastructure, embedding providers, vector databases, orchestration frameworks, plugins and integrations, and a compromise in any one of them can reach the system around it. We compare model weight hashes with the provider's identified artifact to confirm the files are the ones specified, and we assess provenance claims and model documentation as a separate question.

For sensitive fine tuning we review data minimization, access control, privacy techniques and leakage testing. For external models and plugins we review the vendor's security documentation, test the relevant behavior and explain what their data handling means inside your environment, so procurement decisions rest on findings rather than a questionnaire. For background, see the OWASP Top 10 for LLM Applications entry LLM03:2025 Supply Chain, NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations and our cybersecurity and forensics glossary.