Workato Security: Locking Down Roles, Connections, Agents and API Clients

A Workato workspace stores live, authenticated connections to your ERP, CRM, HR system and databases, so anyone who can edit a recipe or call the API with a broad token can move data between all of them. This guide covers the controls that decide who and what can use those connections: environment and project roles, SAML enforcement, API clients, the on-prem agent, encryption key management and the activity audit log. Product facts come from Workato's own documentation, checked on 8 November 2026; hardening stances are NHI Mgmt Group guidance. It is written for integration platform owners, identity teams and security engineers responsible for an existing Workato workspace. For why integration connections should be governed as non-human identities, see the Service Account Security Guide.

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

Key takeaways

• Connections are the asset to protect. A connection is an authenticated non-human identity into another system; whoever can view the folder and edit recipes that use it can act with its rights.
• Use the new permissions model fully. Environment roles plus project roles let you keep developers out of production and limit each team to its own projects and connections.
• Replace legacy API keys with API clients. API clients belong to the workspace, carry a client role, can be scoped to an environment and projects, and can be restricted to allowed IP ranges.
• The on-prem agent is outbound-only, but its config file is a secret store. Encrypt passwords and private keys in config.yml or use an external secrets manager.
• Customer-managed keys are a kill switch. Revoking the key makes encrypted connection, job and log data unavailable across the workspace, so plan who may do it and when.

How identity and access work in Workato

Workato separates human collaborators from the machine identities that do the work. People sign in to the workspace and are given roles. Recipes run using connections, which hold the credentials or OAuth grants Workato uses to reach each application. Automated access to the platform itself uses API clients, and on-premises systems are reached through the on-prem agent (OPA).

Single sign-on: Workato supports SAML 2.0 with third-party identity providers, plus sign-in with Google or Microsoft Office 365 credentials, and just-in-time provisioning. The Enforce SAML authentication for all users toggle under Workspace admin > Settings > Login methods makes every collaborator except the workspace owner sign in through your identity provider. You cannot exempt individual users while it is on. Turn it on, enforce MFA in the identity provider, and treat the owner account as a break-glass credential held in your PAM tool. See the Identity Provider and SSO Security Guide and the Break-Glass Account Guide.

Admin roles and privileged access

Workato's role-based access control model uses environment roles (access to a whole environment such as DEV or TEST, created under Workspace admin > Access control > Environment roles), project roles (access to recipes, assets, folders and connections inside projects, created under Access control > Project roles) and collaborator groups. The legacy model has only workspace-level roles, with no collaborator groups or project-level permissions; Workato's FAQ states legacy collaborator roles worked until the end of August 2026, self-service migration closed on 31 August 2026 and Workato migrated remaining workspaces in early September 2026, so confirm your workspace now runs on the new model.

• Folder view exposes connections: the documentation notes View folders is required to see recipes and connections stored in a folder. Keep production connections in folders that only operators and deployment identities can view.
• Privilege dependencies: some privileges require others (for example Edit File Storage requires View File Storage). Review the combined effect, not just the headline privilege.
• Role edits are global: roles can be cloned through the UI or API, and changing a role changes every holder. Use groups and clones rather than editing a widely used role in place.
• System roles cannot be deleted: so the control is who holds them, not whether they exist. See the Least Privilege Techniques Guide.

Integrations, API tokens and service accounts

Connections

Workato encrypts each connection's data with a connection-specific key. That protects the secret at rest, but not against misuse by someone allowed to build recipes on it. The security of a connection depends mostly on the account behind it:

1. Dedicated integration accounts: authenticate each production connection with a service account or OAuth app created for Workato, never a person's own login, so the connection survives that person leaving and can be reviewed. See the Service Account Security Guide.
2. Least privilege in the target: scope the integration account to the objects the recipes need; a Workato connection with full admin in the CRM is a CRM admin.
3. Separate per environment: DEV connections point at sandboxes with separate credentials, so a test recipe cannot touch production data.
4. Owners and review: every production connection has a named owner and appears in your NHI inventory. See the NHI Ownership Guide.

API clients

API clients are created under Workspace admin > API clients. Each has a client role (the endpoints it may call), an optional environment, projects that limit which connections, recipes, folders, lookup tables and API Platform assets it can reach, and optional Allowed IP ranges. The token is shown once and cannot be retrieved later, and Workato advises storing it in a secrets manager. Regenerate token invalidates the previous token immediately; legacy API client tokens cannot be regenerated. Legacy full-access API keys, sent as an API key plus email, remain supported but Workato recommends migrating to API clients. Note that deleting a legacy client makes its key unrecoverable, so migrate callers first. See the API Key Management Guide.

Embedded partner API clients can reach all customer workspaces and projects, so treat any such client as the highest-value credential you hold.

On-prem agent

