Controlling the AI skill focuses on who built it, who can invoke it, and how it is shared. Controlling the lakehouse data focuses on the sensitivity, governance, and exposure of the underlying resources the skill queries. Both layers matter because a well governed skill can still surface risky data if the connected lakehouse is poorly controlled.
How the AI skill is controlled
Controlling the AI skill means governing the capability itself as a reusable object: who authored it, who is allowed to invoke it, whether it is shared across teams, and what permissions it inherits at runtime. That is the control point for the tool or skill layer, not for the data source behind it. When a skill is over-shared or poorly governed, the risk is usually misuse of the skill path rather than direct exposure of the underlying lakehouse.
For practitioners, the key distinction is that skill controls answer “who may run this capability and with what authority?”, while data controls answer “what can this capability see once it runs?”. The two are related, but they are not the same control plane. A tightly governed skill can still become a problem if its runtime access is broad enough to reach sensitive data.
How the lakehouse data is controlled
Controlling the lakehouse data means governing the assets the skill queries or retrieves, including sensitivity classification, dataset ownership, row- or column-level restrictions, retention, and exposure paths. This layer is about the information surface, not the skill wrapper. If the lakehouse is loosely governed, the skill can surface data that should never have been available to that use case, even when the skill itself appears well managed.
This is why data control must be evaluated independently from skill control. The same skill may be acceptable against a low-risk dataset but inappropriate against regulated, confidential, or broadly shared lakehouse tables. In practice, data governance determines the blast radius of any skill invocation.
Why the difference matters in real deployments
The practical difference is that skill governance reduces unsafe use of the capability, while lakehouse governance reduces unsafe exposure of the content. One is an access and sharing question, the other is a data classification and authorization question. In an AI workflow, the skill can be the delivery mechanism, but the lakehouse is often the source of truth that defines whether the outcome is safe.
That separation also helps with design decisions. If the main issue is that too many people can launch a skill, you tighten skill ownership, approvals, and invocation rights. If the main issue is that the skill can query overly broad datasets, you tighten the underlying data permissions, masking, and governance controls. The right fix depends on which layer failed.
Risk and Threat Considerations
When these two layers are conflated, organisations often secure the skill but leave the data path open, which creates a false sense of safety. A benign-looking skill can still expose sensitive records, and a poorly governed lakehouse can turn an otherwise acceptable skill into a data leakage channel.
Failure mechanism: The skill is approved or shared as a reusable capability, but its connected data sources remain over-permissioned, overexposed, or insufficiently classified. The result is that runtime access inherits more data reach than the business intended.
Impact: Users may retrieve sensitive, regulated, or business-critical data through an apparently controlled interface, expanding blast radius, compliance exposure, and the likelihood of downstream misuse or accidental disclosure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while CSA Cloud Controls Matrix sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Covers agent or skill permissions that exceed intended authority. |
| Recommendation — Constrain skill permissions so invocation cannot exceed approved authority. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Fits controlled invocation of a capability and who may call it. |
| Recommendation — Enforce function-level authorization for every skill invocation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Applies because the question splits capability access from data access governance. |
| DSP — Data Security and Privacy | Applies to lakehouse sensitivity, exposure, and data governance controls. | |
| Recommendation — Separate skill access governance from data access entitlements. Classify and restrict lakehouse data based on sensitivity and exposure. | ||
Practitioner Guidance
What to verify: Confirm whether the skill’s approval process and the lakehouse’s data authorization model are owned separately, because one control should never be assumed to cover the other. If a review only checks the skill registry, it is incomplete unless it also checks what data the skill can actually read.
Decision rule: If the concern is uncontrolled invocation or reuse, treat it as a skill-governance problem; if the concern is sensitive query reach, treat it as a data-governance problem. If both are weak, fix the data path first when exposure is the highest-risk condition, because that is what determines the actual disclosure surface.
Practitioner takeaway: The skill is the permissioned interface, but the lakehouse is the exposure boundary, and the safer design is the one that controls both without assuming either layer compensates for the other.
Related resources from NHI Mgmt Group
- What is the difference between controlling AI agents and governing the data they use?
- What is the difference between controlling data movement and using audit logs for AI chat security?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
