Common signs include broad policy language with no enforcement point, weak linkage between agent identity and action logs, and evidence that controls are reviewed after the fact instead of during execution. If the team cannot block or constrain a risky action live, governance is not operational.
What a checkbox AI governance program looks like in practice
A checkbox program usually has policy artefacts, steering meetings, and approvals, but no operational control path. The governance language may sound complete, yet the team cannot prove who owns each decision, what is being enforced at runtime, or how a high-risk action is actually blocked before it executes. That gap is the clearest sign that governance exists on paper, not in the system.
Two indicators matter more than the volume of documentation: whether authority is attached to a real control point, and whether the control changes behaviour in the live workflow. If the answer is “we review it later,” the programme is tracking activity, not governing it.
One practical test is whether every meaningful action has a traceable owner, an approval rule, and an enforcement mechanism that can be demonstrated in a normal production path. If any of those three are missing, governance is probably ceremonial rather than operational.
Where the evidence usually breaks down
Weak governance often shows up as policy phrasing that is too broad to operationalise, such as “use responsible AI” or “apply human oversight,” with no concrete trigger for intervention. It also shows up when agent or system actions are visible only after execution, which means the review process can explain what happened but not prevent the outcome. NHIMG’s Agentic AI Security Policy Template is useful here because it forces the reader to distinguish policy intent from controls for registration, oversight, monitoring, and retirement.
Another common failure is a weak connection between identity and action logs. If you cannot tie a specific agent, service, or delegated actor to a specific tool call, model action, or side effect, then accountability is too thin to support real governance. That becomes especially obvious when the team can describe governance in a presentation but cannot reproduce the evidence trail for a single risky action. For broader governance design, the NIST AI Risk Management Framework and the NIST AI 600-1 GenAI Profile both stress controls that are measurable in operation, not just defined in principle.
A third sign is that exceptions are handled informally. If risky use cases are allowed because someone “signed off in Slack” or because the business wanted speed, the governance model is probably absorbing exceptions instead of constraining them. NHIMG’s AI Security Platform Buyer's Guide helps practitioners test whether tooling supports real enforcement, telemetry, and runtime guardrails rather than just reporting.
Why runtime control is the real dividing line
The most reliable dividing line is whether the organisation can block or constrain a risky action while it is happening. Live enforcement can mean denying a tool call, forcing step-up approval, limiting data access, or stopping an action when it violates policy. If the only control is retrospective review, the programme is managing records, not risk.
That is why governance maturity is better judged by runtime behaviour than by the presence of committees. A team can have a policy, a register, and a quarterly review cycle and still fail the moment an agent or automated workflow takes an unapproved path. The strongest external benchmark for this kind of operational governance is the ISO/IEC 42001:2023 AI Management System Standard, which treats accountability, controls, and continual improvement as management-system obligations rather than one-time documentation tasks.
For organisations that need a board-level view of that gap, NHIMG’s Agentic AI Identity Risk Board Briefing is a useful way to translate runtime governance into questions about ownership, metrics, and risk appetite. The operational question is simple: if the control cannot stop, shape, or attribute the action in production, then the governance layer is not yet doing its job.
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 addresses the attack surface, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern, Map, Measure, and Manage | AI governance maturity depends on measurable controls and accountability for risky AI actions. |
| Recommendation — Define runtime controls and metrics that prove AI decisions are governed in operation. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Governance fails when actions cannot be traced to an accountable actor and event trail. |
| AC-6 — Least Privilege | A checkbox program often allows excessive action authority without meaningful constraint. | |
| Recommendation — Log AI actions and approvals so each risky decision is attributable and reviewable. Limit AI and operator permissions to the minimum needed for the task. | ||
| ISO/IEC 42001:2023 | 4.4 — AI management system | The subject is AI governance maturity and whether controls operate as a management system. |
| Recommendation — Operate AI governance as a managed system with assigned responsibilities and continual control. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Weak linkage between agent identity and action logs is a core agentic governance failure. |
| Recommendation — Bind agent identities and privileges to each tool-capable action. | ||
Practitioner Guidance
What to verify: Ask for one end-to-end example of a high-risk AI action and verify three things: the live enforcement point, the actor-to-action log trail, and the exception path. If the team can only produce policy documents or post-event reviews, treat the governance model as immature.
What to prioritise: Start with the controls that change runtime behaviour, not the controls that improve reporting. In practice, that means proving that identity, permissions, and action logging line up before expanding policy coverage or governance committees.
Common mistake: Teams often confuse approval workflows with governance. Approval alone does not reduce risk if the system still allows the same action to proceed unblocked through another path or after the approval condition has gone stale.
Practitioner takeaway: A real governance programme changes what the system can do in the moment, while a checkbox programme only describes what the organisation hoped would happen afterwards.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org