The OPA makes only outbound connections, a TLS WebSocket tunnel over TCP 443 to Workato's sg3 and sg4 gateway hostnames for your data centre, with no inbound firewall ports. The gateway and agent authenticate each other with mutual TLS; each agent holds a client certificate issued at activation and trusts only Workato's private certificate authority. TLS inspection tools that re-sign traffic break this chain, so the gateway FQDNs must bypass inspection. Agents can be grouped for high availability, and the on-prem group's Settings > IP Allowlist controls where agents may connect from.

Database passwords and private keys used by on-prem connections live in the agent's config.yml. Workato provides encryptor.cmd (Windows) and encryptor.sh (Linux and Mac) to write values as {encrypted: '...'}, using a key derived from that agent's private key, so an encrypted value only works on that agent. Workato recommends encrypting passwords and private keys, or using an external secrets manager instead. Restrict file system access on the agent host to the agent's service account and administrators. See the Secrets Management Guide.

Encryption key management

Workato encrypts stored data with AES-256. Under encryption key management, connection data uses a connection-specific key, job data an hourly key plus a job-specific data key, and logs a log key; data tables and Workflow apps data use filesystem-level encryption and are not covered by the customer main key. Workato-managed keys are rotated at least yearly. With a customer-managed key, enable auto-rotation in your KMS, as Workato recommends; manual replacement is allowed once per 24 hours. Revoking or deleting the customer key makes encrypted data unavailable to all users, permanently if the deletion is permanent, and because the key cache TTL is five minutes, data may stay readable briefly after access is restricted. Write that into your incident playbook. See the BYOK, HYOK and External Key Management Guide.

Logging and detection

The activity audit log records significant collaborator actions, including logins, invitations, recipe changes and recipe events, and labels actions taken through the AIRO assistant as "(via AIRO)" against the user. Entries are kept for one year by default and can be viewed by the workspace owner, the Admin role and holders of the Activity audit privilege. Audit log streaming (under Workspace admin > Settings > Log streaming) sends JSON over HTTP POST to destinations including Amazon S3, Azure Monitor, Azure Blob, Splunk, Datadog, Sumo Logic and Google Cloud Storage. With data masking enabled, trigger and action inputs and outputs are replaced by a "masked" placeholder in both the UI logs and streamed logs, which keeps business data out of your SIEM. Both features depend on plan. See the SIEM Guide.

Metrics:

• Number of Environment admin holders and custom roles with Workspace access privileges.
• Share of Developer API callers using API clients rather than legacy keys (target 100 per cent).
• API clients without Allowed IP ranges, and maximum token age.
• Production connections without a named owner or authenticated with a personal account.
• On-prem agents with unencrypted secrets in config.yml (target zero).

Hardening baseline

Rollout order:

1. Export collaborators, roles, API clients and connections; tag each connection with its owner and environment.
2. Enable audit log streaming first, so the rest of the change is recorded.
3. Turn on SAML enforcement after confirming every admin can sign in through the identity provider; the owner account remains your fallback.
4. Build environment and project roles, pilot them with one team, then move all collaborators; keep the old role assignments documented for rollback.
5. Create scoped API clients, switch callers one at a time, then delete legacy keys once traffic has stopped.
6. Encrypt or externalise OPA secrets, agent by agent, testing each on-prem connection before moving on.

Common misconfigurations

• Personal connections in production: a recipe running on an employee's own CRM login breaks or keeps working with excessive rights after that person changes role. See the Employee Offboarding Security Guide.
• One workspace role for everyone: staying on broad roles means every builder can edit production recipes and reuse production connections.
• Legacy full-access keys left in scripts: they cannot be regenerated, so rotating one means replacing it everywhere at once, and teams postpone it.
• API clients without IP ranges: a leaked token is usable from anywhere until someone notices.
• Plaintext config.yml: database passwords readable by anyone with access to the agent host.
• TLS inspection on the agent path: re-signing proxies break mutual TLS, and the usual workaround of disabling controls on the host is worse than a targeted bypass for the gateway FQDNs.

Practitioner checklist

• Enable Enforce SAML authentication for all users and vault the workspace owner credentials.
• Confirm the workspace uses the new permissions model, with no remaining legacy collaborator roles.
• Limit Environment admin and Workspace access privileges to a small named group, reviewed quarterly.
• Re-authenticate production connections with dedicated, least privilege integration accounts.
• Replace legacy API keys with API clients scoped by role, environment, projects and Allowed IP ranges.
• Encrypt passwords and private keys in every on-prem agent config.yml, or move them to a secrets manager.
• Stream the activity audit log to your SIEM with data masking and alert on admin role changes and root login.
• Document who may revoke a customer-managed key and the effect on running recipes.

Standards and references

• Workato: Role-based access
• Workato: API clients
• Workato: On-prem agent
• Workato: On-prem agent password encryption
• Workato: Encryption key management
• Workato: Activity audit log
• Workato: Single sign-on
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Service Account Security Guide · NHI Ownership Guide · API Key Management Guide · Secrets Management Guide