The AI Security Playbook

By the end of this playbook you will have:

• A one-page inventory of every place AI touches your business: chatbots, agents, voice agents, n8n/Make/Zapier flows, RAG assistants, and AI features inside your product
• A blast-radius tier for each one, so you know which systems need strict controls and which only need basic hygiene
• A risk-to-control map based on the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications
• Least-privilege tool access and human approval on every action that writes, sends, pays, or deletes
• Secrets, data, and vendor rules your team can follow without a security department
• Logging, cost limits, and an incident runbook you can run the day something goes wrong
• A maturity path for the next 90 days, plus a short map to NIST AI RMF, MITRE ATLAS, and the EU AI Act

This is a working playbook, not a policy document. Each step ends with something you can check.

Octacer note: We build and rescue AI agents, voice agents, and automations for a living. The pattern we see most is not an exotic attack. It is an agent with too many permissions, a provider key in the wrong place, or a workflow nobody is watching. This playbook targets those first.

Classic app security assumes code follows instructions and data stays data. Large language models do not keep that boundary.

• The UK National Cyber Security Centre (NCSC) argues that prompt injection is not like SQL injection: current LLMs do not enforce a boundary between instructions and data, so it may never be fully mitigated the way SQL injection can be. The practical response is to design so a fooled model cannot do much damage.
• In the OWASP Top 10 for LLM Applications 2026 (published August 2026), Excessive Agency moved up to number three. OWASP says agentic deployments are where the damage is landing, and that once a model has tools, memory, and downstream consequences, you should also use the OWASP Agentic Top 10.
• Real incidents follow this shape. EchoLeak (CVE-2025-32711) was a Microsoft 365 Copilot information disclosure flaw where a crafted email could trigger indirect prompt injection and leak data with no user click. Microsoft fixed it server-side in 2025.

The takeaway for a business: assume the model will sometimes be wrong or be fooled, then limit what it can reach, what it can do, and how fast you will notice.

A rule that keeps this simple: let the AI propose, and let ordinary code and people authorize. The system prompt is not your security policy. "Never refund more than the approved limit" is useful guidance for the model, but the payment API should reject a larger refund no matter what the model says. The same goes for "never email outside our domain" or "only HR can read salaries".

1. A list of the AI tools and automations you already run, even if it is rough. Ask each team lead; shadow AI is common.
2. Admin access (or an admin you can work with) for your workflow platforms: n8n, Make, Zapier, GoHighLevel, or similar.
3. Access to your LLM provider dashboards (OpenAI, Anthropic, Google, Azure, and so on) to check keys, usage, and data settings.
4. One owner for this work. It does not need to be a security specialist, but it needs a name.
5. Two to four hours for the first pass. The full maturity path runs over about 90 days.

You cannot secure what you have not listed. Build a simple sheet with one row per AI system.

Check: every row has an owner, and every "what it can do" cell lists real actions, not "integrates with HubSpot".

Not every chatbot needs the same controls. Rank each row by the worst thing it could do if it were fooled or broken.

The tier is set by the most dangerous tool, not the average one. A friendly FAQ bot that can also issue refunds is Tier 3.

Check: every system has a tier, and every Tier 2 or 3 system has a named approver.

Use the two OWASP lists as your checklist. The LLM list covers the model as a component. The Agentic list covers the model as an actor.

OWASP Top 10 for LLM Applications 2026, in plain terms

OWASP Top 10 for Agentic Applications, the ones SMBs hit first

• ASI01 Agent Goal Hijack: outside content redirects the agent's goal. Same root cause as prompt injection, bigger impact.
• ASI02 Tool Misuse and Exploitation: a legitimate tool is used in a harmful way.
• ASI03 Identity and Privilege Abuse: the agent acts with a human's broad credentials or a leaked token.
• ASI04 Agentic Supply Chain Vulnerabilities: a poisoned MCP server, tool, or plugin at runtime.
• ASI06 Memory and Context Poisoning: bad data stored in memory changes behavior later.
• ASI09 Human-Agent Trust Exploitation: a confident, polished explanation gets a human to approve something harmful.

