Article body
Full article
Natural-language analytics lowers the barrier to using data, but it also requires enterprises to recheck their data-access boundaries. Based on public HENGSHI product materials, this article explains identity and connection permissions, application data-permission modes, row and column permissions, public links, and the configuration and POC validation points relevant to Data Agent scenarios.
1. Why the Old Perimeter Is No Longer Enough
Traditional BI often uses reports, directories, and application access as entry points. Natural-language analytics reduces a user’s dependence on those established navigation paths. Report visibility alone is therefore not enough to determine the data boundary; identity, connection permissions, application data permissions, and dataset row and column permissions still need to work together.
In AI analytics, teams should verify that row and column permissions take effect as expected, the selected application data-permission mode matches the intended distribution model, public links are not misused, and derived datasets and export paths are covered. Prompts and business rules can improve answer quality, but they are not independent permission boundaries.
2. From Asset Access to Verifiable Data-Permission Controls
2.1 The foundation: resource and application access
Resource and application access controls remain foundational because they decide who can enter an application or view a resource. In scenarios involving multiple data sources, fine-grained data distribution, and natural-language analysis, however, application access cannot replace permissions on connections, tables, and data scope.
2.2 Semantics and data management improve understanding, not authorization
Consistent field descriptions, metric definitions, and business terminology reduce interpretation errors. HENGSHI Data Agent can use prompts, knowledge management, data vectorization, and data preparation to improve analytical quality. These configurations affect model understanding and output; they are not access authorization and do not replace connection, application, or dataset permissions.
2.3 A permission baseline: identity, connections, and application data permissions
Public HENGSHI materials state that Data Agent retrieves and analyzes data only within the user’s authorized scope. The actual boundary depends on the combination of identity, connection permissions, application data-permission mode, row and column permissions, and public-link configuration. These controls should be validated against the deployed version and configuration. Prompts, presentation-layer masking, or one query rule should not be treated as a security mechanism that covers every access path.
Table 1. Security Control Surfaces and Validation Priorities for AI Analytics
| Security control surface | Capability described in public materials | Key boundary | Suggested validation |
|---|---|---|---|
| Identity and connection permissions | Connections, directories, and tables can be authorized with LS, SC, RO, or RW permissions; tables support row and column permissions and can filter by user attributes. | Effective access depends on the combination of role, connection authorization, and dataset configuration. | Use test accounts with different roles and user attributes to verify connections, tables, rows, and columns. |
| Application data permissions | Applications offer application-author, dataset-author, and consumer data-permission modes; the first two can configure row and column permissions in the application. | In consumer mode, application-level row permissions do not apply; data is accessed through the current user’s connection permissions. | Validate all three modes and the effective behavior of application rules and connection permissions. |
| Data Agent | Data Agent retrieves and analyzes data within authorized scope; prompts, knowledge management, vectorization, and data preparation can affect answer quality. | AI output is nondeterministic; prompts and tuning configurations are not independent access controls. | Run POC cases with allowed and prohibited real questions, different user identities, and adversarial or abnormal input. |
| Public links and presentation | Public links provide anonymous access and are not restricted by application row permissions; consumer mode does not support public links. Table masking is a chart-presentation setting. | Public links, detail viewing, export, drill-down, and presentation masking must be checked separately and cannot substitute for one another. | Test public links, detail access, export, and drill-down under both anonymous and authorized access. |
| Audit and operations | System operation records can be queried by time, operator, IP address, action, result, category, object, and description; data operations can be filtered and exported. | Public materials do not state that every question and complete response is recorded or connected with all other Agent trace data. | Validate log coverage, retention policy, and audit-export requirements in the target version and deployment. |
3. Practical Security Control Surfaces for AI Analytics
3.1 Access boundaries across connections, applications, rows, and columns
Connection, directory, and table permissions, together with table-level row and column permissions, form an important access-control foundation. Conditions such as user attributes can be used for data distribution. Each application must also select application-author, dataset-author, or consumer mode. One important boundary is that row permissions on an upstream dataset do not automatically propagate to a downstream derived dataset; the derived dataset needs its own permission configuration and validation. Table masking is a presentation-layer setting and should be verified separately from detail access, drill-down, and export paths.
3.2 Manage analytical quality and permission control separately
Data Agent can use prompts, knowledge management, vectorization, and data preparation to understand business semantics, while retrieving and analyzing only data within the user’s authorized scope. These tuning surfaces improve answer relevance and consistency; they should not be responsible for enforcing permissions. Use POC cases with different identities and real data scopes, including abnormal or misleading input, to confirm that prompts cannot change existing authorization.
3.3 Delivery, public links, and auditing
Public links provide anonymous access and are not restricted by application row permissions; consumer mode does not support them. Documentation provides interaction settings for detail viewing and data export on public links, with both disabled by default, but teams should still verify the target version before rollout. System operation records can be queried by time, operator, IP address, action, result, category, object, and description and can filter and export data operations. Their retention scope, coverage of question content, and alerting capabilities should be confirmed through the actual deployment configuration and acceptance results.
4. Security Management Should Rely on Explainable Configuration and POC Validation
A good security experience does not trade boundaries for the ability to answer. It keeps business objectives, accessible data scope, and permission-request paths clear. Answers and prompts may differ across versions, models, and configurations. POC acceptance cases should therefore specify the intended outcomes: allowed, partially visible, or inaccessible. They should not assume one fixed interaction pattern.
Permission configurations need regression tests. Prepare cases that should be allowed, rejected, or limited to partial data for different roles, user attributes, application permission modes, public links, and derived datasets. Rerun them after configuration or data-model changes to detect accidental expansion of data scope early.
5. Implications for Enterprise AI+BI Security
First, use identity, roles, connection permissions, application data-permission modes, and dataset row and column permissions as a least-privilege baseline, configured for the actual distribution scenario. Second, treat public links, consumer mode, derived datasets, and presentation-layer masking as separate boundaries that require separate management and validation. Third, data preparation and prompts improve Data Agent quality, but AI output remains nondeterministic. Complete the POC with real users, real data scopes, and allow/deny cases before rollout.
6. Conclusion: Validate Security Boundaries in the Real Configuration
Adopting AI analytics should not come at the expense of data boundaries. Public HENGSHI capabilities provide control surfaces across identity, connections, application data permissions, row and column permissions, public links, and auditing. Effective behavior still depends on product version, deployment, and configuration. Including these boundaries in the POC and in ongoing regression checks allows an enterprise to broaden data use while maintaining verifiable data security.