Securing AI Agents: Prompt Injection, Data Access, and Permissions

A chatbot that gives a wrong answer is embarrassing. An agent with write access to your email, billing, and documents that gets manipulated is a breach. The moment your AI can act, security stops being a nice-to-have.

Here is how we secure production agents — the threats that actually matter and the controls that actually work.

The Threat Model

Prompt Injection: Assume It Will Happen

Any agent that reads external content — emails, documents, chat messages — will eventually read content written by someone trying to manipulate it. You cannot prompt your way out of this. Our working rules:

1. Treat retrieved content as data, never as instructions. System prompts explicitly mark external content boundaries, and the agent is instructed to flag — not follow — embedded commands.
2. No high-risk action executes from a single input. An email cannot directly trigger "send" or "pay". It can only create a proposal in the approval queue, where a human sees exactly what would happen and why.
3. Log the provenance. Every proposed action records which source content triggered it. When something looks odd, the reviewer sees the original text.

The approval queue is not just a UX pattern — it is your injection firewall. A manipulated model produces a suspicious proposal, not a completed attack.

Identity: The Shared API Key Trap

The most common real-world failure we see is not exotic at all: every user hits the agent through one shared API key, so the backend cannot tell users apart. Everyone sees the same threads, the same data, the same permissions.

The fix is boring and essential:

• Identity comes from the authenticated session (e.g. Supabase auth), not from a static key
• Every request carries the user's identity; every query filters by it
• Private threads, starred items, and history are scoped per user at the API layer, not the UI layer
• Admin impersonation is an explicit, logged mode — never the default

Least Privilege for Connectors

Each of our 9 source connectors gets the narrowest scope the actions require. Reading tasks does not need delete rights. Drafting emails does not need send rights — the send happens after approval, through a separate, audited path. When a connector is compromised or misbehaves, the blast radius is one system, one scope.

Defense in Depth: The Full Stack

1. Input layer: content/instruction separation, source tagging
2. Routing layer: anti-patterns that refuse dangerous matches, confidence thresholds
3. Action layer: risk tiers — read-only executes, high-risk queues for approval
4. Identity layer: per-user scoping on every query
5. Audit layer: immutable log of every action, approval, and revert

No single layer is trustworthy. Together, they mean a successful manipulation has to beat five independent controls — and even then, it leaves a trail.

The Checklist

• Can any external content trigger an irreversible action without a human? (Must be no)
• Can two users see each other's data by design or by accident? (Test it)
• Does every connector token have the minimum scope? (Review quarterly)
• Can you reconstruct, for any action, what triggered it and who approved it? (Audit trail)
• Do you log rejected proposals? (They are your early-warning system)

Agents are worth securing precisely because they are worth using. The teams that get this right are the ones that treat the agent like a new employee: real access, real accountability, and no blank checks.