Multi-agent attack tools leave no stone unturned

Executive Summary

Multi-agent offensive security frameworks like ARTEX and Cairn leave no stone unturned when tasked with identifying a path into a targeted organization.

In recent months, Okta Threat Intelligence has observed an explosion in agents performing both passive and active reconnaissance against targets. We have observed operators tasking agents to run lists of known usernames against the sign-up, sign-in, and recovery endpoints targeted tenants, allowing agents to learn where and how users authenticate. Where available, the agents register fraudulent probe accounts that test these authentication flows for potential misconfigurations. Agents are relentless, and there is no flow that they leave “unprobed” during these attacks.

Misconfigurations are now much easier to discover. Agents quickly identify and exploit overscoped tokens, wildcarded callback URLs, weak grant types, or lack of signature validation. These multi-agent frameworks can run for as long as a threat actor is willing to pay for tokens. We have observed some attacks in which worker agents executed these tests for over 390 hours.

This explosion in active reconnaissance requires every organization to identify and remediate client misconfigurations before agents find and exploit them. Various tools are available to facilitate this, as outlined below. Organizations should audit both third-party applications that use Okta for identity as well as first-party client applications that are used for sensitive operations. Okta Workflows is a first-party client application with permissions and scopes that can perform privileged operations against management APIs, making it a priority to lock down.

Workflows: No flow left unprobed

Identity teams increasingly rely on no-code/low-code tools like Workflows, Auth0 Actions, and third-party alternatives to automate onboarding, offboarding, access requests, and notifications, as well as integrations with HR, ITSM, and security tools. These automations often run with significant privileges, and can optionally be called from outside the application boundary via HTTP requests. Given the current threat landscape in which agents are probing every possible flow, defenders need to consider how an automation could result in the unintentional exposure of sensitive information. We discuss key considerations for locking down Workflows below.

Lock down invoke URLs

An invoke URL is created when a Workflows administrator configures a flow that can be triggered (“invoked”) via an external client using the API endpoint card. Invoke URLs can be secured using OAuth 2.0 or client secrets, but administrators can optionally choose a security level of None (public service). When this is selected, anyone with access to the invoke URL can both run the flow and review its output, even if they are not authenticated. Okta provides the following warning about risks of this option in the Workflows console:

“This flow can be run by any person or service with access to the URL. It is recommended to use another security option for production flows.”

The warning is provided because invoke URLs are designed to be triggered by external clients. The security of the flow relies on securing both the client configured to use it, and also securing how the URL might be accessed. For example, the invoke URL might be communicated in tickets or chats, pasted to a clipboard, or captured in browser histories and client application logs.

An attacker with access to a publicly exposed invoke URL that does not require authentication can use it to invoke (“run”) flows. Invoking a flow may not present a risk in some use cases. Some systems can send a request but can't authenticate, such as a webhook from a tool that supports neither OAuth 2.0 nor a client secret, so a public invoke URL is the only way they can reach a flow. Open registration forms are another example, because anyone, including people with no account, must be able to submit them. A flow that returns only non-sensitive, read-only data and uses no connections with meaningful privileges also carries little risk when it is public. Invoking a flow becomes risky when it modifies identity data or returns sensitive data in the client output, so administrators must carefully review what each flow with a public invoke URL can reach.

We recommend that administrators:

• Select Secure with OAuth 2.0 for any flow that touches identity data or performs privileged actions.
• Reserve None (public service) for flows that have been reviewed and confirmed to have no access to sensitive data or privileged actions.

Keep client tokens out of URLs

If a Workflows admin chooses to secure a flow with a client token, Okta generates a random, unique static API token that can be passed as either a clientToken query parameter or in the x-api-client-token HTTP header. Admins can regenerate this token at any time.

There are known risks associated with passing a long-lived token in a query string. URLs can be logged by web servers and proxies, cached by browsers, shared in screenshots, and captured by monitoring tools. This leaves them open to discovery and analysis by AI agents, which tend to be adept at constructing legitimate requests using that token.

We recommend that administrators:

• Pass client tokens in the x-api-client-token header, never in the URL.
• Regenerate a client token whenever the flow is modified in a way that changes its threat model, or whenever a token may have been exposed.

Apply least privilege to console access 

Accounts that can access the consoles of automation tools such as Workflows are highly prized by attackers. For this reason, we recommend applying the principle of least privilege by assigning the Workflows Administrator role instead of Super Administrator for administration of Workflows. A Workflows administrator can in turn assign specific roles and permissions to Workflows users as required. 

On October 27, 2026, Okta announced the availability of folder-level RBAC and folder-scoped connections for Workflows. Roles and permissions can now be assigned by Folder (groups of workflows), segmenting access to specific departments or projects. Administrators can also create a differentiated set of connections for each of those folders based on the scopes they each require.

We recommend that administrators:

• Use the new folder roles to create unique connections for each “folder” (group) of Workflows. This limits the “blast radius” if a client secret or public invoke URL is compromised.

Apply least privilege to connections

From an authorization perspective, Workflows’ access to Okta resources is managed at both the app and connector level.

First, when Workflows needs to access Okta resources, it does so via the Okta Workflows OAuth app. This is a global setting that only the Super Administrator can modify. To achieve least privilege, the administrator using this role to grant API scopes must know all of the API scopes required by the organization’s use of Workflows. If none of the flows in an organization require a given scope, the scope should be denied globally.

Scope should also be constrained at the level of a Workflows connection, which can be configured by the Workflows Administrator or the Connection Manager. 

We recommend that administrators:

• Only use default scopes to test new flows in Preview. Switch to using customize scopes to limit each connection to the scopes it requires prior to establishing the connection in a production org.
• Review and revoke unused scopes granted on the Okta Workflows OAuth app.
• Reauthorize connections after any change in scope. Changes to granted scopes only take effect when the connection is reauthorized.

Validate what comes in, and minimize what goes out

Validating untrusted input is essential to application security. Flows that accept data from an external client should anticipate abuse and, therefore, validate the expected input.

Administrators should also test what values are passed back to the caller of a flow. Workflows returns the full output of the final card in a flow to the caller, irrespective of what output is selected in that final card. (NB: the “output” field in a card only controls what gets passed to the next card in a flow.) 

We recommend that administrators:

• Insert a Return card at the end of a flow to control what values are returned to the calling client.
• Validate input against what the flow expects before using it, and reject anything that doesn't match. 
• Construct responses explicitly, returning only the fields the calling client needs. Use the Return card to control exactly what values you want returned to the calling client. Wherever possible, return generic error messages to external callers.

Keep secrets out of cards, tables, and execution history

Workflows makes it easy to call any HTTP API. Flow builders must avoid any scenario in which an API token or bearer token is entered directly into a card or saved to a table. 

We recommend that users:

• Restrict credentials to configuration of a connector, rather than pasting them in cards.
• Audit execution history and tables for secrets or sensitive data, and disable history on flows that handle them outside of active troubleshooting.
• Require peer review before importing flows into a production org, including a check for hard-coded secrets.

Conclusion

Given the current threat landscape in which agents easily find any misconfigurations, organizations must leave no stone unturned as they lock down tools in their environment. The security best practices that apply to software engineering apply equally to low-code and no-code tools. We recommend applying the same principles outlined above to any automation tools used in your organization. 

The following open source tools can be used to identify exposed secrets and misconfigurations: