Make Security Guide: Securing connections, webhooks, roles and AI agents

Every Make scenario runs on stored connections to other systems, so a Make organisation quietly becomes a vault of OAuth grants, API keys and webhook endpoints that can read and write across your SaaS estate. Make (formerly Integromat) lets business teams build automations without engineering review, and its AI Agents feature now lets a language model choose which of those connections to call. This guide covers roles, privileged accounts, connections, API tokens and webhooks as non-human identities, logging and a hardening baseline. Plan limits are stated where Make's documentation states them.

This is an independent guide from NHI Mgmt Group, based on Make's public documentation as of November 2026. It is not sponsored or reviewed by Make. Product features change, so confirm settings against Make's current documentation.

Key takeaways

• Connections are the crown jewels. A Make connection holds a live credential for another system, and anyone with a team role that can edit scenarios can use it, even without seeing the secret.
• Team roles decide blast radius. Make permissions are granted per team, and custom role permissions are all or nothing per resource type, so separate teams are the real isolation boundary.
• Custom webhooks accept anyone by default. Turn on API Key authentication, IP restrictions and a Data structure on every custom webhook that receives sensitive or action-triggering data.
• Logs can hold the data you are protecting. Execution and webhook logs can contain request headers and payloads; use Keep data confidential on scenarios that move personal or secret data.
• AI agents inherit every tool you give them. Make's own guidance is to assume anything shared with an agent can be accessed, so give agents narrow scenario tools rather than broad connections.

How identity and access work in Make

Make has three layers: the user account, the organisation (the billing and administrative unit), and teams inside an organisation that own scenarios, connections, webhooks, keys, data stores, data structures and templates. A user can belong to several organisations and teams with a different role in each. Access to a resource comes from the team role, not from who created the resource, which is why connection sprawl inside a busy team is the first risk to understand.

How SSO behaves: SSO is configured separately for each organisation. Saving the configuration turns it on and logs you out; Make credentials stop working for login and users sign in through the SSO option. Make emails a one-time link that disables SSO, which is a break-glass mechanism and should be stored like one. The first SSO login must use an organisation owner account whose email matches the account that configured SSO. You choose a default team for new users at first login (or none), and map identity provider claims to Make with an Identity Management Language (IML) expression such as {"id":"{{sub}}","email":"{{email}}","name":"{{name}}"}. Claiming your email domain prompts new users from that domain to use SSO.

Existing users: Make states that a user who existed in the organisation with the same email before SSO was configured loses access to organisation data and must be deleted and log in again through SSO. Plan this before switching on SSO, because those users may own scenarios and connections that need reassigning first.

Availability: Make's documentation lists organisation SSO, audit logs and custom roles as Enterprise plan features, and states that custom roles are not supported on Make private instances. ISO 27001 certification is stated for Enterprise on Make's security page.

Admin roles and privileged access

Organisation Owners and Admins can manage every team, and Make gives them Team Admin permissions in each team of the organisation automatically. That makes them the most privileged identities in the platform: they can reach every connection in every team. There is exactly one Owner, and ownership moves only through Transfer ownership.

Custom roles: on Enterprise, Org Owners and Admins can create organisation-level and team-level custom roles. Make states that permissions are all or nothing per resource type and recommends a separate team where you need to limit access to particular resources. Some permissions depend on others, and a role cannot be deleted while users hold it. In practice this means: put production connections to finance, HR or identity systems in their own team with a short member list, rather than trying to hide them inside a shared team.

Protect Owner and Admin accounts with your identity provider's phishing-resistant MFA through SSO, review them quarterly, and keep the SSO disable link and the Owner account under the same break-glass process you use for other SaaS super-admins. See the SaaS and OAuth App Governance Guide.

Integrations, API tokens and service accounts

Connections

A connection is a stored credential (an OAuth grant, API key, username and password, or certificate) that Make uses on behalf of the team. Each connection is a non-human identity with the permissions of the account that authorised it. The most common pattern in Make estates is a builder authorising a connection with their own admin account in the target SaaS, which then outlives their role. Prefer connections authorised by a dedicated integration account in the target system with only the scopes the scenario needs, and record an owner for each.

