Large language models introduce a class of security problems that traditional application security playbooks do not cover. The most important of these is prompt injection: because an LLM cannot fundamentally distinguish instructions from data, any text it reads — a customer email, a retrieved document, a web page — can attempt to redirect its behavior. In the financial sector, where our systems touch account data and payment workflows, this is not a theoretical concern.
Our first principle is to treat every model output as untrusted input to the rest of the system. The model never holds credentials, never composes raw database queries, and never triggers side effects directly. Instead it produces structured requests that are validated against an allowlist of operations, with hard authorization checks enforced outside the model boundary — the same way you would treat input from an unauthenticated user.
The second principle is strict data isolation between tenants. Retrieval indexes are partitioned per client, with row-level security enforced at the database layer rather than in prompt logic, so a compromised or manipulated prompt cannot widen its own access. Context assembled for one user's session is never cached into another's, and audit logs record exactly which documents entered each model call.
Finally, we red-team continuously. Injection payloads are added to our regression suites the moment they are discovered, and every release is tested against them. LLM security is not a feature you ship once — it is an operating posture. The teams that internalize this early are the ones that will earn the right to deploy AI in genuinely sensitive domains.
Back to all articles