The full list also covers unexpected code execution (ASI05), insecure inter-agent communication (ASI07), cascading failures (ASI08), and rogue agents (ASI10). If you run multi-agent systems or let agents write and run code, read those entries in full.

Check: for each Tier 2 and Tier 3 system, you have written which of these risks apply and which step below covers it.

What is prompt injection?

Prompt injection is when text the model reads changes what it does in ways you did not intend. OWASP lists it as risk LLM01. The text can come from a user, or be hidden in an email, web page, PDF, or tool result, and it does not need to be visible to a human. If the model has tools, a successful injection can turn into real actions.

How do you prevent prompt injection?

Filters and clever system prompts help, but they are not a security boundary. Design so injection has nowhere to go.

1. Label untrusted input. Anything from outside your company is untrusted: customer messages, emails, web pages, uploaded files, call transcripts, tool results from third-party APIs, and even your own knowledge base if customers can add to it.
2. Break the dangerous combination. Be very careful with any agent that has all three of: access to private data, exposure to untrusted content, and a way to send data out (email, HTTP request, link rendering, file write). Security researcher Simon Willison calls this the "lethal trifecta". Remove at least one leg for each agent.
3. Split roles. Use one step to read and summarize untrusted content with no tools, and a separate step with tools that only sees the structured summary.
4. Never let content change permissions. A message saying "I am the admin" or "ignore previous rules" should not be able to unlock tools. Permissions come from your auth system, not the conversation.
5. Gate side effects. Writes that matter go through a human approval or a deterministic rule check (Step 5).
6. Test it. Keep a short list of injection test cases (hidden text in a PDF, an instruction in an email signature, a malicious web page) and run them whenever you change prompts, models, or tools. The OWASP LLM Prompt Injection Prevention Cheat Sheet is a good source of patterns.

Check: for each agent, you can say which leg of the trifecta is missing, and you have run at least three injection tests.

This is the single highest-value step for most businesses.

What is excessive agency?

Excessive agency is OWASP's name for an AI system that can take damaging actions when the model gets something wrong, whether from a hallucination, a bad prompt, or an injection. OWASP traces it to three root causes: too much functionality, too many permissions, and too much autonomy. Least privilege and approvals address all three.

1. One service account per agent. Do not connect agents with a founder's or admin's personal login. Create a dedicated user or API key with only the scopes it needs.
2. Split read tools from write tools. Reads (search contact, get order status) can often run freely. Writes (update deal, send email, cancel booking, refund) get stricter handling.
3. Allow-list actions, not apps. "Can use HubSpot" is too broad. "Can search contacts and add a note" is right. Zapier MCP, for example, lets you restrict which apps and actions an AI client can use; our Zapier MCP playbook shows an allow-listed CRM setup.
4. Human approval on Tier 3 actions and risky Tier 2 actions. Show the approver the real parameters (record ID, amount, recipient, message body), not the model's summary. Fail closed on timeout. Our n8n human-in-the-loop playbook walks through this.
5. Hard limits in code, not in the prompt. Maximum refund amount, maximum emails per hour, allowed domains for outbound HTTP, allowed calendar IDs. The model can ask; the tool enforces.
6. MCP servers: follow the MCP security best practices. Do not pass a user's token straight through to downstream APIs (token passthrough), keep scopes minimal, and watch for confused-deputy problems in proxy servers. Only install MCP servers you trust and have reviewed.
7. Verify, then confirm. An agent should only tell a customer "done" after the system of record returns success. See preventing silent AI write failures.

Check: no agent uses a personal or admin credential, and every write tool has either an approval step or a coded limit.

1. No provider keys in front-end code, mobile apps, or browser extensions. The client calls your backend; your backend holds the key. If you already shipped a key, rotate it now. Our containment playbook for client-side AI provider keys covers the migration.
2. No secrets in prompts. System prompts can leak (OWASP LLM08 Hidden Context Exposure). Keep API keys, passwords, and access rules out of anything the model sees.
3. Use the platform's credential store or a vault, not plain text in workflow nodes, spreadsheets, or Notion pages.
4. Separate keys per environment and per agent, so one leak does not expose everything and usage is traceable.
5. Self-hosted n8n: set your own strong N8N_ENCRYPTION_KEY on every main instance and worker, back it up separately from the database, and follow n8n's guidance on key rotation.
6. Set spend limits and alerts on every LLM provider account. A leaked key or a runaway loop shows up first as a bill.
7. Rotation plan: know how you would rotate each key in under an hour, and write it down.