Credential requests: Make's credential request feature lets a requester specify the apps, modules and connections a scenario needs and send a link to the credential owner, who authorises directly in Make. Make states that requesters cannot see passwords, API keys or OAuth credentials. Team Members can request from their team, Team Admins from the organisation, and only Organisation Admins and Owners can send requests to people outside the organisation, who join as Team Guest. Recipients can revoke access per app from the Sent tab, and declining or deleting a request removes access. Requesters must have the feature enabled; Make lists Partner or Enterprise accounts with a corporate email as eligible, approved by Customer Care. Use it to keep system owners in control of the accounts behind connections.

Make API tokens

API tokens are created per user under Profile, API, Add token, with a label and a set of scopes, and are shown only once. A user with access to several Make zones needs a separate token for each zone. Scopes come in read and write pairs: a :read scope allows only GET requests, a :write scope allows POST, PUT, PATCH and DELETE.

Because tokens belong to a person, they keep that person's team access. Label each token with its purpose and owner, store it in a secrets manager, remove tokens when people leave, and include Make tokens in secret scanning patterns. See the API Key Management Guide.

Webhooks

Make webhooks receive data over HTTPS and queue it for the scenario. The URL alone is the default credential, so a leaked webhook URL lets anyone inject data into an automation. The custom webhook settings documented by Make close that gap:

• API Key authentication: callers must send the key in the x-make-apikey header. Key values cannot be viewed after creation, and Make sanitises the header so scenarios never receive it.
• IP restrictions: a comma-separated allowlist, CIDR notation supported. Left empty, requests from all IPs are accepted.
• Data structure: validates incoming data; failing requests are rejected with HTTP 400.
• Get request headers: exposes caller headers for mapping, which you need if you verify a sender's own signature header in the scenario.

Make documents a limit of 300 requests per 10 seconds per webhook (HTTP 429 beyond that) and deactivation of webhooks not connected to a scenario for more than 120 hours (HTTP 410). Where the sending system signs its webhooks, verify the signature in the scenario before acting. See the Webhook Secrets Security Guide.

Data stores and keys

Data stores are Make's built-in database for sharing data across scenarios, with data structures defining their format. They are team-owned resources, so anyone with team rights to data stores can read every record. Do not use them for secrets or regulated data unless that team is restricted. The Keys feature holds keys and certificates used by encryption, signing and some connection types; treat it like a connection.

AI agents

Make AI Agents use an LLM to decide which tools to call. Make documents three tool types: module tools (Make builds a small scenario around one or more modules), scenario tools (a scenario you build with defined inputs, outputs and filters), and MCP tools (tools from an MCP server). Context files are split into chunks and stored in Make's RAG vector database. Make's best practices state that the best precaution is to assume anyone could access what you share with an agent, recommend filtering inputs before the Run an agent module, defining explicit scenario inputs and outputs, using a blank thread ID when past conversation is not needed, and capping Max Output Tokens and execution steps. Make also notes that system prompt constraints may not always be followed.

From a security standpoint this means: prefer scenario tools with narrow, typed inputs over module tools wrapped around a powerful connection; never give an agent a write-capable connection to a system of record without a human approval step built into the scenario; and keep sensitive files out of agent context if users who should not see them can talk to the agent. See the OWASP LLM Top 10 LLM06 Excessive Agency Guide and the Prompt Injection Guide.

Logging and detection

Audit logs can be filtered by timeframe, event type and user. Alert on: new connections or connection updates in restricted teams; scenario creation or changes by users outside the expected builder group; role changes to Team Admin, Org Admin or Owner; credential requests sent to external recipients; webhooks with no IP restriction or API key; and scenarios deactivated after repeated errors, which can mean a revoked or abused credential. On the target side, watch the integration accounts behind Make connections in each SaaS audit log: calls from Make's egress range outside known scenarios are a signal.

Metrics that show the programme is working:

