AI agent vendor evaluations are shifting to discovery, intent and governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Aizome's blog post: Enterprise evaluation of AI agent security is tightening around discovery, intent-based access, detection and governance, because legacy tools miss co-working agents and behaviour drift.

Why it matters: IAM, NHI and security teams need this shift in evaluation criteria because AI agents can accumulate access, expand scope and create governance blind spots faster than traditional controls were designed to detect.

Context

The core governance gap is no longer whether AI agents exist, but whether the organisation can inventory them, distinguish approved from shadow deployments, and understand what they are actually authorised to do. Existing cloud and endpoint models often assume a bounded asset estate and a stable permission model, which breaks down when employees build agents outside central IT and connect them to business systems.

That failure matters because agent identity is not just about naming an object in a directory. It is about understanding who created it, what credentials it inherited, which systems it can reach, and whether its behaviour still matches the purpose that justified its access. Agent identity spectrum helps frame why some tools only cover the obvious part of the problem.

Key questions

Q: How should security teams discover shadow AI agents in the enterprise?

A: Use endpoint artefacts first. Look for agent directories, service definitions, local ports, and process names that prove the software is installed and active. Network traffic alone is too ambiguous because legitimate browser and API activity can look identical to agent behaviour. Discovery should produce an inventory of where the agent runs, what it can reach, and whether it is sanctioned.

Q: What is the difference between agent permissions and agent intent?

A: Agent permissions are the actual technical rights granted to an agent, such as API scopes, service account roles, or tool-specific access. Agent intent is the goal the agent is authorised to pursue, such as drafting, retrieving, or updating records. Good control keeps permissions narrower than intent, so the agent can decide within a bounded mission without gaining broader authority.

Q: Why do AI agents create new governance risks in security operations even when they reduce alert fatigue?

A: AI agents can compress investigations and improve coverage, but they also shift decision-making into systems that may act quickly and with incomplete context. That creates risk around over-trust, unclear accountability, and hidden autonomy. Organisations need policy limits, access scoping, logging, and clear escalation paths so faster analysis does not become uncontrolled action.

Q: When should security teams prioritise agent-native detection over endpoint controls?

A: Security teams should prioritise agent-native detection when the main risk comes from the agent’s tool calls, workflow chaining, delegated credentials, or prompt-driven actions that may look normal on the endpoint. Endpoint controls still matter for host compromise, but they do not show intent, tool selection, or cross-system sequences. Agent-native telemetry from the agent runtime, orchestration layer, and audit logs is the control surface for spotting misuse.

Technical breakdown

Why cloud discovery misses co-working agents

Cloud discovery tools are good at finding assets that live where security teams expect them to live. Co-working agents often do not. They may run on laptops, in desktop automation paths, or through an MCP server attached to a business user's credentials, which means the control plane sees them as ordinary user activity rather than as governed machine identities. The result is a blind spot between inventory and actual operational use. See the AI Agent Identity Security Buyer's Guide.

Practical implication: Treat business-built agents as governed identities even when they originate outside engineering and do not appear in cloud inventory.

Intent-based access control versus static permissioning

Traditional access governance answers a static question: what is this identity allowed to do. Intent-based access control adds a runtime question: does the action still match the purpose for which the agent was granted access. That distinction matters because an agent can stay technically within granted permissions while still drifting into use cases, systems or data that were never approved for that workflow.

Practical implication: Model agent access around purpose and live behaviour, not only around the permissions assigned at creation time.

Agent-native detection focuses on behaviour drift

Agent-native detection does not start from human baselines or generic network anomalies. It watches the agent as the unit of analysis, looking for changes in tool chaining, resource use, instruction-following patterns and data reach. That is a different problem from endpoint or network security, because the risk may emerge from a sequence of individually legitimate actions that together signal scope expansion.

Practical implication: Tune detections to agent-specific sequences and scope changes instead of expecting human-centric alerts to catch drift.

NHI Mgmt Group analysis

