By NHI Mgmt Group Editorial TeamPublished 2026-06-16Domain: Agentic AI & NHIsSource: Cranium

TL;DR: AI governance often relies on attestations, questionnaires, and framework mappings that say what should be true, but not whether AI systems are actually behaving that way, according to Cranium. The real control gap is the absence of runtime evidence such as model verification, event logs, and telemetry that turns policy into provable reality.


At a glance

What this is: This is an analysis of why AI governance based on attestations and questionnaires fails without runtime evidence, and why verified behaviour matters more than documented intent.

Why it matters: It matters because identity and access teams cannot govern AI, agentic, or machine activity with static claims alone when systems, models, and data paths can change after approval.

By the numbers:

👉 Read Cranium's analysis of why AI governance needs runtime proof


Context

AI governance breaks down when the organisation can describe an approved state but cannot verify the live state. In practice, procurement, compliance, and security often rely on questionnaires, policy mappings, and vendor attestations that age quickly while the underlying model, data path, or deployment changes.

For IAM and identity teams, the core issue is not whether an AI system has a policy on paper. It is whether the system can prove what model it is using, what it accessed, and what it actually did at runtime. Without that evidence, governance becomes a documentation exercise rather than an enforceable control.

The article’s central claim is that AI trust needs a living record that reconciles declarations with observed behaviour. That is a familiar identity lesson: if the control plane cannot observe the runtime plane, it cannot govern it.


Key questions

Q: How should security teams govern AI systems that can change after approval?

A: They should bind approval to runtime evidence rather than to static attestations. That means verifying the active model, the data path, and the execution logs after deployment, then revisiting the approval when those facts change. If the production system can drift without detection, the governance process is descriptive, not enforceable.

Q: Why do static AI policies fail in practice?

A: Static policies fail because they describe an intended state, while AI environments can change model versions, hosting locations, integrations, and tool access after sign-off. Without telemetry, the organisation cannot tell whether the deployed system still matches the approved one. Governance becomes paperwork unless it is connected to observable runtime behaviour.

Q: How can organisations tell whether AI governance is actually working?

A: They should look for evidence that approvals, logs, and observed behaviour reconcile over time. If the team can prove which model ran, what it accessed, and what it did, the control is functioning. If it can only produce forms and attestations, the programme is recording intent rather than governing reality.

Q: Who is accountable when an approved AI system drifts from its declared posture?

A: Accountability should sit with the teams that own approval, monitoring, and change control together, not with compliance alone. If the system changes after approval and nobody can prove when the change occurred, then governance failed at the control boundary. AI risk management frameworks and identity governance both depend on that boundary being observable.


Technical breakdown

Why attestation fails when AI systems change after approval

Attestation is a point-in-time claim that a system matches a declared configuration, policy, or control set. That works only if the system remains stable between review cycles. In AI environments, model selection, hosting location, tool access, and prompt handling can change without the policy artefact changing with them. The result is a governance blind spot: the organisation believes it approved one system, while production is now something else. This is not merely a compliance issue. It is an identity and trust problem, because the operating behaviour is what determines exposure, not the questionnaire response.

Practical implication: tie approval status to runtime evidence, not to static declarations.

What runtime telemetry adds to AI governance

Runtime telemetry is the evidence layer that shows what an AI system actually did. That includes model probes to verify the active model and version, event logs to capture interactions, and prompt or agentic telemetry to record tool use and decisions. In identity terms, this is the difference between claimed entitlement and observed action. Without telemetry, organisations cannot detect model swaps, policy drift, unsanctioned integrations, or prompt paths that alter data exposure. With telemetry, governance becomes auditable in motion rather than only auditable on paper.

Practical implication: require evidence logs that can reconstruct model, access, and action history.

Why a living trust record is the better control object

A living trust record combines the declared posture with the observed posture and keeps both in sync over time. It is not just a document repository. It is a control object that continuously reconciles what a vendor, team, or platform says with what the system is demonstrably doing. For IAM and NHI programmes, this is a useful pattern because it aligns approval, monitoring, and assurance into one feedback loop. The architectural lesson is that governance must become testable, replayable, and revocable at runtime, or it will remain ceremonial.

Practical implication: design AI governance artefacts so they can be continuously refreshed by observed behaviour.


NHI Mgmt Group analysis

AI governance without runtime verification is documentation theatre. The article is right to separate policy from proof, because most governance stacks still reward paperwork more than observed control. A model card, questionnaire, or framework mapping can describe intent, but it cannot confirm that the deployed model, data path, or toolchain still matches that intent. The implication is that governance programmes must stop treating static attestations as evidence of security.