The OWASP Secrets Management Cheat Sheet goes deeper on storage, rotation, and auditing if you run your own vault.

Check: a search of your repos, workflows, and front-end bundles finds no provider keys, and every provider account has a spend alert.

1. Classify data in three buckets: public, internal, and restricted (personal data, health, financial, credentials, client confidential). Write down which AI systems may see each bucket.
2. Check each vendor's data terms: whether inputs are used for training, retention periods, data region, sub-processors, and whether a data processing agreement is available. Settings differ by plan, so check the plan you actually pay for. Zapier, for example, documents how workflow data is and is not used for AI training on its security pages. OpenAI says business and API data is not used for training by default, and that API inputs and outputs may be kept for up to 30 days to run the service and spot abuse, unless an eligible endpoint has zero data retention approved. Training, retention, human review, and data region are separate questions, so record an answer for each, and re-check when you change model, region, or feature.
3. Minimize. Send the model the fields it needs, not the whole CRM record. Redact or mask restricted fields where you can.
4. Approved components list. Keep a short list of approved models, platforms, MCP servers, community nodes, and plugins. New ones get a quick review before use (OWASP LLM04 and ASI04).
5. Pin versions of models and components where the platform allows, and re-test when you change them. Model updates can change behavior.
6. Staff rules. Tell staff, in one page, which AI tools they may paste company or client data into. The EU AI Act's AI literacy obligation has applied since 2 February 2025, and a short internal guide is a sensible base even outside the EU.

The joint CISA, NSA, and FBI guidance on AI data security (May 2025) is a useful reference for provenance, integrity checks, encryption, and access control on data used by AI systems.

Check: every AI system in your inventory has a data bucket next to it, and every vendor has its training and retention settings recorded.

Retrieval is where most data leaks in business assistants happen, because the assistant can only be as careful as the index behind it.

1. Enforce access at retrieval time. If a user cannot open a document in the source system, the assistant should not retrieve it for them. Filter by user, role, or tenant before results reach the model.
2. Separate indexes per client or tenant when you serve more than one. Shared indexes with metadata filters work only if the filter can never be skipped.
3. Control what gets indexed. Decide who can add content. Customer-submitted files and scraped web pages are untrusted and can carry injection or poison (OWASP LLM05 and LLM09). Treat ingestion and retrieval as two separate permission checks; the OWASP RAG Security Cheat Sheet covers both.
4. Keep provenance. Store the source, owner, and date with each chunk so you can trace and remove bad content.
5. Show sources in answers where possible, so humans can verify.
6. Memory hygiene. If agents remember across sessions, decide what can be stored, who can see it, and how it is cleared. Poisoned memory can change behavior long after the original message (ASI06).

If you are building an internal docs assistant, our Dify internal RAG playbook shows a practical starting setup.

Check: you have tested that a staff member without access to a document cannot get its content through the assistant.

1. Validate structure. If the next step expects JSON, validate it against a schema and reject anything else. See hardening LLM JSON output contracts.
2. Encode before display. Escape HTML and Markdown in chat widgets and emails. Be careful with auto-loaded images and links in model output: EchoLeak used an auto-loaded Markdown image as part of its exfiltration path.
3. Never execute raw output. No eval, no shell commands, and no SQL built from model text. Use parameterized queries and fixed tool functions.
4. Restrict outbound links and domains the model can produce or fetch.
5. Review AI-generated code like any other code before it merges. OWASP 2026 now counts insecure assistant-generated code under Improper Output Handling. Our pre-merge review gate playbook covers this.

Check: every place model output flows into code, a database, a browser, or another system has a validation or encoding step. For the basics of adding AI steps to existing workflows, see adding AI steps to business workflows safely.

Most business AI runs inside a workflow tool, so the platform settings matter as much as the prompts.

n8n (self-hosted or Cloud)

