Breaking the “Lethal Trifecta” for LLM Agents

By Keroshan Pillay

When a language model can see private data, read untrusted content, and send information to the outside world at the same time, you’ve assembled the “lethal trifecta.” This article shows how to defuse it in real products—especially in finance—by making safety an architectural property, not a prompt. To tackle this issue we must:

(1) frame the trifecta in practical, product terms;

(2) state two non-negotiable guarantees—single-scope user isolation and no uncurated egress;

(3) present a simple, repeatable pattern (server-side tools, cookie-derived sessions, RLS everywhere, and a deny-egress model runtime);

(4) walk through common attack paths and why they fail under this design

(5) offer a minimal adoption plan and explain why these controls matter for financial privacy, audits, and ship velocity.

Two guarantees, up front

1. Single-scope access — the agent can see only the current customer’s data, never anyone else’s.
2. No uncurated egress — nothing the agent sees can be broadcast to the world by default.

Emphasize the first; never forget the second. Together they keep an intelligent feature from becoming an intelligent breach.

The Two Guarantees, Stated Plainly

• User isolation. The system—not the prompt—decides who the agent is acting for. The model cannot select or impersonate another user. If a tool runs a query, it returns only the rows the current customer is entitled to see.
• Constrained sending. The model runtime has no “phone home” keys. Outbound actions (email, HTTP, uploads) happen only through narrow, audited server tools, with allowlisted destinations and explicit user confirmation.

Models don’t have identities; sessions do. Our model can read secrets, but it can’t send them anywhere.

Think in capability edges, not wishes

System safety isn’t achieved by pleading with a model to behave. It comes from removing capability edges the model could use to do harm.

• Delete the selector edge: the model never gets to pick an identity.
• Delete the egress edge: the model never gets to send.

Everything else is implementation detail.

The Pattern That Makes This Real

We’ve converged on a simple, repeatable pattern. It’s not specific to one stack; it’s a set of construction rules you can translate into your environment.

1) Server‑side tools only

The model may request a tool call, but only the server decides what actually runs. Tools are regular server functions with narrow, schema‑validated inputs. They live behind your API, not in the browser, and not inside the model’s runtime.

2) Identity is derived, not declared

Identity comes from a signed, short‑lived, httpOnly cookie turned into a server session. Every tool receives that session and does not accept userId, accountId, or any other selector. There is literally nowhere to smuggle “act as this other person.”

3) Row‑Level Security everywhere

All database access runs under Row‑Level Security (RLS) keyed by the current session. Even if someone forgets a filter or ships a sloppy query, the database itself enforces “only this user’s rows.”

4) Deny model egress; choreograph server egress

The model runtime has no network keys—no fetch, no sockets, no email, no uploads. If your product needs outbound actions, they happen in server tools that:

• send only to an allowlist of destinations,
• accept minimal, structured payloads,
• require explicit user confirmation for anything that leaves your boundary,
• emit audit logs and respect rate/budget limits.

5) Role‑scoped tool registries

Users, operators, and admins see different tool lists with different rules. Cross‑tenant analytics, if they exist at all, live behind an admin‑only tool with visible “acting as” context and a time‑boxed session.

6) Observe and budget

Safety should be visible: structured logs with component tags, correlation IDs for incidents, and per‑tool quotas. If something weird happens, it should be obvious.

What Could Go Wrong—And Why This Blocks It

• Prompt injection asks for another identity.“Run this as user 42.” Tools don’t accept identity fields; the session supplies identity; RLS enforces it. The instruction is a sentence, not a capability.
• Prompt injection asks to exfiltrate.“Email this ledger to X” or “POST to my server.” The model can’t send; there is no email/HTTP tool in its world. Server egress, if any, uses allowlists and requires explicit user action.
• Confused‑deputy analytics.“Summarize the top 100 users by balance.” A user‑scoped tool returns only their rows. Any cross‑tenant roll‑up sits behind an admin registry and a context switch that a human performs.
• Forgotten WHERE clause.A mis‑scoped query returns only the caller’s rows because RLS is the backstop. You get a correctness bug, not a privacy incident.
• Raw SQL or generic destinations.Tools don’t accept raw SQL or free‑form URLs. If a legacy code path sneaks in, RLS still gates data, and allowlists still gate destinations.

Bottom line: the exploit becomes a request without a route.

A Minimal Adoption Guide

You can get most of the benefit with a short, disciplined sequence of changes:

1. Move tools behind your server. The model asks; the server runs. Remove long‑lived tokens from the model and the browser.
2. Derive identity; purge selectors. Delete userId, accountId, “tenant,” and similar fields from every tool API. Read identity only from the server session.
3. Turn on RLS (or equivalent). Wrap every data client so RLS is always applied. Treat raw clients as a lint error.
4. Disable model egress. No outbound network from the model runtime. Period.
5. Re‑introduce necessary egress deliberately. Implement outbound actions as server tools with allowlists, small schemas, budgets, and user confirmation.
6. Split tool registries by role. End‑user vs. operator vs. admin. Different lists, different audits.
7. Add observability. Component‑tagged logs, correlation IDs, simple anomaly alerts (e.g., “tool X returned >N rows repeatedly”).

These steps don’t slow you down; they unblock shipping by removing the scary tails that stall approvals.

Why This Matters Specifically In Finance

Financial data is unusually sensitive:

• It’s longitudinal. Seemingly minor fields combine over time into rich profiles.
• It’s actionable. An account number, a pattern of deposits, a repayment schedule—these aren’t trivia.
• It’s regulated. Auditors don’t want vibes; they want guarantees they can verify.

The two guarantees give you a clean story:

• User isolation satisfies least‑privilege expectations: the agent can only do what this customer could do.
• No uncurated egress satisfies purpose limitation: nothing leaves by default, and anything that does is explicit, narrow, and auditable.

Equally important, this story is easy to explain to customers. “The AI can only see your data, and it can’t send anything without you” is the kind of sentence that earns trust.

What This Unlocks

• Confidence to use real data. You can safely point agents at statements, ledgers, and analytics for the current customer.
• Safer ingestion of messy inputs. Let the agent read PDFs, tickets, and web pages. Reading is low‑risk when identity is derived and sending is constrained.
• Repeatable governance. Security reviews collapse to a short checklist: derived identity, RLS everywhere, deny egress, allowlists for the few outbound paths, explicit user confirmation for mutations.
• Faster iteration. Safety becomes a platform property, not a bespoke policy per feature. Teams add tools without renegotiating fundamentals.

Closing

The “lethal trifecta” is a useful warning: private data + untrusted content + external communication is a dangerous mix. In fintech, the response is straightforward and strong enough to survive red‑teamers:

• Server‑side tools mediate all capability,
• Cookie‑derived sessions define identity,
• RLS everywhere enforces scope,
• Deny‑egress runtime keeps the model offline by default,
• Allowlisted, user‑confirmed outbound tools provide the few routes you actually need.

Simple rules, applied consistently. That’s what makes intelligent systems safe around money.