Runtime evidence is the missing control layer between AI policy and enforcement. Model probing, interaction logs, and agentic telemetry do not simply add visibility. They convert claims into testable facts and expose drift when the live system diverges from the approved one. That matters for NIST AI RMF and zero trust thinking alike, because trust without continuous observation is only a scheduled assumption.

Living trust records are a more durable governance construct than static AI cards. The article’s proposed AI Card concept is best understood as an identity record that follows behaviour, not a filing cabinet for declarations. That creates a single place where approvals, evidence, and revocation can meet. Practitioners should treat that as the emerging control pattern for AI estates, especially where multiple teams touch provisioning, compliance, and runtime operations.

Shadow AI is a detection problem before it is a policy problem. If the organisation cannot see unsanctioned models or agents connecting to production systems, prohibitions are unenforceable. The security lesson is that governance reaches its limit where observability ends. The practitioner conclusion is simple: if you cannot observe the runtime path, you do not control the runtime path.

NHI governance and AI governance are converging on the same accountability question. Whether the subject is a service account, an OAuth app, or an AI system, the organisation must be able to prove who or what acted, with what authority, and under which conditions. The implication is that identity teams should unify evidence, lifecycle, and runtime assurance rather than run separate trust models for adjacent actors.

From our research:

What this signals

Living trust records will become the practical bridge between AI governance and identity governance. As AI systems move from policy-bound pilots to operational workflows, teams will need records that capture approved posture, observed behaviour, and revocation triggers in one place. The governance problem is no longer whether a policy exists, but whether the organisation can prove the live system still matches it.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per The 2026 Infrastructure Identity Survey, the access model itself is moving faster than most control frameworks. That creates a direct programme signal for IAM and NHI teams: assurance must be continuous, not review-cycle based.

Shadow AI will increasingly look like an identity discovery problem. The practical next step is to treat unsanctioned models, connectors, and agents as unmanaged identities until proven otherwise. Teams that already manage service accounts, tokens, and privileged access are well placed to extend those patterns into AI runtime assurance, especially where observability, offboarding, and evidence retention intersect.


For practitioners

  • Require runtime evidence for every AI approval Link each approved model or agent to logs that verify the active version, data path, and tool usage after deployment. Treat those artefacts as part of the approval record, not optional operational telemetry.
  • Replace static vendor cards with living trust records Maintain a record that continuously reconciles declared posture with observed behaviour, including model changes, policy drift, and event history. Make the record reviewable by security, compliance, and the owning platform team.
  • Instrument prompt and agentic telemetry by default Capture prompt inputs, tool calls, and execution outcomes for AI systems that influence decisions or access. Without those records, you cannot reconstruct how a system reached a result or whether it crossed an approved boundary.
  • Treat shadow AI as an observability gap Deploy sensors that detect unsanctioned models, connectors, and agent integrations before they reach production workflows. Enforcement is impossible if discovery happens only after a questionnaire or audit cycle.

Key takeaways

  • AI governance fails when the organisation can prove intent but not behaviour.
  • Runtime telemetry turns approvals into evidence and exposes drift that questionnaires cannot see.
  • Identity teams should build living trust records that reconcile declared posture with observed system actions.

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.

FrameworkControl / ReferenceRelevance
NIST AI RMFAI governance needs verified evidence, not just documented intent.
NIST CSF 2.0GV.OV-01The article is about making governance evidence-based and auditable.
OWASP Agentic AI Top 10A04Runtime agent behaviour must be observable to detect misuse and drift.

Build control evidence that can demonstrate whether AI systems are operating within approved bounds.


Key terms

  • Runtime Telemetry: Runtime telemetry is the evidence generated while a system is operating, such as logs, probes, and interaction records. In AI governance, it proves what model was active, what data was touched, and what actions were taken, which is essential when approval can no longer be trusted on its own.
  • Living Trust Record: A living trust record is a continuously updated identity and governance record that reconciles declared posture with observed behaviour. It turns static documentation into an operational control object, allowing teams to verify, review, and revoke based on what the system is actually doing.
  • Shadow AI: Shadow AI is any undiscovered or unmanaged AI system operating inside the environment. It includes sanctioned-adjacent models, agents, or connectors that security teams cannot see, govern, or evidence, which makes policy enforcement and risk reporting unreliable.
  • AI Card: An AI Card is a structured trust artefact that captures what an AI system claims to be doing and what it is observed doing. The concept matters because governance becomes durable only when declarations are paired with runtime evidence and kept in sync over time.

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.

This post draws on content published by Cranium: AI governance needs runtime proof, not green checkmarks. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org