Security

Enterprise AI Security

The attack surface AI adds to a large organization, and what to do about it. Shadow AI detection, prompt injection, data exfiltration through output, and the retrieval defect that passes every functional test.

Most AI security guidance is written for the model. The exposure in a large organization is rarely the model itself. It is the plumbing around it: what the system can read, what it is permitted to do, and which content it treats as instruction.

The material here covers the failures that actually show up at review, starting with the two that are hardest to detect: retrieval that ignores permissions, and unsanctioned tool use that never appears in any inventory.

Common questions

What new attack surface does AI actually add?

Four things that did not exist before: untrusted content reaching a system that acts on instructions, retrieval systems that can surface documents the requester was never entitled to read, model output flowing into tools with real permissions, and staff routing sensitive material into services you have no contract with. Everything else is a variation on one of those.

What is prompt injection and why is it hard to fix?

Prompt injection is when content the system reads, a retrieved document, a web page, an email, contains text that the model treats as instruction rather than data. It is hard to fix because there is no reliable separator between instruction and data inside a prompt. The durable mitigations are architectural: treat all retrieved content as untrusted, validate output before anything acts on it, and limit what the system is permitted to do.

How do we stop employees leaking data into AI tools?

Blocking alone tends to push usage onto personal devices where you have no visibility. The pattern that works is to provide a sanctioned tool genuinely good enough for the work people were doing, publish a clear acceptable use policy, and then restrict the unsanctioned paths, in that order.

What is the most common serious defect in enterprise AI systems?

Retrieval that ignores the requesting user's permissions. An index built by a service account with broad read access, queried without reapplying access control, will surface material the user could not otherwise open. It returns correct, relevant, well-grounded answers, so functional testing does not catch it.

Who should run AI security review, and when?

Security, at design stage rather than at the final gate. The threat model should be written while the architecture is still changeable. Adversarial testing should be performed by someone other than the team that built the system, and repeated after any change to indexing, permissions or tool access.

Do we need a separate AI incident response process?

No, an addendum to the existing one is usually right. What needs adding is how an AI-specific incident is recognised in the first place, since a model surfacing restricted content or acting on injected instructions does not look like a conventional alert, and often produces no alert at all.

Want a second opinion on your own position?

We work with large organizations on private AI deployment, strategy, and governance. If you have a decision in front of you, that conversation is available.

Get in touch