All articlesPortfolio · Blog section
Data security and AI agents
Security & AI

AI agents and data leakage: securing prompts, tools, RAG and automated actions

An AI agent can read, combine and transmit data from multiple systems. Without guardrails, data leakage becomes an architectural risk.

Aug 28, 20263 min read
AI AgentsSecurityData LeakageRAGOAuth2Zero Trust
01

Why agents increase the attack surface

A classic chatbot receives a message and generates a response. An AI agent may also call APIs, read files, query databases, send email or trigger actions.

This turns a prompt mistake into a real operational risk. The problem is no longer only a wrong answer, but unauthorized data access or transmission.

Security must therefore be designed at the tool, permission and data layers, not only in the system prompt.

02

Prompt injection can cause data leakage

External content can contain instructions designed to manipulate the agent: a document, email, web page, support ticket or RAG result.

If the agent treats these instructions as trusted, it may reveal information, use an unintended tool or deviate from the requested task.

All retrieved content should be considered untrusted, system instructions must remain separate from data, and available tools should be strictly limited.

03

Apply least privilege to agent tools

An agent that only needs to read order status does not need generic write access to the entire database.

Each tool should expose one precise business operation with limited parameters, server-side authorization checks and validation.

Credentials used by the agent should have fewer privileges than a human administrator, never more.

04

Prevent cross-tenant leakage in RAG

In a multi-tenant SaaS, organization filtering must be applied before vector retrieval, not after documents have already been fetched.

Semantic similarity must never be enough to make a document accessible. Business authorization always takes precedence over similarity.

Tests should include cross-tenant leakage scenarios because a filtering bug can expose data without producing any technical exception.

05

Do not send secrets to the model

OAuth tokens, API keys, passwords, connection strings and technical secrets should never be placed in model context.

Tools should use their own server-side credentials and return only the business result needed.

When an agent acts on behalf of a user, delegated and time-limited authorization is preferable to directly exposing a secret.

06

Log without recreating the leak in logs

Logs are essential for understanding agent behavior, but they can become a leakage source if every prompt and response is stored in clear text.

Prefer correlation IDs, metadata, decisions, tool names and statuses, with masking of personal or sensitive information.

Logs that genuinely need content should use short retention periods and stronger access controls.

07

Put a human in the loop for sensitive actions

Data deletion, financial transfer, permission changes, bulk sending or disclosure of sensitive documents should not be executed automatically based solely on model output.

The agent can prepare the action, explain what it will do and request explicit confirmation before execution.

This validation significantly reduces the impact of hallucinations, prompt injection or bad context.