=====================

Current Behavior:

=====================

When you set up an integration like ScalePad, the API key required to authenticate the integration is generated at the account level with no granular permission controls. The key either has full access or no access — there is no ability to scope it to read-only or restrict it to non-destructive actions.

Because of this, any user who has access to the ScalePad integration in Hatz AI inherently has the same level of access as the full API key, which includes the ability to modify or destroy data in ScalePad products like Lifecycle Manager.

This makes it impractical to share the integration with team members who need access to ScalePad data but should not have the ability to make destructive changes — even if those team members are the primary users of the platform.

=====================

Desired Behavior

=====================

Hatz AI should provide integration-level guardrails that allow administrators to enforce a read-only or test mode on a per-integration basis, independent of what the upstream API key technically permits. This would act as a platform-side safety layer that restricts the types of actions the AI is allowed to take through the integration.

Read-Only Mode: Prevents any write, update, or delete operations from being executed through the integration, regardless of API key permissions.

Test Mode: Allows the AI to simulate actions and surface what it would do, without actually executing any destructive or mutating operations.

These guardrails should be configurable at the tenant level, with the ability to override on a per-user basis for users who need elevated access.

=====================

Use Case

=====================

Our CRM team members are the primary users of ScalePad Lifecycle Manager, but the ScalePad API provides no granular permission scoping — any API key generated has full access to the account, including the ability to modify or delete asset and lifecycle data.

As a result, the ScalePad integration in Hatz AI cannot be safely provisioned to CRM team members, even though they are exactly the users who would benefit from it most. Without platform-side guardrails, sharing this integration creates unacceptable risk of accidental or unintended data destruction.

By introducing read-only and/or test mode guardrails at the Hatz AI platform level, organizations like ours could safely extend integrations to a broader set of users — limiting exposure when the upstream platform does not provide the granular controls needed to do so natively.