• Run the built-in security audit (n8n audit, the public API, or the n8n node). It reports unused credentials, risky SQL expressions, nodes with file system access, and other issues.
• Enforce MFA or SSO, and review who has owner and admin roles.
• Use n8n's settings to block nodes you do not need (for example, ones that execute commands or touch the file system), enable SSRF protection, and redact execution data for workflows that handle personal data.
• Put authentication on every webhook, and disable the public API if you do not use it.
• Back up the encryption key and database separately.
• Keep n8n updated and limit who can edit workflows. In December 2025 n8n published a critical remote code execution advisory (CVE-2025-68613) that let an authenticated user who could edit workflows run code on the host, and further fixes for the same issue followed in early 2026. n8n's own interim advice was to restrict workflow creation and editing to fully trusted users. Our self-hosted n8n playbook covers a production setup.
• On Enterprise plans, keep credentials in an external secret store (n8n supports 1Password, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault, and Infisical) instead of inside n8n.

Zapier

• Restrict which apps and actions AI tools and MCP clients can use.
• Use workspace roles, SSO where available, and review activity logs for AI actions.
• Remove connections owned by people who have left.
• On plans that offer them, use Zapier's admin controls for app connections: managed connections, managed apps, allowed OAuth domains, and app access policies.

Make

• Use Make's connections and credential requests instead of pasting secrets into modules, so the person building a scenario does not need to see the password or key.
• Use least-privilege OAuth scopes and revoke connections you no longer need.

Power Automate and Power Platform

• Use data policies (DLP) to control which connectors can handle business data, and block connectors you have not approved. Microsoft notes that desktop flows that break a data policy can be suspended, so test changes before rolling them out.
• Keep sensitive flows in their own environment, away from experiments, and run them under dedicated accounts rather than a personal admin login.

All platforms

• One owner per workflow, a naming convention, and an error workflow that alerts a human.
• A quarterly review of connections, shared credentials, and inactive users.
• Our silent integration failure triage playbook helps make sure failures are visible.

Check: you have run the n8n audit (or equivalent review) and closed the findings, and every production workflow has an owner and an error alert.

Voice adds two kinds of risk: the agent itself, and attackers using AI voices against your staff.

Securing your own voice agent

1. Disclose that callers are talking to an AI. The EU AI Act transparency rules require people to be told when they interact with an AI system, and they apply from August 2026.
2. Get consent right for outbound calls. In the US, the FCC confirmed in February 2024 that AI-generated voices count as "artificial" voices under the TCPA, so the consent rules for robocalls apply.
3. Keep voice agents at Tier 1 or Tier 2. Let them answer, qualify, and book. Do not let them take card numbers by voice, issue refunds, or change account access without a human step.
4. Confirm against the system of record before telling a caller a booking is made. See voice agent confirms booking without an appointment.
5. Treat transcripts as untrusted input (callers can speak instructions) and as restricted data (they often contain personal details). Set retention and redaction rules.

Protecting your team from voice and video deepfakes

• In 2024 the engineering firm Arup confirmed that an employee in Hong Kong was deceived by a video call with AI-generated versions of senior colleagues and made transfers totaling about US$25 million.
• The fix is process, not detection software: call-back verification on a known number for payment changes, new payees, and urgent transfer requests, plus a second approver for transfers above a set amount.

Check: your voice agent discloses that it is AI, cannot move money, and every payment change requires a call-back on a known number.

1. Log every tool call with timestamp, agent, user or session, tool name, parameters, result, and approver if any. Also record the model and version, the prompt or configuration version, a correlation ID that ties one request together, and which data sources were read. This is what you will need in an incident. The OWASP Logging Cheat Sheet is a good reference for what to capture and what to keep out of logs.
2. Log prompts and outputs for Tier 2 and Tier 3 systems, with redaction for restricted data and a set retention period.
3. Alert on behavior, not just words: spikes in tool calls, repeated denied approvals, attempts to call tools that do not exist or are not allowed, new outbound domains or unusual recipients, one session reading many customer records, unexpected writes to agent memory, workflow loops, sudden token or cost jumps, and repeated injection-like phrases.
4. Set caps: maximum agent iterations per task, maximum tokens per request, rate limits per user, and provider spend limits (OWASP LLM06 Unbounded Consumption). Our AI cost or latency spike triage playbook covers diagnosis.
5. Review weekly for Tier 3 systems and monthly for the rest.

