TL;DR: AI agent security conversations at Identiverse 2026 showed a widening gap between discovery and runtime enforcement, with attendees focused on visibility while access decisions, tool use, and approval logic remained unresolved, according to Aembit. The real risk is that teams keep accumulating agents, credentials, and exceptions before they have a governance model that can enforce access at runtime.
NHIMG editorial — based on content published by Aembit: AI agent security at Identiverse 2026, where visibility is not enough
By the numbers:
- 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 act on behalf of users?
A: Treat the agent as a distinct governed identity, not as a user clone or a generic service account.
Q: Why do existing IAM controls fall short for AI agent security?
A: Human IAM assumes durable identities with stable permissions, and workload identity assumes predictable software behaviour.
Q: What breaks when teams rely on visibility without enforcement for AI agents?
A: Teams can end up with excellent inventories, logs, and dashboards while unsafe requests still execute.
Practitioner guidance
- Separate discovery from enforcement in your control design Inventory which AI agents exist, but require a runtime decision point that evaluates each request before access is granted.
- Define agent-specific authorization boundaries Do not inherit the full permissions of the human user or reuse a generic service account pattern unchanged.
- Bind access to session context and expiry Issue short-lived credentials for the agent session and terminate them when the task is complete.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- How Aembit describes blended identity for Copilot Studio agents and why it differs from inherited user access
- The article's runtime decision flow for evaluating agent, user, resource, and policy context before granting access
- Practical examples of the questions security teams should ask before AI agents go live in production
- References to the related interview and checklist resources that expand the deployment discussion
👉 Read Aembit's analysis of AI agent visibility, enforcement, and blended identity →
AI agent visibility vs enforcement: what should teams do now?
Explore further
Visibility without enforcement is an exposure register, not an identity control. Discovery tells teams which agents exist and what they touched, but it does not decide whether the next action should be allowed. That leaves organisations with excellent telemetry and weak governance, which is a familiar failure mode in early identity programmes. The practitioner conclusion is simple: if runtime policy is absent, AI agent security remains documentation, not enforcement.
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.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
A question worth separating out:
Q: Who should own AI agent access decisions in an enterprise IAM programme?
A: Ownership should sit with the identity and security function that can enforce policy across agent, user, and resource context, with clear escalation for high-risk actions. If no one owns the runtime decision, the organisation will default to ad hoc approvals, inherited permissions, or post hoc review, all of which are weaker than policy-driven control.
👉 Read our full editorial: AI agent security needs enforcement, not just visibility