How to Use AI Agents Without Leaking Your Data

Researchers found live malware hidden inside a popular shared AI agent skill last month, and over a million API keys have been exposed through a pattern that most people still repeat every day. I am Madhuranjan Kumar, and the thing I want to establish first is that AI agents are worth the complexity they introduce, because the power is real. The security risks are also real, and they are manageable if you understand them before they find you rather than after.

Researchers found real malware hidden inside downloaded AI agent skills this month

Shared skill libraries for AI agents work like app stores for behavior: someone builds a skill, publishes it to a public repository, and others download and install it. The problem is that these repositories have no consistent vetting process, and the open-source nature of the skills makes it easy to include code that does something other than what the description promises.

The specific attack pattern found in the wild this month buried a payload inside a skill that appeared functional. It installed itself when the skill was activated, ran silently in the background, and began scanning the system for API keys and credential files. The users who installed it saw the skill working as expected while the payload was operating in parallel.

This is not a hypothetical concern. It has already happened, it happened recently, and it happened to people who were experienced enough to be using agentic AI tools but who downloaded skills without inspecting the code. The lesson is not to avoid skills or to abandon agent tools. It is to change how you source the skills you install.

The practical rule is this: build the skills you rely on yourself, or review the source code of any skill you download before running it. For the most common capabilities, a skill is often only a dozen lines of code, and reading twelve lines is not a significant burden. For skills you cannot or do not review, run them in an isolated environment where they cannot reach your credentials or your sensitive data, and observe their behavior before trusting them with production access.

Prompt injection is the attack method that most business owners have never heard of

An AI agent reads text and acts on it. That is its core value: it understands natural language and does what the language describes. The same property that makes it powerful is the vulnerability that prompt injection exploits. A malicious instruction embedded in a document the agent reads, a webpage it visits, or a shared file it processes can quietly instruct the agent to take an action the user never intended.

Concrete example: an agent is tasked with reading and summarizing customer emails. An attacker sends a carefully crafted email containing hidden text that, when the agent reads it, instructs the agent to forward the next ten emails it reads to an external address, then delete the forwarding rule from its memory. The agent follows the instruction because it cannot distinguish between the legitimate instruction from the user and the malicious instruction embedded in the email content. The user sees a summary of the malicious email like any other, and the forwarding runs invisibly.

This is not a theoretical attack. The fundamental architecture of instruction-following models makes them susceptible to it, and every lab researching AI security takes prompt injection seriously. The mitigation is to think carefully about what sources of text the agent can read and act on, to treat any external content, email, web pages, shared documents, uploaded files, as potentially hostile, and to build review steps at any point where the agent is about to take an action based on externally sourced content.

API keys typed into a chat window are already exposed before you close the tab

The most common source of credential exposure in AI tools is the simplest one: someone pastes an API key directly into a chat conversation to tell the assistant how to connect to a service. Chat conversations are logged. Those logs are stored on the provider's servers. If those servers are ever breached, if the account is accessed by someone else, or if the logs are retained and used in ways the user did not anticipate, the key is compromised.

Over a million API keys have been exposed through this pattern, according to research published earlier this year. The damage ranges from minor, a key that is quickly rotated before meaningful use, to severe, a key with broad permissions that was used to run up charges or access sensitive data before the breach was discovered.

The correct place for an API key is a protected configuration file that the application reads at startup. The file should have permissions that prevent other users on the system from reading it, and it should never be included in any version-controlled code repository. The application reads the key from the file when it needs to make an API call, and the key itself never appears in any conversation, any log, or any code that leaves the protected file.

For businesses using CRM and web infrastructure that connects to various APIs, the same principle applies to every credential in the stack. Database connection strings, service account keys, webhook secrets, none of these belong in chat logs, email threads, or code repositories. They belong in protected configuration files or in a secrets management service designed for exactly this purpose.

Limiting access is more reliable than trusting the model's judgment about what to do

The most effective mitigation for every category of risk described above is the same: give the agent the smallest possible set of permissions it needs to do the task you assigned it, and nothing more. This principle, called least-privilege access, means that if the agent is compromised, misled by a prompt injection, or given a bad instruction, the blast radius is contained.

An agent that has read access to your email for drafting purposes but no write access, no forwarding permission, and no connection to your financial accounts has a very limited attack surface. Even if it is manipulated into attempting a harmful action, the permission boundary prevents execution. An agent with broad permissions to read, write, send, and connect to everything creates an attack surface proportional to its access.