Check: you can answer "what did this agent do yesterday, and who approved it?" in under ten minutes.

Keep this to one page per Tier 2 or Tier 3 system.

1. Detect: who gets alerted, and through which channel.
2. Contain authority first: a documented kill switch for each agent (disable the workflow, revoke the tool's credential, or switch the bot to a "handing you to a human" mode). Cutting what the agent can do is faster than fixing its prompt while it stays live. Also pull poisoned documents from retrieval and clear bad agent memory. Practice it once.
3. Rotate: the list of keys and tokens the system uses, and how to rotate each one.
4. Investigate: where logs live, and how to export tool calls and conversations for the incident window.
5. Repair: how to find and fix records the agent changed. Approval logs and tool-call logs make this possible.
6. Notify: who decides whether customers, clients, or regulators must be told, and your legal deadlines (for example, GDPR breach notification rules if you handle EU personal data).
7. Learn: add the attack or failure to your test cases, then re-test.

For the wider process, NIST SP 800-61 Rev. 3 (April 2025) is NIST's current incident response guidance and fits AI incidents into your normal cybersecurity risk management.

Check: someone other than the builder has run the kill switch for each Tier 3 system in under five minutes.

Move a system up a stage before you give it more autonomy. Autonomy is earned by controls, not by a better prompt.

A simple scorecard for leadership. For each production AI system, track yes or no for: owner, data bucket, vendor review, retrieval permissions, scoped agent account, managed secrets, human-approval boundary, kill switch, security logs, spend and tool limits, prompt injection tests, incident runbook, and the date of the last review. It measures your own coverage, not a comparison with anyone else.

You do not need to adopt a full framework to start, but it helps to know where this playbook fits.

• NIST AI Risk Management Framework (AI RMF 1.0): organizes work into Govern, Map, Measure, and Manage. Steps 1 and 2 are Map, Steps 4 to 11 are Manage, Step 12 is Measure, and owners plus reviews are Govern. NIST's Generative AI Profile (NIST AI 600-1) adds generative-AI-specific risks and actions.
• NIST Cyber AI Profile (NIST IR 8596): a draft Cybersecurity Framework profile for AI. As of October 2026 it is still a draft, so watch it rather than build to it.
• MITRE ATLAS: a knowledge base of real adversary tactics and techniques against AI systems. Useful when planning tests in Stage 4.
• ISO/IEC 42001:2023: the international standard for an AI management system, for organizations that build or use AI. Useful when you want policies, roles, supplier reviews, and continual improvement in a structure auditors recognize. Certification is optional.
• UK NCSC Guidelines for Secure AI System Development: secure design, development, deployment, and operation guidance from the NCSC and partner agencies.
• EU AI Act (Regulation (EU) 2024/1689): applies if you place AI systems on the EU market or your AI's output is used in the EU. Key dates for most businesses:
• Prohibited practices and AI literacy: since 2 February 2025
• General-purpose AI model rules: since 2 August 2025
• General application, including transparency duties such as telling people they are talking to an AI: from August 2026
• High-risk use cases in areas like employment, education, and credit: moved to 2 December 2027 by the 2026 AI Omnibus (Regulation (EU) 2026/1744); high-risk AI in regulated products moved to 2 August 2028
• If you use AI to screen CVs, score candidates, or decide access to credit or essential services, treat it as potentially high-risk and get legal advice now.
• Article 50 transparency: if you use a third-party chatbot or voice platform, agree in writing who shows the "you are talking to an AI" notice, rather than assuming the vendor does it.
• Article 26, for deployers of high-risk systems once it applies: follow the provider's instructions, assign human oversight to people with the competence and authority to act, monitor the system, report serious incidents, and keep the logs it generates (where you control them) for at least six months unless other law says otherwise.
• Classify use cases, not vendors. The same model can be low risk drafting marketing copy and high risk when it helps decide who gets hired.

This section is general information, not legal advice.

• [ ] Listed in the inventory with an owner and a tier
• [ ] Dedicated service account; no personal or admin credentials
• [ ] Tools allow-listed; read and write split
• [ ] Approval or coded limits on every write; fail closed on timeout
• [ ] At least one leg of the lethal trifecta removed
• [ ] No secrets in prompts or front-end code; keys in a credential store
• [ ] Data bucket recorded; vendor training and retention settings checked
• [ ] Retrieval access control tested (if RAG)
• [ ] Output validated and encoded before it reaches code, a browser, or another system
• [ ] AI disclosure in place for customer-facing chat and voice
• [ ] Tool calls logged; cost caps and alerts on
• [ ] Kill switch documented and tested
• [ ] Injection and permission tests run and passing

• Relying on the system prompt for security. "Never reveal customer data" is a request, not a control.
• Connecting agents with an admin login because it was faster during the demo.
• Approval screens that show the model's summary instead of the actual parameters. Approvers then trust a polished explanation (ASI09).
• Indexing everything into one knowledge base and hoping the bot will be discreet.
• No spend limits on provider accounts, so the first sign of a leaked key is the invoice.
• Installing community nodes, plugins, or MCP servers without checking who maintains them.
• Telling customers "done" before the write succeeded.
• Treating security as a one-time project. Models, tools, and prompts change; re-test when they do.

We are a small team. Do we really need all of this?

No. Do Stage 1 this week and Stage 2 for any agent that writes to your systems or talks to customers. Tier 0 internal tools only need the basics.

Can a better system prompt or a guardrail product stop prompt injection?

They reduce it. They do not remove it. The NCSC's position is that prompt injection may never be fully mitigated the way SQL injection can be, so limit what a fooled model can reach and do.

Is it safe to send customer data to an LLM provider?

It depends on the provider's terms for your plan, the data type, and your own obligations to customers. Check training use, retention, region, and the data processing agreement, and send only the fields the task needs.

Do these risks apply to no-code tools like Zapier, Make, and GoHighLevel?

Yes. The model and the platform are different, but the risks are the same: what the AI can read, what actions it can take, and where credentials live.

Does the EU AI Act apply to a business outside the EU?

It can, if you place AI systems on the EU market or the output is used in the EU. Get specific advice for your case.

What are the biggest AI agent security risks?

For most businesses: agents with more access than they need (excessive agency), prompt injection from emails, files, or web pages, provider keys in the wrong place, sensitive data reaching the wrong person through a chatbot or knowledge base, and workflows nobody is monitoring. The OWASP Top 10 for LLM Applications 2026 and the OWASP Agentic Top 10 list them in full.

What is the OWASP Top 10 for LLM Applications 2026?

It is the OWASP GenAI Security Project's list of the most critical security risks for applications built on large language models, published in 2026. It runs from LLM01 Prompt Injection to LLM10 Improper Output Handling, with Excessive Agency at number three. Step 3 above maps each risk to a first control.

What should an AI agent security checklist include?

At minimum: an owner and a risk tier, a dedicated service account, allow-listed tools, approval or coded limits on every write, no secrets in prompts or front-end code, a clear data rule for each vendor, logging and alerts, spend caps, and a tested kill switch. The go-live checklist above has the full list.

Is n8n secure?

n8n can be run securely, but on a self-hosted instance the security is largely your job: updates, the encryption key, MFA or SSO, webhook authentication, and who can edit workflows. n8n has published critical advisories, including CVE-2025-68613 in December 2025, so patching quickly matters. Run its built-in security audit and close the findings.

How often should we review?

Weekly log review for Tier 3 systems, monthly for the rest, and a full access and connection review every quarter or after any major change.

We design, build, and harden AI agents, voice agents, and automations on n8n, Make, Zapier, GoHighLevel, HubSpot, and custom stacks. For security work, that usually means:

• An AI security review of your current agents and workflows against this playbook, with a prioritized fix list
• Least-privilege rebuilds: service accounts, allow-listed tools, approval gates, and coded limits
• Moving provider keys server-side and setting up rotation and spend controls
• Logging, alerts, and kill switches your team can operate
• Rescue work when an AI feature is already misbehaving in production. See System Rescue.

Want a second pair of eyes on your agents before you give them more autonomy? Book a call and we will walk through your inventory with you.

• Add approvals to your write tools: Production Approvals: n8n Human-in-the-Loop Tool Gates
• Fix exposed keys: Containing Client-Side AI Provider Keys
• Contain invented answers: The AI Agent Invented an Answer
• Wire MCP safely: Business MCP Starter Pack
• See how we build AI features: AI Apps and Integrations and Architecture

All links were checked on October 24, 2026.

• OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/
• OWASP GenAI Security Project, 2026 Top 10 release announcement (September 2026): https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/
• OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications (December 2025): https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
• OWASP Cheat Sheet Series, AI Agent Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
• OWASP Cheat Sheet Series, LLM Prompt Injection Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
• UK NCSC, "Prompt injection is not SQL injection (it may be worse)": https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
• UK NCSC, Guidelines for Secure AI System Development: https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
• NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• NIST, AI 600-1 Generative AI Profile: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
• NIST NCCoE, IR 8596 Cyber AI Profile (draft): https://www.nccoe.nist.gov/publications/csf-profile/nist-ir-8596-ipd-cybersecurity-framework-profile-artificial-intelligence
• MITRE ATLAS: https://atlas.mitre.org/
• CISA, AI Data Security: Best Practices for Securing Data Used to Train and Operate AI Systems: https://www.cisa.gov/resources-tools/resources/ai-data-security-best-practices-securing-data-used-train-operate-ai-systems
• Model Context Protocol, Security Best Practices: https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
• Microsoft Security Response Center, CVE-2025-32711 (EchoLeak): https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32711
• Simon Willison, "The lethal trifecta for AI agents": https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
• n8n Docs, Security: https://docs.n8n.io/hosting/securing/overview/
• n8n Docs, Run security audits: https://docs.n8n.io/deploy/host-n8n/configure-n8n/security/run-security-audits
• n8n Docs, Set a custom encryption key: https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/set-a-custom-encryption-key
• Zapier, MCP security: https://docs.zapier.com/mcp/manage/security
• Zapier, Security and compliance: https://zapier.com/security-compliance
• Make Help Center, Credential requests: https://help.make.com/credential-requests
• FCC, "FCC Makes AI-Generated Voices in Robocalls Illegal": https://www.fcc.gov/document/fcc-makes-ai-generated-voices-robocalls-illegal
• CNN, "Arup revealed as victim of $25 million deepfake scam involving Hong Kong employee": https://www.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
• European Commission, AI Act overview and timeline: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• EUR-Lex, Regulation (EU) 2024/1689 (AI Act): https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
• EUR-Lex, Regulation (EU) 2026/1744 (Digital Omnibus on AI): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
• EU AI Act Service Desk, Article 4 (AI literacy): https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4
• EU AI Act Service Desk, Article 26 (Obligations of deployers of high-risk AI systems): https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
• EU AI Act Service Desk, Article 50 (Transparency obligations): https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50
• ISO, ISO/IEC 42001:2023 AI management systems: https://www.iso.org/standard/42001
• NIST, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025): https://csrc.nist.gov/pubs/sp/800/61/r3/final
• OWASP Cheat Sheet Series, RAG Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html
• OWASP Cheat Sheet Series, Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
• OWASP Cheat Sheet Series, Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
• OpenAI, Enterprise privacy: https://openai.com/enterprise-privacy/
• n8n Docs, Use external secret stores: https://docs.n8n.io/administer/manage-credentials/use-external-secret-stores
• Zapier Help Center, Admin controls for app connections: https://help.zapier.com/hc/en-us/articles/49441881946253-Admin-controls-for-app-connections
• Microsoft Learn, Power Platform data policies: https://learn.microsoft.com/en-us/power-platform/admin/wp-data-loss-prevention
• Microsoft Learn, Power Automate data loss prevention: https://learn.microsoft.com/en-us/power-automate/prevent-data-loss
• OWASP GenAI Security Project, LLM01 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• OWASP GenAI Security Project, Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
• GitHub Advisory Database, n8n remote code execution via expression injection, CVE-2025-68613 (December 2025): https://github.com/advisories/ghsa-v98v-ff95-f3cp
• n8n, Expression escape vulnerability leading to RCE, GHSA-6cqr-8cfr-67f8 (2026): https://github.com/n8n-io/n8n/security/advisories/GHSA-6cqr-8cfr-67f8