Notifications
Clear all
Topic starter
24/06/2026 11:29 pm
TL;DR: AI agent governance now has to address agents that make decisions, call APIs, and act across workflows in real time, creating new exposure around access control, observability, and compliance, according to WitnessAI. Governance that treats agents like static software will miss the runtime behaviour that actually drives risk.
NHIMG editorial — based on content published by WitnessAI: AI Agent Governance
By the numbers:
- By 2026, more than half of enterprises will deploy AI agents to automate functions like support, analysis, and content generation.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams govern AI agents that can call tools and APIs?
A: Security teams should treat AI agents as governed identities with constrained runtime access, not as ordinary applications.
Q: Why do AI agents create more governance risk than static automation?
A: AI agents create more governance risk because they can choose actions at runtime, change tool usage based on context, and cross workflow boundaries without a human step between every decision.
Q: What breaks when AI agent access is reviewed like normal application access?
A: What breaks is the assumption that a single access review can describe behaviour that changes every time the agent runs.
Practitioner guidance
- Define agent-specific access boundaries Map every agent to the exact data sources, APIs, and actions it may use, then review those entitlements as runtime permissions rather than generic application access.
- Inventory and retire agents as governed identities Track each agent from creation to decommissioning, including ownership, approved tools, and retirement criteria, so abandoned agents do not retain access after their business purpose ends.
- Require decision logging before production use Capture prompts, tool calls, policy outcomes, and downstream actions so investigators can reconstruct what the agent did and whether it stayed within its intended scope.
What's in the full article
WitnessAI's full article covers the operational detail this post intentionally leaves for the source:
- How the vendor frames lifecycle, risk management, security, and observability as one governance operating model
- The vendor's examples of authentication, authorization, and runtime protection in agentic workflows
- The article's discussion of guardrails for generative outputs and zero-trust architecture in AI environments
- The vendor's explanation of how observability supports compliance, accountability, and post-incident analysis
👉 Read WitnessAI's analysis of AI agent governance and runtime controls →
AI agent governance: are your controls keeping up with autonomy?
Explore further
25/06/2026 8:23 am
AI agent governance exposes a runtime identity problem, not just a model-risk problem. Once an agent can choose actions and call tools, the control question shifts from whether the model is allowed to exist to what the agent may do at the point of execution. That makes access scope, tool gating, and auditability central to governance. The practical conclusion is that agent oversight belongs inside identity and access operations, not only inside AI policy.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent makes an unauthorised decision?
A: Accountability should sit with the business owner of the agent, the team that approved its permissions, and the control owners responsible for monitoring and retirement. If no one can explain the agent’s scope, data access, and decision trail, accountability has already failed. Governance requires named ownership before the incident, not blame after it.
👉 Read our full editorial: AI agent governance needs runtime controls, not policy overlays
