Cranium and ISTARI partnership expands enterprise AI governance

At a glance

What this is: This is a partnership announcement about combining AI security software with advisory-led governance for enterprise AI programmes.

Why it matters: It matters because practitioners must decide how AI governance, risk, and compliance controls will be operationalised across internal and third-party systems, not just documented.

👉 Read Cranium's announcement on its AI security and governance partnership with ISTARI

Context

Enterprise AI governance fails when visibility, testing, and operating-model design live in separate programmes. AI security and compliance controls only become useful when they are connected to the way teams approve, monitor, and change systems in production.

The article is about a partnership intended to close the gap between technical AI security and enterprise governance execution. That gap is familiar to IAM, NHI, and compliance leaders: controls are often written faster than they can be operationalised, especially where third-party systems and shared accountability are involved.

Key questions

Q: How should security teams operationalise AI governance across internal and third-party systems?

A: Security teams should connect discovery, testing, approval, and monitoring to the workflows that already govern change and risk. The goal is not a separate AI review lane, but a repeatable control path that records ownership, evidence, and exceptions. That approach makes governance enforceable when AI systems are deployed by multiple teams and suppliers.

Q: Why do AI governance programmes fail when security and advisory ownership is split?

A: They fail because no single team owns the full decision chain from risk identification to remediation and evidence retention. Split ownership creates gaps between what is found, what is approved, and what is actually enforced. In AI programmes, those gaps widen quickly because deployment speed outruns manual coordination.

Q: How can organisations govern third-party AI systems without losing accountability?

A: They need explicit ownership, control evidence, and review cadence for every external AI dependency. That includes suppliers, hosted platforms, and integrated services that influence model behaviour or data exposure. Without those controls, accountability becomes implied rather than auditable, which is a weak basis for enterprise governance.

Q: What should boards look for to tell whether AI governance is actually working?

A: Boards should look for evidence that governance findings change operational decisions. Useful signals include delayed releases, escalated exceptions, documented remediation ownership, and reduced reliance on manual approval chains. If governance only produces reports, it has not become part of the operating model.

How it works in practice

Why AI governance breaks when discovery is detached from execution

AI governance programmes often collect inventories, policies, and control evidence in separate workflows, which makes them hard to operationalise. Automated discovery can find systems and testing can surface risk, but neither changes who owns the decision, when a control is triggered, or how exceptions are handled. In practice, the control plane matters as much as the visibility layer. If governance cannot reach the operating model, it remains a reporting exercise rather than a security function.

Practical implication: connect AI discovery outputs directly to approval, review, and escalation workflows so findings can drive action.

How third-party AI systems change governance scope

Third-party AI systems extend the trust boundary beyond the enterprise perimeter and force governance to cover suppliers, integrators, and shared platforms. That creates a different control problem from internal model oversight because responsibility for testing, monitoring, and remediation is distributed. The article points to a combined security and advisory model, which reflects a broader reality: programme owners need evidence, not assumptions, about which controls remain effective once AI leaves the core environment.

Practical implication: map third-party AI systems to explicit owners, control evidence, and review cadence before they enter production.

What embedded governance means for AI risk management

Embedded governance means AI controls are part of normal operating processes, not a separate after-the-fact review. That matters because AI risk changes quickly and policy updates lag operational change. When governance is embedded, teams can tie compliance checks, risk decisions, and exception handling to the systems that create exposure. The result is less dependence on manual coordination and more repeatable accountability across model development, deployment, and use.

Practical implication: build AI risk checkpoints into change management, procurement, and deployment workflows rather than treating them as stand-alone reviews.

NHI Mgmt Group analysis

This partnership is a signal that AI governance is moving from policy design to operating-model enforcement. The article frames the problem correctly: enterprises can no longer treat AI oversight as a document set or a periodic review cycle. When AI adoption spreads across internal and third-party systems, governance only matters if it changes how decisions are made, who approves them, and what evidence is retained. Practitioners should read this as a sign that AI governance is becoming an execution discipline, not a compliance appendix.

