Article body
Full article
A Data Agent can query data, create resources, and trigger actions for a user. It inherits every security concern of the BI platform and adds the risk of automated execution. If a multi-tenant SaaS product verifies identity only at the chat entry point, later tool calls can cross data boundaries.
The governing principle is straightforward: every tool call must answer who is acting, in which tenant, against which resource, and with what authority. The decision and its result must remain in the audit chain.
Carry Trusted Identity on Every Call
When an agent runs a query, reads a metric, or creates a dashboard, the backend must re-evaluate tenant, user, and resource permissions. It must not send model-generated SQL directly to the database or trust a tenant ID supplied by the client. The query service should inject tenant filters, row-level rules, and field restrictions from trusted identity context.
A secure call path usually includes:
- An identity gateway validates the user session and tenant membership.
- A policy service combines application, data, and function permissions.
- The tool layer validates parameters, resource state, and operational risk.
- The query or write service executes with a least-privileged identity.
- The audit service records policy decisions, inputs, results, and approvals.
None of these checks can be skipped because the caller is an agent.
Join Three Permission Layers at One Decision Point
| Permission layer | Controlled objects | Decision |
|---|---|---|
| Application | Spaces, portals, dashboards, and reports | May the user enter and view the resource? |
| Data | Rows, fields, connections, and metrics | Which data and definitions may the user see? |
| Function | Modeling, export, publishing, and tool calls | Which actions may the user perform? |
Permission to view a dashboard does not imply permission to export its details. Permission to ask questions does not allow the agent to change a metric definition. The three layers must converge in a server-side, default-deny decision.
Sensitive actions should use narrowly scoped tools. Resource creation, wider sharing, cross-system writes, and bulk export need approval or explicit confirmation. Administrators also need a global kill switch, deny lists, and emergency revocation so that sessions and tokens can be terminated immediately.
Shared and Dedicated Isolation Are Business Choices
A shared database reduces operating cost, but every read path must pass through a common tenant filter. A database per tenant offers stronger physical isolation but increases upgrade, connection, and cross-tenant operational costs. A platform can combine both models by customer tier, provided the security contract identifies where data resides, who can access it, and how backup and migration work.
Isolation must also cover caches, search indexes, object storage, and job queues. Protecting only the primary database still leaves export files, logs, and asynchronous jobs as possible leakage paths.
SSO Provides Identity Consistency, Not Just Login
Enterprises already use SAML, OAuth, or OIDC identity providers. A BI PaaS should reuse the enterprise IdP and map organization, role, and tenant attributes into platform policy. Embedded deployments also need secure token exchange between the host application and BI component without exposing long-lived credentials to the browser.
Session policy includes expiration, revocation, device limits, and anomalous-login detection. A long-running agent task cannot rely on an indefinite token. The executor must recheck authorization at critical steps. If policy changes during execution, the task should stop, fall back to read-only behavior, or request confirmation again.
An Audit Record Must Answer Six Questions
A complete agent audit record identifies:
- who started the task and in which tenant;
- the user’s business goal;
- the tool and tool version the agent called;
- the resources that were read or changed;
- the policy decision and approval result;
- the final result, error, and compensation action.
Prompts and intermediate reasoning can be reduced according to compliance policy, but tool parameters, authorization decisions, and resource changes must remain traceable. Sensitive fields should be redacted before logging. Tokens, secrets, and complete personal records do not belong in event streams.
Expand from a Read-Only Boundary
A production rollout can follow the risk boundary:
- Start with read-only questions over governed datasets.
- Add reversible resource creation with mandatory Dry Run.
- Connect approval to permission changes, export, and cross-system writes.
- Replay high-risk tasks to detect overreach, duplicate execution, and anomalous export.
- Continuously test tenant separation, revocation, and audit completeness.
Automation should expand only after permission and audit controls are mature. Data Agent security is not a property of the chat component; it is the combined result of the platform control plane.
Engineering Details
1. Multi-Tenant Architecture
1.1 Why a BI PaaS Needs Multi-Tenancy
Multi-tenancy lets one software instance serve several organizations while isolating their data and platform state.
| Dimension | Single-tenant model | Multi-tenant model |
|---|---|---|
| Deployment cost | One instance per organization | Shared infrastructure |
| Data isolation | Physical isolation by default | Isolation enforced by the platform |
| Version management | Versions can fragment across instances | One controlled upgrade path |
| Resource utilization | Capacity follows each instance | Capacity can be scheduled across tenants |
HENGSHI SENSE introduced tenant creation in v5.1.2. By v6.2, the platform covered tenant creation, licensing, workspace policy, organization management, and decommissioning.
1.2 Platform Layout
HENGSHI SENSE BI PaaS
├── Tenant A: workspace, groups, sources, applications
├── Tenant B: workspace, groups, sources, applications
├── Tenant C: workspace, groups, sources, applications
├── Tenant isolation: data, permissions, identity, configuration
└── Shared infrastructure: licenses, SSO, security policy, audit1.3 Tenant Lifecycle
Each tenant has its own workspace and user system. A PaaS license can define tenant limits, feature grants, user limits, and expiration dates.
license:
type: paas
tenant_limit: 50
tenants:
- id: tenant_hq
name: "Headquarters"
user_limit: 500
features: ["advanced_analytics", "data_export", "api_access"]
expires_at: "2026-12-31"
- id: tenant_east
name: "East China Branch"
user_limit: 200
features: ["basic_analytics", "data_export"]
expires_at: "2026-06-30"Version 6.1.1 added stronger workspace separation for embedded analytics. Administrators can hide the personal workspace, rename the team workspace, and assign administrator, analyst, or viewer access.
Organization APIs in v6.0.5 support bulk updates and moving a child node to the root:
POST /api/organization/batch
{
"operations": [
{
"action": "move_to_root",
"node_id": "dept_1024",
"tenant_id": "tenant_east"
},
{
"action": "update",
"node_id": "dept_2048",
"name": "New Business Line",
"parent_id": "dept_1024"
}
]
}Version 6.0.1 replaced a global license lock with tenant-level and user-level locks. The smaller lock scope removes cross-tenant contention and reduces deadlock risk.
acquire(tenant_license_lock[tenant_id])
→ validate tenant license
release(tenant_license_lock[tenant_id])
acquire(user_license_lock[user_id])
→ validate user license
release(user_license_lock[user_id])2. Three-Dimensional Authorization
2.1 Model Evolution
v5.1.x Basic roles and connection row permissions
v5.2.8 Global strict permission checks and inheritance review
v6.1.0 Unified application, data, and function permissions
v6.1.5 Consolidated metric-analysis and data-viewer roles2.2 Three Independent Dimensions
| Dimension | Controlled objects | Example |
|---|---|---|
| Application | Dashboards, reports, and application modules | View or edit the Sales Analysis application |
| Data | Connections, tables, and fields | Read the Amount field in Order Details |
| Function | Product functions | Export data or call an API |
The platform evaluates all three dimensions together. Access to an application does not grant access to all underlying data or functions.
2.3 Tenant-Level Row Authorization
PUT /api/permissions/row-level
{
"connection_id": "conn_sales",
"table": "sales_table",
"tenant_id": "tenant_east",
"rule": {
"type": "filter",
"expression": "region = 'East China'"
}
}2.4 Deduplicated Dimensions in Permission Filters
A user may receive overlapping rules from department and role membership. The permission filter applies dimension deduplication in both data-filtering and metric-filtering paths, then returns one consistent authorized dataset.
3. Enterprise SSO
3.1 Integration Matrix
| Provider or mode | Protocol | Introduced | Use case |
|---|---|---|---|
| Authing.cn | SAML 2.0 | v5.1.10 | Enterprise identity management |
| Microsoft Teams | OAuth 2.0 | v5.4.10 | Microsoft 365 integration |
| Tenant custom domain | SAML or OIDC | v5.3.4 | Tenant-specific identity domain |
| Feishu | OAuth 2.0 | v6.0.0 | Feishu ecosystem |
| DingTalk | OAuth 2.0 | v6.0.0 | Alibaba ecosystem |
| WeCom | OAuth 2.0 | v6.0.0 | Tencent ecosystem |
| JWT enhancements | JWT | Multiple releases | API authentication |
3.2 Unified Access Token Management
Version 6.0.0 brought Feishu, DingTalk, and WeCom access tokens into one manager. The manager stores tokens, refreshes expiring credentials, retries failed refreshes, and maps platform identities into one session service.
3.3 Tenant Custom-Domain SSO
server {
listen 443 ssl;
server_name bi.tenant-a.com;
location / {
proxy_pass http://hengshi-sense:8080;
proxy_set_header Host $host;
proxy_set_header X-Tenant-Id tenant_a;
proxy_set_header X-SSO-Domain bi.tenant-a.com;
}
}The host name selects the tenant identity configuration in embedded deployments. Users reach the correct identity provider without seeing another tenant’s login entry point.
3.4 Default SSO Roles
sso:
provider: authing
config:
saml_endpoint: "https://xxx.authing.cn/saml"
default_role: "analyst"
default_tenant: "tenant_hq"
auto_create_user: true
role_mapping:
- attribute: "department"
value: "IT"
role: "admin"
- attribute: "department"
value: "Sales"
role: "analyst"3.5 Authing SAML Flow
HENGSHI SENSE sends a SAML AuthnRequest to the Authing identity provider. After authentication, Authing returns a signed assertion. HENGSHI SENSE validates the assertion, maps the tenant and role, creates a session, and returns the authenticated BI page.
4. Architecture Trade-Offs
4.1 Shared and Dedicated Databases
HENGSHI SENSE uses a shared-database model with tenant filters injected at query time. It lowers cost and operating complexity while placing a strict requirement on every query path. A database-per-tenant model provides stronger physical separation but increases upgrade, connection, and cross-tenant operating cost.
4.2 Protocol Selection
| Protocol | Strength | Constraint | HENGSHI SENSE use |
|---|---|---|---|
| SAML 2.0 | Established enterprise standard | Complex XML configuration | Authing and enterprise IdPs |
| OAuth 2.0 | Broad SDK support | Requires a separate user-information flow | Feishu, DingTalk, and WeCom |
| JWT | Stateless API credential | Revocation needs another mechanism | API authentication |
4.3 Security and Usability
- Active Cookie policy limits device count and lets administrators clear abnormal sessions.
- Login lockout can use exponential backoff instead of one long lock.
- Watermark policy can be set per application.
- Row permissions run in the service layer without extra user steps.
5. Operating Practices
Tenant operators should divide tenants by business boundary, reserve license capacity, and reclaim idle tenants. Permission owners should start with least privilege, evaluate all three permission dimensions, consolidate redundant roles, and enable strict permission checks. Identity owners should reuse the enterprise IdP, assign default SSO roles, and use tenant-specific SSO domains for embedded analytics. Security teams should configure lockout policy, device limits, watermarks, and controlled CORS access.
Source and Verification Note
Internal material was used to organize HENGSHI capabilities and engineering methods. Competitor and version information was checked against official pages available on August 26, 2026. Features can vary by release, region, license, and deployment mode; confirm them in the target environment before purchase or publication.
Further reading: HENGSHI SENSE Product and Technology White Paper.