TL;DR: Agentic AI systems can query databases, call APIs, delegate tasks, and trigger downstream actions at machine speed, which means legacy tools often miss harmful activity that still looks legitimate, according to WitnessAI. The governance problem is not just visibility but the assumption that human-paced review can keep up with autonomous runtime decisions.
NHIMG editorial — based on content published by WitnessAI: Agentic AI risk management guide
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when AI agents inherit access from users and service accounts?
A: The main failure is that inherited access can be broader than the agent’s actual task, so privilege becomes easier to reuse than to govern.
Q: Why do agentic AI systems complicate existing IAM and PAM controls?
A: They complicate them because IAM and PAM were built around stable identities, human-paced approvals, and entitlements that are reviewed after use.
Q: How do organisations know if AI agent governance is actually working?
A: Look for evidence that every agent action is attributable, every high-risk action is constrained at runtime, and every external tool connection is inventoried.
Practitioner guidance
- Inventory every agentic identity path Map each agent, token, integration, data source, and external API connection before allowing production use.
- Enforce runtime limits by action risk Assign low-risk, medium-risk, and high-risk action tiers, then require confirmation or explicit approval before an agent can perform irreversible changes, sensitive reads, or downstream writes.
- Separate agent telemetry from human telemetry Log the initiating user, the agent, each tool call, and each downstream effect so reviews can distinguish normal human sessions from autonomous execution chains.
What's in the full article
WitnessAI's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step runtime policy design for low-risk, medium-risk, and high-risk agent actions
- The full control architecture for network-level AI visibility across employees, models, apps, and agents
- Operational guidance for immutable audit trails, including the fields to capture for tool calls and handoffs
- Incident response details for revoking agent credentials and quarantining MCP connections before damage spreads
👉 Read WitnessAI's guide to agentic AI risk management and runtime controls →
Agentic AI risk management: where do legacy controls break down?
Explore further
Agentic AI creates an assumption collapse, not just a control gap. Access review processes were designed for privilege that persists long enough to be observed, certified, and revoked on a human cadence. That assumption fails when an AI agent can acquire, combine, and consume access within a single operational session. The implication is that governance must be rethought around runtime authority and not around periodic inspection of stable entitlements.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: How should teams respond when AI agents use third-party tools and MCP connections?
A: Teams should treat those connections as access-bearing dependencies, not as ordinary integrations. That means approving them before connection, recording them in a registry, and validating what data they can reach and what actions they can trigger. If the dependency can modify enterprise state, it belongs in the identity governance process.
👉 Read our full editorial: Agentic AI risk management exposes legacy IAM control gaps