Torq

C Torq hyperautomation platform

Workloads call the Torq REST API by trading a static client ID and secret for a one-hour bearer token; no OIDC or workload identity path exists. New keys must carry an expiry, can be role-scoped and show last use, but deleting them is UI-only and GitHub does not scan for them. Into your cloud, AWS is keyless via an IAM role with external ID; GCP wants a service-account JSON key and Azure a client secret.

Docs: kb.torq.io · Checked 2026-10-22 · source YAML · dispute via PR

Inbound C

How a workload running anywhere authenticates to this product.

OAuth2 client_credentials: a static Torq API key (client ID and client secret, personal or service account) is posted to auth.torq.io/v1/auth/token for a bearer token valid one hour, used on the public REST API and the Torq steps integration. No federation path.

learn.torq.io checked 2026-10-22
“In the request to the authentication server, provide your Torq API key, which consists of a client ID and client secret.”
learn.torq.io checked 2026-10-22
“curl POST https://auth.torq.io/v1/auth/token -H "Accept: application/json" -H "Accept-Language: en_US" -u "<CLIENT_ID>:<CLIENT_SECRET>" -d "grant_type=client_credentials"”
learn.torq.io checked 2026-10-22
“A bearer token is valid for one hour (3,600 seconds).”
learn.torq.io checked 2026-10-22
“The Torq REST API allows you to programmatically manage resources such as workflows, users, and secrets from outside the Torq platform.”
kb.torq.io checked 2026-10-22
“To incorporate Torq vendor steps in your workflows or use the Torq API, you must first create a Torq integration instance or generate a bearer token. This process requires API key credentials: a client ID and a client secret.”
kb.torq.io checked 2026-10-22
“When a key is created, Torq generates a Client ID and Client Secret together, and neither value can be updated independently.”

Short-lived tokens bootstrapped from a long-lived client secret is C (static root). Checked the API reference index (developers.torq.io/llms.txt), the authentication page and the KB: the token endpoint documents only grant_type=client_credentials with a client secret, and no OIDC token exchange, GitHub Actions, cloud workload identity or private_key_jwt path exists. The SSO claim-mapping endpoints and Okta/Entra OIDC guides are for human login. Webhook triggers into Torq use a generated shared-secret header, also static. Inbound moves to B or A only if the token endpoint accepts a federated JWT from GitHub Actions, a cloud, or an issuer you configure.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

AWS steps assume an IAM role you create that trusts Torq with a required External ID (and can chain sts assume-role into other accounts); Slack and Microsoft 365 Delegated Access are consent flows to Torq's own apps. GCP wants a service-account JSON private key, Azure CLI, Microsoft 365 app-only, Defender and Sentinel want an Entra app client secret, and AWS REST API (SigV4) steps take IAM user access keys.

kb.torq.io checked 2026-10-22
“AWS integrations use an AWS IAM role that you define in your AWS IAM configuration.”
kb.torq.io checked 2026-10-22
“To create an IAM role in AWS, you need the Torq Workspace ID and the AWS External ID that are located in Torq.”
kb.torq.io checked 2026-10-22
“STS allows a single AWS Step integration instance to be used for multiple AWS accounts, reducing the number of integration instances that need to be created.”
kb.torq.io checked 2026-10-22
“Via the AWS REST API integration with user access keys as SigV4 credentials”
kb.torq.io checked 2026-10-22
“Save the private key for later—you will use it when creating the GCP integration in Torq.”
kb.torq.io checked 2026-10-22
“Paste the client secret you generated”
kb.torq.io checked 2026-10-22
“Paste the Client Secret you retrieved earlier.”
kb.torq.io checked 2026-10-22
“The Microsoft 365 Delegated Access integration is a Microsoft-sanctioned Enterprise app that allows users to grant Torq access to the resources that their own Microsoft 365 account can access.”
kb.torq.io checked 2026-10-22
“The Slack steps integration adds the Torq bot (Torq app) to your workspace, which enables you to perform common Slack actions as part of your workflows and trigger Torq workflows directly from the Slack CLI by mentioning (@) the Torq bot or sending a message directly in the Torq app channel.”
kb.torq.io checked 2026-10-22
“Copy the key to save it for later. You will need it to set up custom secrets in Torq.”
kb.torq.io checked 2026-10-22
“API tokens inherit the same permissions as the user who creates them, and if the user permissions change, the API token permissions also change.”
kb.torq.io checked 2026-10-22
“Ensure the secret ID you create for the role is long-lasting by setting the secret_id_num_uses and secret_id_ttl parameters to 0.”

