Frequently asked questions¶

Trust3 AI Governance is a control plane for AI agent data access across the enterprise. It helps you discover agents on connected platforms, map them to owners and invoker identities, maintain a unified inventory and dashboard, and run policy checks and audit-oriented reporting—so teams can answer “which agents exist,” “who can use them,” and “how that matches our rules” without stitching spreadsheets from every vendor admin console.

Traditional Protect-pillar tooling (network, endpoint, DLP, generic IAM) secures infrastructure and data paths broadly. Trust3 adds governance in the IT pillar sense: agent-level and identity-level visibility tied to platforms such as Databricks, Microsoft Copilot Studio, and Azure Foundry (and related Power Platform signals). You still need both; Trust3 does not replace firewalls or SOAR—it makes AI usage attributable and reviewable.

AI asset inventory is the normalized catalog of AI-related surfaces the platform tracks—agents, endpoints, Genie spaces, Copilot-related objects, and similar assets—plus relationships to identities (owners, service principals, invokers). It is the basis for the unified dashboard, policy evaluation, and GIA answers.

The AI Assets Collector is a Docker-based collector you run in your environment (see Run Collector). It uses credentials you configure in .env to call upstream platform APIs, then ingests discovered assets into Trust3 AI Governance (often using AI_GOVERNANCE_API_KEY, depending on your deployment). It does not require you to open your data warehouse to Trust3 for row-level reads as part of this flow—the focus is platform metadata about AI assets and identities.

Documentation and the collector today emphasize Databricks (for example serving endpoints and Genie spaces), Microsoft Copilot Studio, and Azure Foundry (and related Power Platform configuration or usage signals your tenant exposes). Custom applications can be represented through manual registration where automated connectors are not yet available. Exact coverage evolves with product releases—confirm against your tenant’s connector list and prerequisites / Microsoft Copilot Studio guides.

Identity mapping links each governed agent to the principals that own or invoke it, using metadata and logs from connected platforms. Some identities are short-lived or delegated. Trust3 models those as ephemeral and ties them to a parent principal so audits and incident reviews show who ultimately acted, not only a transient token identifier.

GIA (Governance Intelligence Agent) is Trust3’s AI governance agent: natural-language questions over your live inventory and identity graph—for example “What needs attention now?”, “Show high-risk AI assets”, “Explain trust score drop”, or “Which agents don’t have owners?”—plus actions such as drafting agent registration fields from a short description, importing policies from a document or URL (with human review before activation), and explaining violations with remediation guidance in plain language.

GIA is available from the GIA button in the header and on the Overview dashboard; sessions keep context as you navigate until you start a new conversation, close the drawer, or log out. Admin, Compliance, Legal, and Developer roles can use GIA; Viewer does not have access.

For full detail, see GIA — Governance Intelligence Agent.

Trust3 AI Governance provides five user roles, listed below from highest to lowest privilege:

If a user's IdP group is mapped to multiple AI Governance roles, Trust3 assigns the most privileged role rather than combining the permissions from multiple roles.

The role precedence, from highest to lowest privilege, is:

Admin → Legal → Compliance → Developer → Viewer

Example: If a user's IdP group is mapped to both ROLE_AI_GOVERNANCE_LEGAL and ROLE_AI_GOVERNANCE_DEV, the user is assigned the Legal role because it has higher precedence than the Developer role.

This precedence applies the same way across every SSO provider Trust3 supports. For a worked example of configuring group-to-role mappings, see Role Mapping for Azure AD.

Typical examples include required owner and description fields, approved model lists, tagging for sensitive data scope, and workflows to open and close violations when inventory drifts. The exact rule catalog depends on your Trust3 configuration; the platform compares observed inventory to declared organizational rules.

The AI Assets Collector path described in this documentation is aimed at platform metadata about AI assets and identity relationships, not bulk extraction of warehouse row data. Operational and contractual details for your tenant are covered in your agreement and Trust3 privacy materials. If you have a specific residency or logging requirement, involve your Trust3 account team.

For the current release, the collector is scheduled to run every 15 minutes while docker compose keeps the stack up. That cadence may change in a future version; use docker compose logs -f trust3-ai-assets-collector to confirm runs and watch for errors after platform or credential changes.

Yes. Add each workspace, and each Microsoft tenant service (Azure AI Foundry, Copilot Studio, M365), as its own connection from its tile on the runtime plane's Collectors tab. Shared connections run together, up to 10 in one pod; a Dedicated connection gets its own pod. See Collector Connections. Connections need a runtime plane on release 9.2.45.3 or later.

Each Databricks workspace, and each service of a Microsoft tenant, can have only one connection on a runtime plane, so the same source is never scanned twice. The message names the connection that already has it: use that connection, or delete it first. For Azure AI Foundry, two connections of one tenant are allowed when they use different client IDs. See One connection per workspace and per service.

Choose Shared for most connections: they share one pod and its settings. Choose Dedicated when a connection must not share a pod — for example, to keep one customer's credentials apart, or to give a large workspace its own resources. The mode cannot change after create; delete the connection and create it again. See Choose the Deployment Mode.

No. Existing collectors keep working as AI Assets Collector (Legacy), with their own pod and full form, and nothing is migrated. To move a workspace into a connection, add the connection and then remove the workspace from the old collector; do not leave it in both. See Existing collectors are unchanged.

Store it as a saved credential on the runtime plane and pick it in each collector. Editing the credential shows which collectors will restart, then updates all of them at once.

Trust3 offers cloud (SaaS) for fast time-to-value and options such as hybrid models where parts of the footprint run in your cloud for residency or isolation requirements. The collector always runs under your control with your credentials. See the installation guide and your account team for the model that applies to you.