The spending limit principle works the same way. An API key with a $50 spending cap that gets stolen is a $50 problem. An API key with no cap that gets stolen is an open liability until you discover and rotate it. Setting explicit spending limits on every API key is one of the highest-return security investments you can make on any agentic system, because it converts an unlimited downside into a bounded one.

Running agents in sandboxed environments, whether a virtual machine, a container, or an operating-system-level isolation layer, adds another layer of protection. A sandboxed agent cannot read files outside its designated folder, cannot run processes outside its container, and cannot establish network connections to services not explicitly allowed. If the agent is compromised, the sandbox prevents the compromise from propagating to Madhuranjan Kumar system.

For businesses running Facebook and Instagram ad campaigns or Google Ads accounts that are connected to AI tools for reporting or optimization, this is particularly relevant. Ad account credentials with spending authority represent real money and real campaign performance. An agent with access to those credentials should be given exactly the read permissions it needs for reporting, with write permissions added only for specific, explicitly approved automation tasks, and with those permissions reviewed and reconfirmed regularly.

The habit of rotating keys at the first sign of anything unusual is the final layer. Key rotation is the action that makes a leaked credential worthless immediately. If something in your agent's behavior looks odd, if a service shows usage you did not initiate, if an account shows login activity from a location you do not recognize, rotate the relevant credentials before investigating further. The investigation can wait. Stopping the potential damage cannot.

None of these mitigations require deep technical expertise. They require the same kind of careful, slightly paranoid thinking you apply to physical security: lock the doors even when you expect the neighborhood to be safe, because the cost of the lock is low and the cost of a break-in is not. ## A concrete setup that contains the risk without eliminating the utility

The approach that works in practice is designing the agent's access from the assumption that something will eventually go wrong, and ensuring that when it does, the damage is contained. This is the same principle that governs physical security: you lock the door not because you are certain someone will try to open it, but because the cost of locking it is low and the cost of a break-in is not.

A concrete example from a business that got this right: a small financial advisory firm wanted to use an AI agent to help with research tasks: summarizing market reports, drafting client update letters, and preparing briefing documents for advisor-client meetings. The access design started with a clear list of what the agent would and would not be able to reach.

The agent could access: a folder of approved market research reports, a template library for client communications, a public financial data feed, and a calendar for scheduling. The agent could not access: any client account information, any brokerage accounts, any email inbox, any document with personally identifiable client data. The permissions were enforced at the file system level, not just through instructions to the agent.

Every AI-generated document was required to pass through a human review before being sent or used in any client-facing context. The review was not optional and was not waived for documents the agent produced confidently. The reviewer's job was not to rewrite the document but to verify that every specific claim, every figure, and every reference was accurate and appropriate.

API keys used by the agent had spending caps set at the project level, reviewed quarterly. When a new key was created for a new integration, the cap was set conservatively and raised only after observing actual usage for thirty days. No key with financial account access of any kind was shared with the agent for any reason.

Eighteen months into using this setup, the firm had not experienced any security incident. What they did experience was one false positive prompt injection: a report from a financial website contained text that the agent interpreted as an instruction to format its summary differently. The change in format was caught during the standard review, the source document was flagged, and the website was removed from the approved source list. The incident took thirty minutes to diagnose and resolve. Without the review step, a more sophisticated prompt injection could have done something more significant before anyone noticed.

The lesson is not that agents are dangerous and should be used minimally. It is that agents are useful and the governance that makes them safe is not particularly burdensome. The review habit, the minimal-access design, and the spending caps each cost a small amount of time to set up and very little to maintain. The return is an agent that can be used confidently for real work without the anxiety that comes from knowing it has broad, unrestricted access to sensitive systems. That confidence is itself valuable, because it means the agent gets used consistently rather than cautiously avoided whenever the stakes feel even slightly high.

The final discipline that makes security governance sustainable rather than burdensome is reviewing and updating it as your AI usage evolves. The permissions that were right for your first agent may be too narrow or too broad for your fifth. The task types that were low-risk when you started may have expanded to include higher-risk operations as the team became more comfortable with agentic tools. A quarterly review of the access map, the spending caps, and the output review cadence takes two hours and ensures that the governance keeps pace with the actual use rather than lagging behind it. The review is also the moment to document what you have learned about where the agents are most and least reliable, which updates the governance based on evidence rather than assumption.