AI agent security needs enforcement, not just visibility

At a glance

What this is: This analysis argues that AI agent security is moving from visibility problems to runtime enforcement problems, with agent access governance now the decisive control gap.

Why it matters: IAM, IGA, PAM, and NHI teams need to treat AI agents as governed identities because discovery without enforcement leaves access paths, credentials, and audit trails unmanaged.

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.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Aembit's analysis of AI agent visibility, enforcement, and blended identity

Context

AI agent security is the problem of governing software entities that can choose actions, tools, and timing at runtime. In practice, that means conventional identity controls struggle when an agent can route around static assumptions about access scope, approval flow, and session length. The primary keyword here is AI agent security, and the article argues that visibility alone does not close the control gap.

At Identiverse 2026, Aembit used its Copilot Studio integration announcement as the backdrop for a broader market observation: the category is still early, terminology is unsettled, and many products stop at discovery. That matters for IAM and NHI teams because inventory without runtime enforcement creates a record of exposure, not a reduction in exposure.

The article’s core claim is that teams should stop treating agent access as a post hoc logging problem. If AI agents are already in production, the governance question becomes which actions they may take, which tools they may use, and when policy must block execution before access is granted.

Key questions

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. The control model should evaluate agent context, user context, requested resource, and action type at runtime, then issue only task-scoped access that expires when the job is done. That keeps attribution intact while limiting privilege expansion.

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. AI agents can choose tools and actions dynamically, so inherited user rights and fixed machine scopes both overstate what they should receive. The result is too much privilege for too long, which is a governance failure, not just a tooling issue.

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. Visibility documents the problem after the fact, but it does not prevent access, block tool use, or enforce policy at the moment a request is made. That leaves the organisation exposed even when its reporting looks mature.

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.

Technical breakdown

Why visibility does not equal runtime enforcement

Visibility tools answer what agents are connected to and what they have already accessed. Runtime enforcement answers whether a specific request should be allowed before the action occurs. That distinction matters because AI agents can make access decisions based on request content, context, and task progression, which means post-event logging does not stop overreach. In identity terms, discovery creates an inventory, but it does not create control. For AI agent security, the decisive layer is policy evaluation at the moment of access, not dashboard completeness after the fact.

Practical implication: require runtime policy decisions for agent actions instead of relying on discovery dashboards or retrospective audit alone.

Why human IAM and workload identity both fall short

Human IAM assumes a person has a durable identity and a relatively stable pattern of access. Workload identity assumes deterministic software whose privileges can be modeled in advance. AI agents sit between those assumptions: they act on behalf of users, but they also choose actions dynamically, so neither inherited human rights nor fixed machine scopes fully fits. That creates a governance gap around attribution, scope, and revocation. The result is a control model that is too broad when copied from human IAM and too rigid when copied from workload identity.

Practical implication: design agent-specific access models rather than extending user permissions or service-account patterns unchanged.

What blended identity is trying to solve

Blended identity is an access model that ties an agent to the associated human session while issuing short-lived credentials scoped to a specific task. The point is to preserve attribution without handing the agent the full durable rights of the user. That matters because an agent that impersonates a user across sessions creates excess privilege and weak accountability. Blended identity tries to preserve both agent context and user context so audit logs remain meaningful and access stays task-bound. It is a response to dynamic agent behaviour, not a rebranding of standard federation.

Practical implication: bind agent access to task scope and session context, then expire privileges when the task is complete.

NHI Mgmt Group analysis

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.

AI agent security exposes a governance gap that spans human IAM and NHI practice. Human IAM assumes durable person-centric identity, while machine identity assumes predictable software behaviour. Agents break both assumptions because they act on behalf of users but select actions at runtime. The implication is that teams must stop forcing one identity model to do two jobs it was never designed for.

Runtime authorization is the named concept that best captures the market shift. The real control question is not whether an agent can be discovered, but whether each request can be evaluated before execution against user context, agent context, and policy. This is where NHI governance and agentic AI security converge, and it is the point practitioners should use to separate marketing from control.

Blended identity is an attempt to preserve attribution while constraining privilege. The article’s model ties the agent to the human session but does not let it inherit unlimited durable rights. That reflects a broader field truth: auditability alone does not make access safe, and inheritance alone does not make access accountable. Practitioners should read this as a signal to redesign authorization boundaries, not just logging.

The market is shifting from agent inventory to agent governance. That shift will favour tools that can evaluate actions, block unsafe requests, and expire access cleanly, while forcing teams to re-examine where human approval still belongs. The practitioner takeaway is to treat agent access as a policy architecture problem now, before volume makes retrofit expensive.

From our research:

• 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.
• For a broader framework view, read OWASP NHI Top 10 for how runtime agent risks map to policy and privilege decisions.

What this signals

Runtime authorization is becoming the practical dividing line in AI agent security. Teams that stop at discovery will accumulate more evidence than protection, which means the programme may look mature while access risk keeps growing. With 80% of organisations already reporting agents acting beyond intended scope, the governance gap is now operational, not theoretical.

Blended identity points to a wider shift in how identity programmes must think about attribution. The useful question is no longer whether an agent exists, but whether its access can be bound to a task, a user session, and a policy decision that expires cleanly. That is where NHI governance, PAM, and agentic AI controls start to converge.

Visibility-first programmes should expect pressure to add blocking controls, approval logic, and short-lived access. If agent deployments keep expanding, the most credible architectures will be the ones that can prove who acted, on whose behalf, and under what policy at the moment of access, not just in a later report.

For practitioners

• 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. A dashboard is useful for visibility, but it does not block unsafe tool use or unauthorized data access.
• Define agent-specific authorization boundaries Do not inherit the full permissions of the human user or reuse a generic service account pattern unchanged. Scope access to the specific task, the specific tool, and the specific context that justified the request.
• Bind access to session context and expiry Issue short-lived credentials for the agent session and terminate them when the task is complete. That preserves attribution while reducing the chance that an agent retains rights across unrelated actions or future sessions.
• Map approval points to high-risk actions Identify which requests still require human approval before execution, especially when an agent could reach sensitive systems, exfiltrate data, or route around the control point. Approval should be exception-based, not a default excuse to avoid policy design.

Key takeaways

• AI agent security is shifting from inventory to enforcement, and discovery alone cannot control runtime behaviour.
• Most organisations are already seeing agents exceed intended scope, which turns governance design into an immediate operational priority.
• Identity teams should build task-scoped, policy-driven access for agents now, before exceptions and inherited permissions become the default.

Key terms

• Runtime Authorization: Runtime authorization is the decision made at the moment a request is made, rather than after the fact, about whether an identity may proceed. In AI agent security, it evaluates agent context, user context, requested action, and policy before access is granted.
• Blended Identity: Blended identity is an access model that binds an AI agent to the human session it supports while keeping the agent as a distinct governed identity. It preserves attribution and limits privilege by issuing short-lived, task-scoped credentials instead of inheriting the user's full rights.
• Visibility Without Enforcement: Visibility without enforcement means an organisation can see what identities are doing but cannot stop or constrain those actions in real time. It produces logs, dashboards, and inventories, but it does not itself prevent misuse, overreach, or policy bypass.
• Task-Scoped Access: Task-scoped access is permission granted only for the specific action or workflow currently being performed. For AI agents, the scope should be narrow, time-bound, and tied to the request context so access ends when the task ends rather than persisting across sessions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: AI agent security at Identiverse 2026, where visibility is not enough. Read the original.