AI agents are moving into businesses fast. Most teams haven't had time to think through the security implications. Platforms like n8n and Make.com can read files, send emails, call APIs, interact with browsers, and trigger actions inside your business tools, depending on how they're configured. Some teams still deploy these tools without precisely evaluating the attack surface they introduce.
AI Agents That Act, Not Just Answer
Three levels are worth distinguishing. A classic automation follows a predefined path. An LLM-augmented workflow can interpret content or make limited decisions. A true AI agent has tools, an objective, and planning capabilities that let it chain multiple actions autonomously. That last category generally presents the largest risk surface, because the agent can combine interpretation, tool selection, and action execution. Cisco put it plainly: an AI agent is no longer a conversational assistant. It's a new attack vector wired directly into your systems. In some extensible agent frameworks, plugins or skills can load dynamically and run with significant privileges within the execution environment. The actual exposure depends on the platform, isolation model, and permissions granted.
Key Security Risks of Agentic AI Systems
An autonomous AI agent should never be deployed on a production machine with elevated privileges. In production, it must be isolated, subject to the principle of least privilege, monitored, and governed by controls appropriate to the criticality of its actions.
Risks vary by platform and architecture, but several categories come up repeatedly in security analyses:
- Workstation or execution environment compromise: a vulnerability in the agent, an extension, or a dependency may allow partial or full control of its environment
- Data leakage: agents transmit sensitive information to external services you don't control
- Overly broad permissions: the agent may receive access to far more systems than it actually needs
- Shared credentials: access tokens or passwords handed to the agent can end up exposed or exfiltrated
- Lack of traceability: without logging and monitoring, it becomes difficult to know which actions the agent performed, and what their impact was
Prompt Injections and LLM Risks: Key OWASP Categories
The OWASP Top 10 for LLM Applications provides a classification of important risks in applications that integrate language models. Several categories are particularly relevant in agentic contexts:
- Prompt injection: an attacker hijacks the agent's behavior via malicious instructions hidden in an email, PDF, or Slack message
- Sensitive data disclosure: the model leaks confidential information from its context or system prompt
- Excessive agency and overly broad permissions: the agent holds far more permissions than needed, which amplifies the damage when something goes wrong
- Insecure output handling: AI outputs trigger actions via tools or APIs with no human review step in between
- Supply chain vulnerabilities: unverified community plugins, third-party dependencies, or unaudited models introduced into the architecture
- Data or knowledge base poisoning: manipulated data can influence the model's responses or the agent's decisions
This selection is not a full reproduction of the OWASP Top 10. It highlights the categories most directly relevant to agents that use tools and act on external systems.
n8n and Make.com Workflows: Risks That Are Often Overlooked
Low-code platforms make sharing workflows trivial: export a JSON, share it, done. In n8n, a workflow export contains the workflow definition, including its nodes, parameters, and referenced connections. Some exports may also include credential names and, for requests imported from cURL, authentication headers. You should inspect and anonymize the file before sharing it. More broadly, as this analysis of hidden risks in these platforms explains, any imported workflow should be reviewed before activation, especially when it uses scripts, community nodes, or external integrations.
- Unverified code in script nodes: malicious or insufficiently controlled logic can exfiltrate data or trigger unauthorized actions during workflow execution
- Credential exposure: connection names and configs revealing infrastructure details, or hardcoded secrets buried inside the JSON
- Unverified community nodes: third-party components may introduce code or dependencies with additional risks, with access levels depending on their implementation and the instance's configuration
- Unpatched self-hosted instances: for n8n in particular, recent security advisories have covered expression evaluation and code execution. Follow security bulletins and apply patches promptly
- Data privacy compliance: personal data sent to AI APIs potentially processed outside your jurisdiction, with no formal data processing agreement
What Recent Security Research Shows
Recent incidents show these risks are already exploitable in certain ecosystems. Trend Micro documented malicious OpenClaw skills used to distribute a variant of the Atomic macOS Stealer (AMOS) infostealer. Cisco and Palo Alto Networks have analyzed risks tied to elevated privileges, malicious skills, and the extension supply chain. And a recent arXiv paper formally maps the attack surface of LLM agents in production. These examples describe specific architectures, but they show that threat actors are already targeting parts of this ecosystem.
Concrete Steps to Secure Your AI Automations
None of this is inevitable. These risks are manageable, as long as security is built in from the start, not bolted on afterward. Here are the practices to put in place before deploying anything to production.
- Least privilege: the agent only gets access to what it strictly needs, nothing more
- Human approval for irreversible actions: deletion, sending, modification of production data. For reversible, low-risk actions, solid controls and full logging may be sufficient
- Isolated test environment: test agents in an isolated environment with synthetic or non-sensitive data before connecting to any production system
- Audit imported workflows: inspect every script node, strip hardcoded credentials, only import from internal or official sources
- Trigger whitelists: lock down which users or groups can activate the agent, and under what conditions
- Log and monitor: retain the actions performed, tools called, and human approvals, with a retention period compatible with your privacy requirements
- Emergency stop: any agent capable of sensitive actions must be quickly disableable, with access tokens revocable without delay
- Token rotation and expiration: limit the lifetime of API keys and revoke immediately those that are no longer needed
- Volume and cost limits: set caps on the number of API calls, emails sent, files modified, or transactions triggered
- Environment separation: use distinct accounts, credentials, and data for development, testing, and production
- Data minimization: only send what's strictly necessary to AI APIs, pseudonymize where possible, verify data processing agreements
- IT and security sign-off: any agentic automation going to production needs formal residual risk acceptance first
AI automation can save a lot of time. A misconfigured agent can waste far more. That's not a reason to avoid it. It's a reason to do it right.
If you're curious about the broader picture of AI in security, we've also written about AI as both a tool and a threat in enterprise cybersecurity.