Capabilities

Connectors provide access. Capabilities provide actions.

A connector establishes access to a tool. Its capabilities define what HexaHQ can do there. One connector can have many capabilities, and a workflow can use capabilities from several connectors.

If the required action does not exist yet, your AI can author a capability from the tool's API documentation. Once created, the capability can be reused in future work.

Allow, Ask, and Deny

Every capability is governed by a policy.

• Allow lets the capability run without a separate approval. This is commonly used for safe lookup and read actions.
• Ask pauses before the action runs and shows the user what HexaHQ is about to do. This is commonly used for actions that send, change, or delete information.
• Deny blocks the capability.

By default you can change the policy on a capability for yourself, and the change takes effect immediately for you and for nobody else. If a lookup you trust keeps asking, you can stop it asking without filing a request. Making your setting the answer everyone gets is the separate step of sharing it with the organization, which goes through review.

An organization that wants these settings centralized can limit the change to administrators in its settings. The Hub shows the control to whoever the organization allows to use it.

The policy is evaluated when the capability runs, so saving an action inside a workflow does not bypass review.

Identity and audit

A capability runs using the connection the person running it has to the source tool, so the source app enforces that person's own permissions. Some tools are connected once for the whole team instead, through a bot or a service account. Work through those runs as the bot, and the source app sees the bot.

Either way, HexaHQ records who asked, which capability ran, and any approval, in a run. Nobody ever borrows a teammate's personal connection.