Notifications
Clear all
Topic starter
25/06/2026 12:17 am
TL;DR: AI risk management now spans bias, privacy, security, drift, and regulatory exposure across the AI lifecycle, according to WitnessAI’s overview of frameworks and control patterns. The harder problem is that governance built for static systems does not fully cover runtime AI behaviour, especially when agents can act, adapt, and affect outcomes in motion.
NHIMG editorial — based on content published by WitnessAI: What Is AI Risk Management?
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should organisations govern AI systems that can access data and tools?
A: Organisations should govern AI systems as runtime identities, not just as software features.
Q: Why do AI risk controls need to include identity and access management?
A: Because many AI failures are caused by overbroad access, weak secret handling, and poor runtime visibility rather than model logic alone.
Q: What do security teams get wrong about AI governance?
A: They often treat governance as documentation instead of operational control.
Practitioner guidance
- Map AI systems by identity type and access surface Separate human-operated tools, NHI-backed services, and AI agents in your inventory so you can assign the right governance model to each runtime identity.
- Tie AI risk reviews to permission changes Require a fresh risk review whenever an AI system gets new data sources, broader API access, or tool execution rights.
- Validate outputs at the point of use Add input and output validation where AI decisions feed downstream workflows, especially in finance, healthcare, and cybersecurity use cases.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- A fuller walkthrough of AI risk categories and how the article maps them to governance decisions.
- Additional detail on implementing monitoring, validation, and access controls across AI workflows.
- The vendor's explanation of how its runtime security model applies to models, applications, and agents.
- Context on the enterprise AI control posture it says its platform is designed to support.
👉 Read WitnessAI's overview of AI risk management and AI governance →
AI risk management and agent governance: where do controls fail?
Explore further
25/06/2026 9:09 am
AI risk management is becoming an identity governance problem, not just a model governance problem. The article frames risk through bias, transparency, privacy, and compliance, but the real control boundary is who or what can act on behalf of the system. Once AI systems can retrieve data, call tools, or influence workflows, IAM, secrets, and lifecycle controls become part of the risk model. The implication is that AI governance programmes now need identity-aware control design, not isolated policy statements.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, while 38% have no or low visibility, according to The State of Non-Human Identity Security.
- Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, and 60% plan to do so within the next twelve months.
A question worth separating out:
Q: How do identity teams extend AI risk management into existing programmes?
A: By treating AI services and agents as governed non-human identities. Identity teams should fold them into secrets management, access reviews, logging, and offboarding processes, then align those controls with the AI risk framework. That approach connects AI governance to the same operational discipline used for workloads and service accounts.
👉 Read our full editorial: AI risk management is widening from policy to runtime control