• Percentage of connections with a named owner and a dedicated integration account (target 100% in restricted teams).
• Number of users holding Org Admin, Owner or Team Admin, trended quarterly.
• Percentage of custom webhooks with API Key authentication or IP restrictions enabled.
• Percentage of scenarios handling personal data with Keep data confidential on.
• Count of Make API tokens older than your rotation period or owned by leavers (target zero).
• Number of AI agents with write-capable tools and no human approval step.

Hardening baseline

1. Inventory first. Using a read-only token with scenarios:read, connections:read and hooks:read, list scenarios, connections and webhooks per team. Record the target system and authorising account for each connection.
2. Turn on SSO. Reassign resources owned by existing same-email users, configure SAML or OIDC with a default team of none, claim your domain, and store the one-time disable link in your break-glass vault.
3. Restructure teams. Move connections to sensitive systems into restricted teams. Replace Team Restricted Member assignments. Give operators Team Operator and auditors Team Monitoring rather than Team Member.
4. Rebuild risky connections. Re-authorise connections that use personal admin accounts with dedicated integration accounts and minimum scopes, using credential requests so system owners authorise them. Delete unused connections.
5. Lock down webhooks. Add API Key authentication, IP restrictions where the sender has stable addresses, and a Data structure to every custom webhook. Rotate any webhook URL found in tickets, chat or code by replacing the webhook.
6. Protect data in logs. Enable Keep data confidential on scenarios moving personal, payment or secret data. Note Make's warning that it leaves limited options for fixing errors, and decide where Store incomplete executions is acceptable, since stored executions retain data.
7. Govern AI agents. Require scenario tools with typed inputs, a human approval step for write actions, step and token caps, and a review of context files before an agent goes live.
8. Feed logs out. Review audit logs weekly at minimum, and export events to your SIEM by whatever route your contract supports.

Rollback: keep the SSO disable link and an owner account tested; when restructuring teams, move a scenario and its connections together and run it once before deactivating the original, so you can switch back if a connection fails.

Small versus large organisations: a small team on a non-Enterprise plan without SSO, audit logs or custom roles should rely on built-in team roles, strong unique passwords with the social provider's MFA, webhook API keys and IP restrictions, and a monthly manual review of connections. Large organisations should treat Make like any other privileged SaaS: SSO only, restricted teams per business domain, audit log monitoring and connection ownership attestation.

Framework mapping

Common misconfigurations

• Connections authorised with a builder's personal admin account. The scenario keeps working after the builder changes role, with far more access than it needs, and the owner of the target system never approved it.
• Custom webhooks with no API key and no IP restriction. The URL appears in a ticket or browser history and anyone can trigger the automation behind it.
• One large shared team. Because permissions are all or nothing per resource type, every Team Member can use every connection, including the HR or finance one.
• Payloads left in logs. Without Keep data confidential, execution and webhook logs keep personal data and tokens passed in headers, readable by Team Monitoring holders.
• Long-lived personal API tokens in scripts. A token with scenarios:write in a repository lets an attacker modify automations that already hold trusted connections. See the Git Secret Scanning Guide.
• Agents given broad module tools. An agent with a write-capable connection and no approval step can be steered by injected content in an email or document it reads.

Practitioner checklist

• Enable organisation SSO and store the one-time disable link and Owner account under break-glass controls.
• Limit Org Owner, Org Admin and Team Admin to named people and review them quarterly.
• Split sensitive connections into restricted teams; assign Team Operator or Team Monitoring where editing is not needed.
• Give every connection an owner and a dedicated, least-privilege integration account; use credential requests for third-party systems.
• Enable API Key authentication, IP restrictions and Data structure on every custom webhook.
• Turn on Keep data confidential for scenarios that move personal or secret data.
• Scope Make API tokens to read pairs where possible, store them in a secrets manager and revoke leavers' tokens.
• Require typed scenario tools, step caps and human approval for AI agents with write actions.
• Review audit logs and alert on connection, role and webhook changes.

Standards and references

• Make: Security
• Make Help Center: Teams and team roles
• Make Help Center: Single sign-on
• Make Help Center: Credential requests
• Make Apps: Webhooks
• Make Developer Hub: API scopes
• Make Help Center: AI agent best practices
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Webhook Secrets Security Guide · API Key Management Guide · NHI Ownership Guide