TL;DR: Databricks’ Data Intelligence Platform for Cybersecurity brings data, AI, and security into a shared operating model, while HiddenLayer positions model scanning, adversarial detection, and lifecycle monitoring as the security layer for AI applications, according to HiddenLayer. The governance shift is not just integration, but proving that AI systems remain auditable and resilient as attacks and compliance demands converge.
At a glance
What this is: This is a product and ecosystem announcement about Databricks’ cybersecurity platform and HiddenLayer’s model-security integration, with the key finding that AI security now has to be governed as part of the data platform lifecycle.
Why it matters: It matters because IAM, NHI, and AI governance teams now need a common control view for models, workloads, and access paths rather than treating AI security as a separate bolt-on concern.
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read HiddenLayer's analysis of Databricks' cybersecurity platform and AI model security
Context
AI security is no longer a standalone control layer. Once models, data, and operational tooling share the same platform boundary, the governance problem shifts to whether the platform can keep models trustworthy, explainable, and auditable across their lifecycle.
That matters for identity and access teams because AI systems are now tied to platform permissions, catalog controls, and operational oversight. The real question is whether security governance can keep pace when the model itself becomes part of the production trust chain.
Key questions
Q: How should security teams govern AI models inside shared data platforms?
A: Treat the platform as the governance boundary and assign explicit ownership for model access, change control, lineage, and audit evidence. Security teams should not rely on informal operational knowledge. If the model influences business decisions, the organisation needs a repeatable control model that shows who can touch it, when it changed, and how integrity is verified.
Q: Why do AI security controls need to extend beyond the model itself?
A: Because the model is only one part of the trust chain. The surrounding data platform, catalog, permissions, and service identities determine whether the model can be changed, invoked, or exported safely. If those controls are weak, the model can remain technically sound while the overall system still produces untrusted outcomes.
Q: What do organisations get wrong about AI model compliance?
A: They often confuse policy statements with evidence. Auditors and risk teams need to see operational proof that access, monitoring, and change control are working across the model lifecycle. Without that evidence, AI compliance remains a claim rather than a control.
Q: How do NHI and workload identities affect AI governance?
A: They define who and what can move data, retrain models, invoke services, and export outputs. That makes service accounts, tokens, and workload credentials part of the AI security boundary. If those identities are over-privileged or poorly tracked, the model inherits that exposure.
Technical breakdown
AI model security inside a data platform
The architectural shift here is that AI model security moves closer to the data plane. When a platform unifies data, AI, and security, the model is no longer an isolated artifact. It becomes something that must be scanned, monitored, and governed alongside the surrounding platform controls. HiddenLayer describes model scanning for vulnerabilities and adversarial manipulation, which points to two distinct concerns: the model may be technically compromised, or its outputs may be steered by hostile inputs. In practice, that means model trust is not static. It depends on continuous visibility into the model’s behaviour and the surrounding governance boundary.
Practical implication: treat model security as a runtime governance problem, not a one-time certification event.
Unity Catalog as a governance control point
Unity Catalog matters because it turns access and lineage into enforceable policy rather than loose operational metadata. In an AI security context, catalog integration can help answer who can touch the model, where the model is used, and how changes are tracked over time. That is essential when organisations need to show due diligence to auditors or internal risk teams. The security value is not the catalog itself, but the fact that it creates a consistent governance anchor for the model and its associated assets. Without that anchor, AI controls remain fragmented across data, tooling, and deployment layers.
Practical implication: map AI model ownership, access, and lineage to a single control surface before scaling deployment.
Adversarial manipulation and model integrity
Adversarial inputs, data poisoning, and model theft are different attack paths, but they converge on one issue: model integrity. Adversarial inputs try to distort behaviour at runtime, poisoning corrupts the training or reference corpus, and theft removes the model as a protected asset altogether. Those are not purely ML problems. They become governance problems once business decisions depend on model outputs, because a compromised model can create fraud, compliance, or operational failures downstream. The important distinction is that model risk is both technical and identity-adjacent when access to models, prompts, or pipelines is permissioned through enterprise controls.
Practical implication: classify model integrity as a security outcome that needs access, monitoring, and change control.
NHI Mgmt Group analysis
AI model governance is now part of the identity control plane, not adjacent to it. When a cybersecurity platform is built around shared data and AI services, access to models, catalogs, and operational workflows becomes a governance question, not just an engineering one. That means security teams have to think in terms of entitlement, lineage, and auditability across AI assets. The practitioner conclusion is simple: if the platform cannot explain model access and change history, it cannot claim governance.
Model integrity failure is a different class of risk from model availability failure. This announcement reflects the reality that AI systems fail not only when they go down, but when they are manipulated into producing untrusted outputs. Adversarial inputs, poisoning, and theft all break the assumption that the model remains stable between review cycles. The practitioner conclusion is that resilience must include integrity monitoring, not just service uptime.
Compliance for AI will increasingly depend on evidencing control, not just asserting policy. HiddenLayer’s integration story is really about demonstrating due diligence through auditable controls around AI models and their lifecycle. That direction aligns with the broader shift in security governance, where regulators and internal audit teams expect traceability across critical systems. The practitioner conclusion is that evidence collection for AI needs to be designed into the platform boundary.
Identity teams should expect AI governance to converge with NHI and workload governance. AI models do not operate in isolation. They depend on permissions, pipelines, service identities, and platform entitlements to function, which means existing NHI and workload controls increasingly define the model’s real security boundary. The practitioner conclusion is that model security programmes will fail if they ignore the identities that move, update, and invoke the model.
HiddenLayer’s integration highlights a growing runtime governance gap for AI systems. The security issue is no longer whether an organisation has AI controls in concept, but whether those controls persist where the model actually runs and changes. That is why platform-bound governance matters more than standalone policy documents. The practitioner conclusion is to anchor AI security in the operational system of record, not in a disconnected review workflow.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
- A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
- For teams looking to close that gap, Ultimate Guide to NHIs , Key Challenges and Risks frames the visibility and over-privilege controls that matter most.
What this signals
Runtime governance gap: AI security is moving into the platform layer, which means the real control question is whether model access, lineage, and change history can be evidenced at the point of use. That is a different operating model from policy-only review and it aligns more closely with platform-native controls than after-the-fact assurance.
Enterprises should expect AI governance to converge with NHI and workload identity management because the identities behind the model often define the true attack surface. In practice, that means service accounts, tokens, and pipeline credentials will matter as much as the model artefact itself.
With 1 in 4 organisations already investing in dedicated NHI security capabilities, and another 60% planning to do so within twelve months, the direction of travel is clear: identity governance is being pulled closer to runtime systems, including AI platforms.
For practitioners
- Map AI assets to a governance owner Assign explicit ownership for models, prompt workflows, and cataloged data so every AI asset has a named control point for review, change approval, and audit response.
- Add integrity checks to model lifecycle monitoring Track adversarial input signals, suspicious output drift, and unexpected model changes as part of the normal security monitoring workflow, not as a separate ML-only process.
- Tie platform permissions to model usage evidence Require that access to AI models, datasets, and operational pipelines is traceable through platform records that support audit and incident investigation.
- Review NHI and workload identities around AI pipelines Identify the service accounts, tokens, and workload credentials that can modify, invoke, or export model assets, then scope their permissions to the narrowest operational need.
Key takeaways
- AI model governance now depends on the same operational controls that secure the surrounding data platform, not on isolated policy statements.
- Adversarial manipulation, poisoning, and theft are integrity problems, which means AI security must track trust continuity across the model lifecycle.
- Identity teams need to govern the service accounts, tokens, and platform permissions that let AI systems move, change, and expose data.
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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AG-05 | Agentic and model-adjacent governance needs runtime monitoring and misuse detection. |
| NIST AI RMF | AI RMF aligns to lifecycle governance, integrity, and accountability for model risk. | |
| NIST CSF 2.0 | PR.AC-4 | Platform permissions and access traceability underpin AI model governance. |
Map model, catalog, and pipeline access to least-privilege controls and review them regularly.
Key terms
- Model integrity: Model integrity is the condition that an AI model behaves as expected and has not been altered, poisoned, or manipulated in ways that change its outputs. In security terms, it is the trust property that lets an organisation rely on model behaviour for decisions, automation, and compliance evidence.
- Runtime governance: Runtime governance is the set of controls that remain active while a system is operating, not just during design or approval. For AI systems, it means monitoring access, inputs, outputs, and changes continuously so the organisation can prove the model stayed within its intended boundary.
- Model lineage: Model lineage is the traceable record of where a model came from, what data influenced it, and how it changed over time. It helps security and audit teams reconstruct control decisions, investigate failures, and verify that AI assets were handled according to policy and risk requirements.
- Workload identity: Workload identity is the identity assigned to a service, pipeline, or non-human system so it can authenticate and access resources safely. In AI environments, it often governs the processes that train, deploy, query, or export models, making it part of the effective security boundary.
What's in the full analysis
HiddenLayer's full post covers the operational detail this post intentionally leaves for the source:
- How the Databricks integration is positioned inside the cybersecurity platform ecosystem and what that means operationally for buyers.
- How HiddenLayer describes model scanning, adversarial detection, and lifecycle monitoring in implementation terms.
- How Unity Catalog is used to support auditability and governance evidence across AI assets.
- How the vendor frames compliance and due diligence for organisations adopting AI security controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2025-09-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org