Solution

AI Security

Threat modeling, security architecture, and adversarial testing for AI systems — designed in from week one, not reviewed at the end.

The problem

AI systems break the assumptions application security is built on.

Behavior is non-deterministic. The trust boundary moves — untrusted content becomes instruction. The system reads across data it was never intended to aggregate, and agents take actions with real consequences. Traditional review has no vocabulary for any of it.

We build the security architecture alongside the system, and we produce the artifacts your security organization needs in order to say yes: a threat model, a documented data flow, a control mapping, adversarial test results, and audit evidence.

Determinism is gone

The same input can produce different output. Test cases that pass once are not guarantees, so assurance has to be statistical and continuous rather than a one-time gate.

Data becomes instruction

Content retrieved from a document, an email, or an API response is interpreted by the model. Anything the system reads is a potential instruction from whoever wrote it.

Aggregation changes exposure

A retrieval system can synthesize across documents a user was never meant to see together, producing disclosure that no single document permission would have allowed.

Agency creates blast radius

An agent with tool access can send, delete, transact, or escalate. The security question stops being about data and starts being about authority.

Trust boundary

Everything the model reads is untrusted input

AI system trust boundary and control points User prompts, retrieved content, and tool output all sit inside an untrusted input zone. They pass through an entitlement check before reaching the model. Model output passes through a tool-call gate enforcing least privilege before any tool runs, and consequential actions require human approval. UNTRUSTED INPUT ZONE User prompt may be adversarial Retrieved content indirect injection vector Tool / API output attacker-influenced Entitlement check per user, per doc Model non-deterministic Tool-call gate least privilege allow-list, scoped Human approval consequential actions only Every gate is logged as audit evidence
Control points in an enterprise AI system. Entitlement enforcement happens at query time, not at index time. Tool access is scoped and allow-listed. Consequential actions require approval.
Threat classes

What we test for

Prompt injection

Direct and indirect. Instructions embedded in retrieved documents, email bodies, web content, or tool responses that redirect the model's behavior.

Data exfiltration

Sensitive content leaving through generated output, tool parameters, rendered markdown, or outbound requests the model was induced to make.

Entitlement bypass

Retrieval returning content the requesting user has no right to read, through index-time permissioning, cache leakage, or aggregation across documents.

Excessive agency

Agents holding broader tool permissions than any single task requires, enabling an injected instruction to send, delete, transact, or escalate.

Supply chain

Model and dependency provenance, weight integrity, unverified fine-tunes, and the package ecosystem underneath the serving stack.

Insecure output handling

Model output rendered or executed downstream without treatment — HTML, SQL, shell, or code paths that trust generated text.

Training and fine-tuning leakage

Sensitive material memorized through fine-tuning or retained in caches, embeddings, or logs beyond the retention policy.

Denial of wallet

Cost-amplification attacks that drive inference spend or exhaust GPU capacity, degrading availability for legitimate users.

Index and model poisoning

Adversarial content introduced into the corpus or the retraining loop to influence future retrieval and generation.

Engagement

AI Security Review

A fixed-scope assessment of an existing or planned AI system.

  • Architecture and data flow review — what the system reads, what it can reach, and where content crosses a trust boundary.
  • Threat model with ranked findings — AI-specific classes, assessed against your deployment rather than in the abstract.
  • Control mapping — findings mapped to your existing framework, so remediation lands in a process your organization already runs.
  • Adversarial test report — reproduction steps for every finding, run against the deployed system rather than the model in isolation.
  • Remediation plan with sequencing — what to fix before production, what can follow, and what is an accepted risk.
  • Executive summary — written for a risk committee, not for engineers.

Governance alignment. We map controls and documentation to NIST AI RMF and ISO/IEC 42001, reference the OWASP Top 10 for LLM Applications for application-layer findings, and account for EU AI Act obligations where your deployment falls in scope.

Questions

Frequently asked

How do you handle prompt injection?

Architecturally, not by prompt engineering. Treat retrieved content as untrusted input, constrain tool access with least privilege, gate consequential actions, enforce entitlements at the retrieval layer, and test adversarially before release.

Defenses that live entirely in the system prompt are not defenses.

Our security team has already blocked one AI project. Can you help?

That is a common reason clients call us, and the security team is usually right. We start from their requirements rather than presenting to them at the end, and we produce the artifacts they need to evaluate the system on its actual risk.

Do you review systems you didn't build?

Yes. AI Security Reviews are a standalone engagement, and a significant share of them are on systems built by another firm or in-house.

How is this different from a penetration test?

A penetration test targets the application and infrastructure. An AI security review adds the model-specific layer: injection, entitlement bypass through retrieval, agency and tool abuse, output handling, and aggregation exposure.

They are complementary. Neither substitutes for the other.

Related

Private AI

Production AI systems that run entirely inside your infrastructure. No third-party data processor in the data path.

Private AI

Our Implementation Framework

Security architecture enters in phase 02, before development starts — and nothing reaches production without passing the gate.

The framework

Request an AI security review.

A fixed-scope assessment of your AI system against AI-specific threats, with reproduction steps, a control mapping, and a remediation plan your security organization can act on.

We will sign your NDA before a detailed technical discussion.