Feature Requests

It would be helpful to be able to assign roles to groups, so that members of those groups got those permissions. Members of multiple groups would get all of the permissions of those roles. This would allow tenants with SCIM set up to manage roles on the IdP side.

Full Conversation-Level Audit Log What we need: Admin-accessible logs that capture, per user: Full conversation input (user prompt) Full conversation output (AI response) Timestamp (UTC) User identity (linked to SSO/directory) Model/agent used Session ID Why: Under SEC Rule 204-2, AI-assisted communications that relate to investment advice or client correspondence must be retainable and producible on demand for up to 5 years. Usage/credit metrics alone are not sufficient. Examiners will ask: "Show me what your analyst asked the AI and what it returned on this date." Requested format: Exportable via admin dashboard (CSV or JSON); ideally accessible via API for automated archiving pipelines. --- Tamper-Evident / Immutable Log Option (WORM-Compatible Export) What we need: An option to export audit logs in a tamper-evident format — either: Cryptographically signed exports (hash-verified), or A direct integration/webhook to WORM-compliant archiving platforms (Global Relay, Smarsh, Microsoft Purview) Why: SEC Rule 204-2 requires records to be "true and accurate." WORM compliance (Write Once, Read Many) is the established standard for electronic records. Hatz itself does not need to be the WORM archive — but it needs to produce exports that can feed into one. A signed, hash-verified export would satisfy the "audit trail alternative" standard. The more regulated industries NEED these. Hopefully it is easily doable via the API and we can build our own audit log if we can get the history.

Allow admins to be able to enable/disable specific integrations (e.g. X, Reddit, etc.) at the tenant level. After a few conversations with different cybersecurity leaders during demos, this was a question that continually came up. It should be at the tenant level since Company XYZ may only want MS365 type integrations, where company ABC may only want Google integrations and non-social media type integrations, as an example.

Can you create an option for Administrator to be able to hide the Available Integration under Tools?

Further to just blocking Community Access, is there a middle ground, I found quiet a bit of inspiration and ideas from looking at the community workspace, even posted a few of my own. I noticed and from one of the comments on a past round table session there is limited control to what can be posted. In a perfect world having some form of admin review before an agent is shared with the community would help tremendously.

I am inquiring about the possibility of having more control over who can access community workflows. We would like to ensure that not everyone in our office has access to these workflows, but rather only specific roles or groups. This would allow us to benefit from the new features rolled out within the community while maintaining control over the process. By doing so, we can prevent staff from randomly grabbing and adding features without proper oversight.

Add visibility into who created and last updated each app would help admins manage shared content more effectively. When many users build and share apps, it can be difficult to identify ownership or know who to contact with questions. Showing basic metadata like the original creator and most recent editor would make this clearer and reduce unnecessary back-and-forth. This would be especially useful when an app is accidentally shared company-wide. With creator details available, admins could quickly confirm whether the app should stay public or be restricted, improving oversight and keeping the app catalog organized.

being able to see and export a list of all users in a tenant