Discovery is now the first governance test for AI agents. Enterprises are past the stage where the main question is whether agents exist at all. The harder problem is whether the security team can see co-working agents that were created outside central IT and still operate under human credentials. That is not just an inventory issue. It is a control-plane failure that leaves governance blind to shadow deployments and unmanaged access paths. Practitioners should treat undiscovered agent populations as a standing governance gap, not an edge case.

Static permission models do not answer the real AI agent question. Access governance can tell you what an agent may do, but not whether its runtime behaviour still matches the task it was created for. That is why intent-based control is becoming a more useful lens than entitlement review alone. The key issue is not only overpermissioning, but mandate drift: an identity can remain formally authorised while operating far beyond its original purpose.

Agent-native detection is a different control class, not a minor tuning exercise. Detection that is inherited from endpoint or network security will miss the way agents accumulate risk through chains of legitimate actions. The named concept here is runtime mandate drift: an agent gradually exceeds its intended scope without a single obviously malicious event. That concept matters because the failure mode is behavioural accumulation, not one discrete alertable act. Practitioners need to recognise that conventional baselines often arrive too late to explain the drift.

AI governance now sits inside identity governance, not beside it. The article's evaluation questions point to a market where board accountability, cost attribution and access control are converging around the same actor class. That means AI governance can no longer be treated as a reporting layer that sits above identity. It has to answer who owns the agent, what it can reach, what it is costing and whether it is still aligned to business intent. Security teams should expect AI agent governance to be judged as an identity problem first and a tooling problem second.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Runtime mandate drift: organisations should expect AI agent risk to emerge from behaviour that remains individually legitimate while becoming collectively out of scope. That shifts programme design toward runtime observation, ownership tracking and purpose alignment, rather than relying on periodic reviews of static permissions.

Security teams will increasingly need to govern AI agents as persistent identities with business accountability, not as one-off automations. That means evaluation, monitoring and offboarding practices must follow the actor across the full lifecycle, especially when the same person can create, deploy and abandon agents outside central control.

For practitioners

• Build a complete AI agent inventory Track agents created by business users, not just engineering teams, and include where they run, who owns them and which credentials they use.
• Separate approved agents from shadow agents Require a governance record for every agent that touches production systems, including purpose, owner, data scope and retirement date.
• Review runtime behaviour against declared intent Compare what each agent is permitted to do with the systems, records and workflows it actually touches during execution.
• Instrument detections around agent-specific drift Watch for changes in tool chaining, access breadth and instruction patterns, because legitimate actions can still produce unsafe cumulative behaviour.
• Align board reporting to agent ownership Make cost, accountability and access ownership answerable in the same reporting path so governance questions can be answered without manual reconstruction.

Key takeaways

• AI agent security now turns on whether organisations can find every agent, including those built outside IT and connected through human credentials.
• The central failure mode is mandate drift, where an agent stays technically authorised while its behaviour moves beyond the purpose that justified access.
• Practitioner controls need to shift from static permission reviews to runtime oversight, ownership tracking and behaviour-based detection.

Related NHI Mgmt Group resources: AI Agent Identity Security Buyer's Guide · AI Agents vs Agentic AI · Agentic AI Security Policy Template · AI Security Maturity Model

Key terms

• Co-Working Agent: A co-working agent is an AI agent that operates alongside a person or another system and shares tasks, context, or tools during execution. It usually acts within a defined workflow, with its actions governed by delegated authority, runtime constraints, and audit logging so its decisions can be traced back to a human owner or supervising process.
• Intent-Based Access Control: An access control model that evaluates not just what an agent is requesting, but the inferred intent and context behind the request, granting or denying access based on whether the action aligns with the agent's declared purpose.
• Mandate Drift: Mandate drift is the gradual expansion of an AI system’s behaviour beyond the purpose it was originally approved to serve. It often happens through workflow expansion, prompt changes, or new integrations, and it creates governance risk even when the underlying access permissions remain unchanged.
• Agent-Native Detection: Agent-native detection is a detection method that monitors the agent itself, rather than only the host or network, to spot risky or unauthorised actions. It uses signals such as tool calls, prompt changes, workflow state, delegated credentials, and action sequences to identify misuse, policy violations, or abnormal autonomy.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.