AI security and AI governance fail for the same reason many IAM programmes fail: they are split across ownership boundaries. Security teams, risk teams, and advisory functions often each hold part of the control picture, but none owns the full lifecycle of assurance. That fragmentation is now more visible in AI because deployment speed compresses review windows and multiplies external dependencies. The implication is that programme design must assume shared accountability from the start, or governance will trail deployment by default.

Embedded governance is the right direction because AI controls have to sit inside the workflow where risk is created. The partnership suggests a shift away from one-off assessments toward continuous operational oversight across model development, deployment, and third-party use. That is consistent with broader identity security practice: controls only hold when they are attached to the system that issues access, change, or approval. Practitioners should treat AI governance as a workflow problem, not just a policy problem.

Third-party AI oversight will increasingly resemble supplier identity governance rather than conventional app governance. Once AI systems are shared, integrated, or externally operated, the key questions become ownership, visibility, and revocation, not just performance or accuracy. That creates a governance pattern closer to non-human identity lifecycle management than to traditional software assurance. The field should expect procurement, security, and compliance teams to converge on the same control evidence if AI programmes are to remain auditable.

AI governance programmes will be judged by whether they can translate assurance into repeatable operating decisions. The article shows a market moving toward practical enforcement rather than abstract readiness. That means practitioners should measure whether findings actually change deployment gates, exception handling, and review cadence. If they do not, the programme is still describing risk rather than governing it.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• Use NHI Lifecycle Management Guide to translate visibility into lifecycle controls before third-party access becomes ungoverned.

What this signals

Third-party AI governance will increasingly be judged by lifecycle evidence, not by policy intent. When external systems participate in model development, inference, or monitoring, practitioners need proof of ownership, review cadence, and revocation paths. The pattern is close to supplier NHI governance, where visibility without control action is just inventory. That is why many teams should align AI oversight with the discipline behind the NHI Lifecycle Management Guide.

The governance gap here is structural because external AI systems expand the number of parties that can create, change, or consume risk. A programme that cannot show who approved a dependency, who monitors it, and who can remove it will struggle under audit. For identity teams, the practical next step is to treat AI access and AI oversight as part of the same assurance chain.

As third-party AI use grows, expect procurement, risk, and security to converge on common evidence requirements. That pressure will look familiar to teams already managing OAuth-connected vendors, service accounts, and delegated access. The organisations that move first will be the ones that can turn governance findings into operating decisions instead of static reports.

For practitioners

• Define a single owner for AI governance decisions Assign one accountable function for approvals, exceptions, and evidence retention across internal and third-party AI systems so the control model does not fragment across security, risk, and delivery teams.
• Tie AI discovery to operational workflows Feed discovery, testing, and compliance findings directly into change management, procurement, and deployment gates so controls are enforced where AI systems actually move into use.
• Map third-party AI dependencies before production Record which external systems, advisory partners, and integrated platforms participate in AI delivery, then assign control evidence and review cadence to each dependency.
• Measure whether governance changes decisions Track how often governance findings alter rollout timing, exception approval, or remediation ownership. If decisions do not change, the programme is not yet operational.

Key takeaways

• The article points to a market shift from AI governance as policy writing to AI governance as operational enforcement.
• The main risk is fragmented ownership across security, risk, and advisory teams, which leaves deployment faster than assurance.
• Practitioners should connect discovery, evidence, and approval workflows so AI governance changes real decisions.

Key terms

• AI governance operating model: The operating model is the way an organisation turns AI policy into day-to-day decisions, approvals, and accountability. In practice, it defines who owns risk, how exceptions are handled, and where evidence is collected so AI controls can be enforced rather than merely documented.
• Third-party AI dependency: A third-party AI dependency is any external service, platform, or partner that influences how AI is trained, deployed, monitored, or used. These dependencies expand the governance boundary because control evidence, ownership, and revocation may sit outside the core enterprise team.
• Embedded governance: Embedded governance means security and compliance controls are built into normal workflows instead of being handled as separate reviews. For AI programmes, this usually means approvals, monitoring, and escalation happen inside procurement, change management, and deployment processes.

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 building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Cranium: Cranium AI and ISTARI Forge Global Alliance to Drive Enterprise AI Security and Governance. Read the original.