TL;DR: Config-driven insight engines let analysts ship production-grade analytics without engineering cycles, using JSON, SQL validation, tenant isolation, feature flags, and multi-region execution, according to Island. The broader lesson is that when analytics becomes self-service, governance must move from release management to policy, validation, and access control.
At a glance
What this is: Island describes a config-driven insight engine that lets analysts ship production-grade analytics without backend code changes, while moving the main risk into validation, tenancy, and rollout governance.
Why it matters: IAM and security teams should care because self-service analytics can expose identity metadata and privileged-behaviour insights at scale, so access control and policy enforcement shift from deployment gates to runtime governance.
Context
Declarative analytics means analysts define insight logic in configuration instead of asking engineers to write and deploy code. That changes the governance problem: the critical controls move from release management to schema validation, tenant scoping, and policy enforcement around who can define and activate an insight. In a security environment, that matters because analytics often touches identity metadata, device posture, and privileged activity.
Island's example shows how browser telemetry, identity metadata, and workload routing can be combined into self-service insights without losing tenant isolation. The operational question is no longer whether an analyst can ask for a metric, but whether the platform can safely let non-developers shape production behaviour without creating data exposure, noisy queries, or uncontrolled rollout paths.
Key questions
Q: What breaks when analytics insights are defined in configuration without strong governance?
A: The main failure is not the query itself, but the control plane around it. If validation, ownership, and tenant scoping are weak, declarative analytics can let non-developers push production-visible logic that runs with broader access than intended. That creates a governance problem in the same place teams expected a delivery shortcut.
Q: Why does self-service analytics create access and compliance risk for security teams?
A: Because the data often includes identity metadata, device posture, or privileged-user behaviour, and those fields can be sensitive even when the output is only a dashboard insight. If access rules, rollout controls, and retention are loose, the analytics layer can expose information that should have remained tenant-bound and role-restricted.
Q: What do security teams get wrong about tenant-isolated analytics execution?
A: They often assume isolation is guaranteed once a platform is multi-tenant. In practice, the query layer, worker context, and routing logic all need to enforce the boundary. A single mis-scoped execution path can turn a useful insight system into a cross-tenant visibility problem.
Q: How should teams govern declarative analytics once it reaches production?
A: Use the same discipline you would apply to any production control plane: review who can author insight definitions, validate every configuration change, gate visibility with feature flags, and audit execution outcomes over time. The goal is to keep speed, while making activation and scope fully accountable.
Technical breakdown
How declarative insight engines separate logic from deployment
A declarative insight engine moves the analytic definition into structured configuration, usually JSON plus a query definition, and leaves the execution layer to handle routing, validation, and rendering. That decouples feature delivery from code deployment, but it also creates a policy surface: if the configuration is wrong, the system can still execute it at scale. In Island's model, the platform validates schema and business rules in CI, versions the artefact, and then uses feature flags and tenant-aware routing to decide where it runs. The technical shift is from shipping code to governing executable configuration.
Practical implication: Treat insight definitions as governed production artefacts, not lightweight content files.
Why tenant-scoped execution is the real control boundary
Tenant isolation is the control that prevents a useful insight from becoming a cross-customer data leak. When analytics runs in batch or on demand, each query must be scoped to a single tenant, and the execution context must preserve that boundary even when workers, queues, and read replicas are shared. Island's design adds row limits, timeouts, retries, and tenant-aware service routing because scale amplifies the cost of a scoping mistake. This is especially important where the insight is based on identity metadata or privileged-user behaviour, because the data is both sensitive and operationally useful.
Practical implication: Enforce tenant scoping in the data-access layer, not in analyst-written query text.
How feature flags and historical storage change rollout risk
Feature flags and historical result storage turn analytics delivery into a controlled lifecycle rather than a one-time release. Flags determine who sees an insight and when it runs, while stored outputs support retrospective analysis and trend detection. That improves operational resilience, but it also means the governance model must cover activation, visibility, and retention together. A poorly controlled flag can expose a sensitive insight too early, and poor retention discipline can preserve data longer than intended. The architecture is safe only if rollout, visibility, and result handling are governed as one system.
Practical implication: Version and review insight activation rules with the same discipline you apply to production access changes.
Threat narrative
Attacker objective: The objective would be to surface or extract sensitive telemetry across tenant boundaries, or to abuse insight execution to expand visibility into privileged behaviour.
- Entry occurs when analysts or product teams create insight definitions that become executable configuration without engineering mediation.
- Escalation happens if validation, tenant scoping, or feature-flag controls fail and the insight runs with broader data access than intended.
- Impact is exposure of sensitive browser, identity, or privileged-activity telemetry through mis-scoped analytics or uncontrolled rollout.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Declarative analytics config is a governance pattern, not just a delivery pattern: once configuration can change production-visible behaviour, the control plane becomes the real security boundary. The article shows that validation, versioning, and scoped execution are what keep self-service analytics from becoming unmanaged production logic. Practitioners should stop treating analytics delivery as a release pipeline problem and start treating it as a governed policy surface.
Privilege and identity data make analytics delivery a security-sensitive workload: the example insight about privileged users accessing AI tools shows how quickly analytics becomes intertwined with identity governance. Once analytics is used to monitor behaviour tied to access rights, the platform itself inherits the obligations of access control, data minimisation, and tenant isolation. That makes the analytics layer part of the identity security programme, not a separate reporting tool.
Static configuration as a control plane is the right named concept here: the article's core model is that structured configuration, not application code, now decides what runs, where it runs, and who sees it. That is powerful, but it also concentrates risk in schema correctness, validation gates, and rollout policy. The practitioner conclusion is clear: govern configuration with the same rigor that previously surrounded code deployments.
Self-service analytics widens the gap between change velocity and governance maturity: analysts can now create and publish insights in minutes, while security and data teams still need to prove that each insight respects tenant boundaries, privacy expectations, and access policy. That gap is manageable only when ownership, validation, and execution controls are explicit. The field should expect more platforms to expose this same tension as analytics becomes programmable.
Browser telemetry analytics sits close to the NHI and identity boundary: when insight engines analyse user behaviour, device posture, installed extensions, and privileged access patterns, they start to function as identity-adjacent control systems. That means IAM, PAM, and NHI teams need to understand not just the insights themselves, but the governance of the engine producing them. The practical conclusion is that analytics platforms should be reviewed as part of the broader identity governance surface.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
What this signals
Static configuration as a control plane: this pattern will keep spreading as teams look for faster ways to ship governed analytics without code releases. The governance burden moves earlier in the lifecycle, so validation and policy checks have to happen before execution rather than after deployment.
Where analytics touches privileged-user behaviour or identity metadata, it becomes part of the security control surface rather than a reporting convenience. Security teams should expect more requests for self-service insights and should define upfront what data can be queried, by whom, and under which tenant boundary.
Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That kind of visibility gap is why identity-adjacent analytics must be governed as a sensitive workload, not treated as a benign reporting layer.
For practitioners
- Define a configuration approval model for insights Treat JSON insight definitions and query files as production artefacts. Require schema checks, business-rule validation, and ownership approval before any insight can be activated.
- Enforce tenant scoping in the execution layer Verify that tenant isolation is enforced by the data-access layer, worker context, and routing logic, not by analyst discipline or query comments.
- Review feature-flag governance for sensitive insights Map which insights are hidden, partially rolled out, or customer-segment gated, and ensure the same approval path governs activation and deactivation.
- Separate analytical workloads from transactional systems Keep long-running insight queries on read replicas or equivalent isolated compute so analytics does not degrade core platform performance or availability.
- Track insight outputs as governed records Store execution results with retention rules, access controls, and auditability so historical analytics does not become an unmanaged data archive.
Key takeaways
- Declarative analytics shifts the main risk from code deployment to configuration governance, because runtime behaviour now follows validation, scope, and rollout policy.
- When insight engines analyse identity and privilege-related telemetry, tenant isolation and access control become part of the analytics control plane.
- Security teams need approval, scoping, and audit discipline around self-service insights or they risk turning speed into uncontrolled production access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Declarative insights still need strict authorization around who can define and activate them. |
| Recommendation — Apply PR.AA-05 to gate insight authoring and activation by role, tenant, and sensitivity. | ||
| CIS Controls v8 | CIS-5 — Account Management | Analyst-driven production changes still depend on accountable user and service account governance. |
| Recommendation — Use CIS-5 to review which accounts can publish, approve, or execute insight configurations. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Mis-scoped analytics and shared execution paths can be abused to move across data boundaries. |
| Recommendation — Map shared execution risk to TA0006 and TA0008, then hunt for unexpected cross-tenant access paths. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The insight engine exposes a governed API surface where routing and access controls can be misapplied. |
| Recommendation — Use API8 to review routing, authorization, and tenant-scoping controls on insight endpoints. | ||
Key terms
- Declarative configuration: Declarative configuration describes the state a system should have, rather than the steps needed to build it. In practice, this makes reviews easier, supports repeatable deployments, and gives security and identity teams a stable reference point for drift detection and rollback.
- Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
- Feature Flag: A feature flag is a runtime control that turns a capability on or off for a specific user, organization, or environment. In identity terms, it behaves like an entitlement claim when it decides what a customer can do, and it must be governed with ownership, review, and retirement rules.
- Read Replica: A read replica is a database copy optimised for read-heavy workloads so analytical queries do not interfere with transactional operations. It is a performance and resilience control, but it still requires scoping and access governance because it may contain sensitive operational data.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a fit for practitioners who need to connect access governance, machine identity control, and operational security decisions.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org