1 Key Risks
The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Make exposes unauthenticated input channels, unrestricted outbound network access, and centralized credential stores with no default input filtering, output DLP, or per-action approval gates.
2 AIRQ Scores
The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. Make scores below median on defense controls while attack surface and blast radius both sit above the midpoint due to unrestricted network egress and centralized credential stores.
The Exposed Giants placement reflects unrestricted outbound HTTP, centralized credential stores, and no default webhook authentication, DLP, or per-step approval gating.
The four headline metrics capture the platform's default-configuration risk posture without operator hardening applied.
| Metric | Score | Comments |
|---|---|---|
| AIRQ Score | 4.12 | Composite driven by elevated attack surface and blast radius against minimal defense controls. |
| Blast Radius | 5.87 / 10 | Network and credential access at band 3 drive the weighted composite above median. |
| Attack Surface | 5.5 / 10 | Trifecta floor applied; six surfaces at band 3 with one CVE-elevated to ceiling. |
| Defense Controls | 3 / 15 | Two components at 1 and three at 0 reflect absent default protections across the platform. |
3 Attack Surface
Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. Six of ten attack surfaces score at band 3, driven by unauthenticated webhooks, unrestricted HTTP module access, and AI Agent delegation to external LLMs without instruction hierarchy.
Scores reflect the documented default configuration without operator-added validation modules or webhook authentication.
Each row measures the attack surface exposure inherent to the platform's default behavior for that component.
| Surface | Score | Comments |
|---|---|---|
| User Input | 3 / 4 | AI Agents accept prompts routed through scenario triggers with no built-in injection detection on the platform [6]. |
| External Data | 3 / 4 | Webhooks process inbound payloads without authentication by default; verification is opt-in via challenge-response [8]. |
| Memory | 2 / 4 | Execution logs and data stores persist per-run context accessible via API but no cross-session learning loop exists [7]. |
| Reasoning | 3 / 4 | AI Agents delegate reasoning to operator-selected LLMs through the API with no instruction hierarchy or prompt boundary documented [7]. |
| Planning | 2 / 4 | Scenarios follow operator-defined module chains; AI Agents select tools within a single invocation without multi-step autonomous planning per class-level risk patterns [4]. |
| Tool Execution | 3 / 4 | The HTTP module and AI Agent tool-calling reach arbitrary endpoints across the connected app catalog without per-call gating [6]. |
| Orchestration | 3 / 4 | Cron-like scheduled execution, sub-scenario triggers, and AI Agent decision loops fire without per-action human confirmation [6]. |
| Inter-Agent | 2 / 4 | Sub-scenario calls chain scenarios via webhooks; no formal multi-agent delegation protocol or autonomous agent mesh exists [6]. |
| Output Processing | 2 / 4 | Scenario outputs pass through modules without platform-enforced filtering; operators must add explicit validation steps [10]. |
| Configuration | 4 / 4 | CVE-2025-6085 demonstrated arbitrary file upload in the Make Connector WordPress plugin via misconfigured validation [1]. |
The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Make accepts unauthenticated webhook payloads, holds OAuth tokens for connected services, and issues unrestricted outbound HTTP — meaning a single compromised scenario can read private data and exfiltrate it without platform-level detection.
Make exhibits all three of these conditions in its documented default configuration:
- Untrusted input — Webhooks accept arbitrary payloads without platform-enforced authentication on the default configuration [8].
- Sensitive data — Scenarios access CRM records, email, and database rows via centralized OAuth tokens stored for all connected services [5].
- External egress — The HTTP module issues arbitrary outbound requests with no domain restriction or outbound DLP [5].
4 Blast Radius
The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. Network and credential access drive the blast radius composite above median, reflecting unrestricted outbound HTTP and centralized storage of OAuth tokens for all connected services.
Scores measure the maximum impact achievable through a compromised scenario execution on the default configuration.
Each factor quantifies the downstream damage potential when a scenario execution is compromised or misused.
| Factor | Score | Comments |
|---|---|---|
| Code execution | 2 / 4 | Custom function modules allow limited JavaScript expressions in data mapping; peer platforms have demonstrated RCE via sandbox escape [11]. |
| File system access | 2 / 4 | File operations read and write documents from connected cloud storage but no local server file system access exists [6]. |
| Network access | 3 / 4 | The HTTP module issues arbitrary outbound requests to any endpoint; no domain allowlist or egress filtering is documented in the platform configuration [6]. |
| Credential access | 3 / 4 | All connected service OAuth tokens and API keys are stored centrally; every scenario in the organization can access any stored connection during execution [5]. |
| Autonomous action | 2 / 4 | Scenarios execute all modules to completion once triggered but do not spawn persistent background processes [6]. |
| Deployment access | 2 / 4 | Scenarios can trigger deployments via connected CI/CD integrations but no direct infrastructure provisioning exists by default [6]. |
5 Defense Controls
Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. The platform ships no input guardrails, no output DLP, and no per-action approval gates by default, leaving all five defense components at or near the floor.
Scores reflect what the platform provides by default without operator-implemented custom modules or external tooling.
Each component measures the strength of the platform's built-in defense at the documented default configuration tier.
| Component | Score | Comments |
|---|---|---|
| Input Guardrails | 0 / 3 | No built-in prompt injection detection, content filtering, or input validation exists on the platform by default; the vendor bounty program [2] has disclosed no mitigation. |
| Execution Isolation | 1 / 3 | Enterprise tier provides isolated AWS environment per SOC 2 Type II attestation [9]; standard plans run in shared multi-tenant cloud infrastructure. |
| Action Controls | 1 / 3 | RBAC controls scenario authoring and publishing but once a scenario triggers, all modules execute without runtime per-action approval gates [7]. |
| Output Guardrails | 0 / 3 | No built-in DLP, credential redaction, or exfiltration blocking exists for scenario outputs on any tier [5]. |
| Monitoring | 1 / 3 | Scenario execution logs and enterprise audit logs are available but anomaly detection and SIEM integration are absent [5]. |
6 Hardening Tips
Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. Operators can materially reduce exposure by enforcing webhook authentication, scoping connection permissions, and deploying external monitoring.
Input Guardrails
Input guardrails intercept adversarial content before it reaches the reasoning loop.
- Policy Require all webhook endpoints to use HMAC signature verification before scenario processing begins [10].
- Configuration Deploy a validation module at the start of every scenario that rejects payloads exceeding schema bounds or containing injection patterns.
- Engineering Integrate a prompt injection detection service upstream of AI Agent modules to filter adversarial inputs before LLM delegation.
Execution Isolation
Execution isolation contains what a compromised agent can do on the host.
- Policy Mandate Enterprise tier deployment for scenarios handling sensitive data to gain isolated AWS environment boundaries.
- Configuration Use the on-premises agent to keep sensitive data processing within the private network boundary rather than cloud-hosted execution.
- Engineering Deploy an API gateway between external callers and Make webhooks to enforce rate limiting, authentication, and request filtering.
Action Controls
Action controls govern which tools and actions the agent can invoke autonomously.
- Policy Restrict scenario creation and editing permissions to security-reviewed roles using organization-level RBAC policies.
- Configuration Scope connected service OAuth tokens to minimum required permissions rather than broad administrative access across integrations [3].
- Engineering Implement a pre-execution webhook that validates scenario actions against an operator-defined allowlist before module execution proceeds.
Output Guardrails
Output guardrails inspect what the agent sends to other systems and users.
- Policy Require all scenarios handling PII to include a data-masking module before any external output steps in the execution chain.
- Configuration Configure webhook response modules to strip sensitive fields using JSON transformation modules before returning data to callers.
- Engineering Deploy a DLP proxy between Make scenario outputs and external endpoints to scan outbound payloads for credential and PII patterns.
Monitoring
Monitoring captures what the agent did and surfaces anomalies for review.
- Policy Require all production scenarios to forward execution logs to the organization SIEM, prioritizing credential-access events, outbound HTTP to new domains, and execution failures [5].
- Configuration Enable enterprise audit logging and configure threshold-based alerts for scenarios exceeding normal execution frequency or data volume.
- Engineering Build a log aggregation pipeline that correlates Make execution logs with downstream service access patterns for anomaly detection.
7 References
The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.
Selected Vulnerabilities
- CVE-2025-6085 Make Connector WordPress plugin arbitrary file upload via misconfigured file type validation (CVSS 7.2). Admin-authenticated RCE on the WordPress host. Patched in 1.5.11.
- Make Security Exploit Bounty Program Vendor operates a vulnerability disclosure program at bounty@make.com covering make.com domain with no public advisories listed.
Selected Research
- How to Secure Make.com Integrations in Enterprise Settings Third-party enterprise security guide covering credential handling and webhook exposure for Make.com deployments.
- OWASP Citizen Development Top 10 Security Risks Industry framework identifying ten pressing risks from no-code development including Blind Trust and Injection Handling failures.
Vendor Documentation
- Automation Security and Compliance Vendor security page documenting SOC 2 Type II, ISO 27001, AWS infrastructure, encryption, and penetration testing program.
- Make AI Agents Product page documenting AI Agent capabilities including visual orchestration and external LLM delegation across connected apps.
- AI Agents API Documentation Developer reference for programmatic agent creation, invocation, and SSE streaming on the open-beta runtime.
- Webhooks Custom Apps Documentation Developer documentation showing webhook processing without default authentication where verification is opt-in.
- Celonis Trust Center Parent company trust center providing Make-specific SOC 2 Type II reports and bridge letters.
Other Sources
- Is Make.com Secure? CISO Guide to Automation Independent security analysis covering shared responsibility model and unauthenticated webhook risks.
- n8n flaws widen automation security risk Class-level reference demonstrating RCE in a peer automation platform applicable to the Custom Workflow Agents class.