Agents already outnumber human operators in many environments, yet most security programs still treat them as scripts.

Diagram showing an AI agent with shadow deployment, standing privilege and long-lived credentials reaching production data, CI/CD pipelines and cloud roles

AI agents are no longer experimental side projects. They write code, query production databases, trigger infrastructure changes, call third-party APIs, and act on behalf of users across SaaS platforms. In many environments they already outnumber human operators. Yet most security programs still treat them as temporary scripts or just another service account. That gap is becoming dangerous.

The new identity problem

Traditional machine identity focused on certificates, API keys, and service principals. AI agents add a different layer of complexity. They can:

  • Spawn sub-agents or tool chains dynamically
  • Inherit or escalate privileges through MCP servers and LLM tool use
  • Operate across multiple clouds and SaaS platforms at once
  • Appear and disappear without formal provisioning

The result is a growing population of poorly documented, over-privileged, and sometimes completely unknown agents. Shadow agents, those spun up by developers or business teams without security review, are especially common. They often carry long-lived credentials, broad access scopes, and no clear ownership.

From a penetration testing perspective this looks familiar: the same pattern we have seen with abandoned cloud instances, forgotten service accounts, and unmanaged secrets. The difference is speed and scale. An agent can accumulate access far faster than a human-managed identity.

What we are actually seeing in the field

Several recurring issues keep showing up:

  1. Developers and other teams are running agents in Anthropic, OpenAI, Gemini, AWS Bedrock, Copilot Studio, Salesforce AgentForce, n8n, CrewAI, and desktop tools without security teams knowing. These agents often inherit long-lived API keys or broad permissions.
  2. Many agents get far more access than their actual task requires. Least privilege is rarely applied at the identity level.
  3. Once an agent starts acting, stopping a malicious or compromised sequence is often slow or impossible.
  4. Security teams struggle to answer basic questions: Who owns this agent? What credentials does it use? What tools and data can it touch? What happens when it is decommissioned?
  5. Mapping agent behaviour to frameworks like NIST AI RMF, the EU AI Act, SOC 2 or ISO 27001 is still mostly manual and incomplete.

These conditions create high-value targets for both external attackers and malicious insiders. A compromised or manipulated agent can move laterally, exfiltrate data, or abuse privileged functions faster than most human operators.

What good controls should look like

Defensible environments need several capabilities that traditional IAM and PAM tools were never designed for:

  1. Full discovery. Visibility across all agents, their LLMs, tools including MCP servers, credentials, and the identities an agent can act as or on behalf of. Otherwise you are testing blind.
  2. Task-based least privilege. Fine-grained policies that limit agents to only the tasks necessary for their role, enforced before they run.
  3. Runtime monitoring and response. Identification of unusual access, privilege-escalation attempts and intent mismatches, with the ability to end sessions immediately.
  4. Lifecycle management. Tracking from deployment through decommissioning, including ownership and automated remediation of posture drift.
  5. Audit-ready evidence. Continuous posture assessment against relevant frameworks rather than point-in-time screenshots.

What effective governance looks like

A workable approach to AI agent identity security needs to cover the full lifecycle rather than bolt controls on after the fact.

  1. Discovery first. You cannot protect what you cannot see. Effective platforms pull signals from EDR, MDM, network traffic, SIEM, firewalls, and native platform APIs such as AWS Bedrock, Azure AI Foundry, Salesforce AgentForce and Copilot Studio. They also intercept Model Context Protocol traffic to surface unauthorised tool connections. The output should be a living inventory, sometimes called an AIBOM, recording owner, credentials, connected LLMs, MCP servers, and the full access graph of every identity the agent can assume or act on behalf of.
  2. Posture and ownership. Once discovered, each agent needs continuous posture scoring: credential age and strength, privilege level relative to stated purpose, configuration drift, and compliance mapping. Clear ownership assignment is non-negotiable; an unowned agent is an unowned risk.
  3. Runtime control, not just policy documents. Allow-lists and deny-lists for MCP tool calls, API endpoints, terminal commands, data access and infrastructure actions should be enforced inline, before the action executes. If an agent tries to do something outside its defined task scope, the system should block it in real time. An agent kill switch, both manual and policy-driven, provides the last line of defence when anomalous behaviour appears.
  4. Lifecycle automation. Registration at deployment, continuous monitoring, least-privilege enforcement and clean decommissioning should be automated. Manual processes do not keep pace with agent creation rates.

Why this matters to security teams and pentesters

During assessments we increasingly find agents with standing access to production data stores, CI/CD pipelines and privileged cloud roles. In several recent engagements the highest-value paths involved an agent whose credentials had never been rotated and whose owner had left the company months earlier. Traditional identity tools rarely surface these relationships because the agents live outside the usual IAM inventory.

Treating AI agents as first-class identities, complete with discovery, ownership, least privilege, continuous posture and runtime enforcement, closes a gap that conventional CLM, PKI and PAM solutions were never designed to address.

AI agents are privileged non-human identities with autonomy. Leaving them ungoverned is the modern equivalent of handing every service account domain admin rights and hoping for the best. Security teams need inventory, least privilege, runtime controls and lifecycle management for agents the same way they should have them for machines and humans. Pentesters should start treating agent identity and privilege as a standard part of scope. Threat modelling the AI attack surface is where that scope usually begins.

The question is no longer whether AI agents introduce new risk. It is whether your organisation can see them, constrain them, and stop them when something goes wrong. If you cannot answer those three questions clearly today, the attack surface is already larger than you think.

All articles