Checked: AWS steps (also S3 and Redshift steps, and the S3 audit-log export, which reuse the AWS integration): keyless, cross-account role with Require external ID, CloudFormation template offered. AWS REST API integration for SigV4 HTTP steps: static IAM user access key (the same page offers the assume-role alternative). GCP and Google Cloud Pub/Sub: a service-account JSON private key uploaded to Torq (with domain-wide delegation for Workspace data); no impersonation or WIF option. Azure (CLI, Blob), Azure Key Vault, Microsoft 365 app-only, Defender for Endpoint and Sentinel: a single-tenant Entra app registration you create, with a client secret pasted into Torq; Azure even recommends Contributor. Microsoft 365 Delegated Access and Slack: consent to Torq's own multi-tenant apps, no customer secret (delegated to a user or service account). GitHub: a personal access token or a GitHub App private key stored as a custom secret. Okta and Jira: user-bound API tokens. HashiCorp Vault AppRole: a never-expiring secret ID, by Torq's own instruction. CrowdStrike: OAuth client ID/secret. Self-hosted step runners in your cluster were not found to offer ambient identity for steps in public docs (not publicly verifiable). B because AWS is keyless while GCP and Azure resource access require static secrets; GCP impersonation and an Azure federated credential on a Torq app would lift it to A.

Hygiene for any static credential the product still issues

✓ Expiry enforceable	Passes because the platform requires an expiration date on every new key (same call as sentinelone-singularity's mandatory expirationDate), not a changeable default. Caveats: no maximum lifetime or org policy cap is documented, the date can be extended at will through the UI or the Set API Key Expiration step, and legacy keys created before the rule still show "Never" until someone sets a date. kb.torq.io checked 2026-10-22 “New API keys require an expiration date at the time of creation.” kb.torq.io checked 2026-10-22 “If any keys were previously generated without one, they will remain valid and their expiration date will be listed as” learn.torq.io checked 2026-10-22 “The timestamp when the API key expires.”
✗ Rotation via API	Judgment call. The public REST API reference has only List API keys (GET /v1alpha/api-keys); no create or delete endpoint. Inside Torq, the Create a Service API Key and Set API Key Expiration workflow steps can mint a key and move an expiry, but Torq's own rotation guide says the old key is deleted manually in the UI, and no Delete API Key step or endpoint is documented. Shortening the old key's expiry with the step approximates revocation; a reviewer could count that. Public create and delete endpoints would flip this check. learn.torq.io checked 2026-10-22 “Returns a list of all API keys for the current workspace.” kb.torq.io checked 2026-10-22 “After validation, delete the old key manually via the UI.” kb.torq.io checked 2026-10-22 “The Create a Service API Key step requires the Owner role.”
✓ Scoped keys	Service API keys are machine principals not tied to a user, assigned a preset or custom role built from granular scopes, and limited to one workspace or selected workspaces. Personal keys act as their owner, which would not count on their own. kb.torq.io checked 2026-10-22 “However, they are more secure and efficient as they are not associated with any individual user.” kb.torq.io checked 2026-10-22 “When you build a custom role or a least-privilege service API key, use this table to find the scope behind a specific action.” kb.torq.io checked 2026-10-22 “Users own the private API keys they create.”
✓ Last-used visible	The List API keys response carries last_authenticated_time per key. Whether the API Keys page shows it in the UI is not publicly verifiable; the API field is enough to find dead keys. learn.torq.io checked 2026-10-22 “The timestamp when the API key was last used to generate an access token.”
✗ Leak revocation	Torq does not appear in GitHub's supported secret scanning patterns table, so a leaked Torq client secret is not reported to Torq for revocation. No other partner program is documented. docs.github.com checked 2026-10-22

Notes

One card for the Torq platform (workflows, cases, HyperSOC/Socrates); all programmatic access uses the same workspace API keys, so there are no materially different sibling products to split. Hygiene applies to Torq API keys: three of five pass (expiry, scoping, last_used), and the rotation_api fail is a judgment call flagged above. Hygiene does not change a C. Inbound moves up only with federation on the token endpoint; outbound reaches A with GCP service-account impersonation and keyless Azure (federated credential or Torq multi-tenant app for Azure resources).

Badge

[![wif.tax grade](https://wif.tax/badge/torq.svg)](https://wif.tax/p/torq/)