AI agents today already access SAP, Salesforce, and ServiceNow systems independently, often with far-reaching permissions and no clear governance. That creates a new reality for security teams: each of these instances is an identity with its own permissions, access, and risks. Unlike an employee, it works around the clock, makes decisions in milliseconds, and appears in no HR system. Anyone who doesn't manage these agents like employees loses control over their own core systems.
An underestimated risk
The problem isn't theoretical. A Saviynt study among German CISOs and CIOs found that 93 percent confirm AI identities already access core systems, but only 25 percent govern that access with clear policies. More than half have no complete overview of the AI identities in their environment, and 76 percent have already discovered unsanctioned AI tools, often with their own credentials and elevated permissions.
Three scenarios show where the risk shows up in practice. A company pilots an AI agent to automate compliance checks; after the pilot ends, the project is shelved, but the agent keeps running because nobody registered it in the identity system, still holding access to financial data and audit systems. An external vendor supplies an AI agent for predictive maintenance that accesses production data; the vendor gets compromised, and the agent's credentials fall into the attacker's hands, who then moves through the company's systems undetected. And a business department builds its own AI agents on a low-code platform with access to customer data and ERP systems, without IT security ever finding out. In all three cases, perimeter security doesn't help, since the access comes through an already legitimized identity, and classic identity management systems don't apply because they were built for human users.
Why agents behave differently from employees
Security leaders know the joiner-mover-leaver process for employees; for AI agents, most companies have nothing comparable. An employee gets hired and eventually leaves the company; an AI agent, by contrast, can run indefinitely unless someone actively decommissions it. If it hits an obstacle in a workflow, it can try to obtain additional permissions, at machine speed rather than the pace of a helpdesk ticket. In agentic AI architectures, agents also delegate tasks to other agents, passing along permissions the original agent never had. Making things harder, AI agents don't only originate in the IT department: business units build them on low-code platforms, developers deploy them in cloud environments, and external vendors bring their own. That grows the attack surface in places security teams often can't even see.
Five measures for security leaders
The following steps can be implemented regardless of the platform in use and follow the least-privilege principle as well as the requirements of NIS2, DORA, and Germany's KRITIS umbrella law. First: inventory AI agents, meaning a complete stocktake of all agents, both authorized and shadow AI, by analyzing API access to core systems, scanning cloud environments, and specifically surveying business departments. Without an inventory, no governance is possible.
Second: assign every agent a human owner, a named person responsible for its permissions, activities, and decommissioning, comparable to ownership practices already established for service accounts. Third: introduce lifecycle processes, meaning registration, approval, regular recertification, and decommissioning, with an expiration date for every agent. When a pilot ends, the agent gets deactivated; when a contract with an external vendor ends, its credentials get automatically revoked.
Fourth: apply least privilege consistently. AI agents should only get the permissions they need for their defined task, and just-in-time access, granting rights temporarily and only when needed, matters even more for AI agents than for human users, since agents are active around the clock. Standing privileges are a particularly high risk with AI agents. Fifth: monitor access in real time, since quarterly manual recertifications aren't enough for agents that make decisions in milliseconds. What's needed is real-time monitoring with automated alerts for deviations from defined behavior, covering both access to company applications and communication between agents.
Growing regulatory pressure
NIS2 requires companies to maintain traceable control over privileged access, DORA demands strict control of ICT risks and third-party access from financial firms, Germany's KRITIS umbrella law obliges operators of critical infrastructure to meet higher security standards, and the EU AI Act demands transparency and traceability for AI systems. None of these regulations distinguish between human and machine identities; the obligation to maintain control applies to all. Yet according to the Schwarz Digits Cyber Security Report 2026, nearly half of German companies mistakenly believe they aren't affected by NIS2, and 54 percent rate the cyber risk from AI as nonexistent. The gap between regulatory requirements and operational reality is therefore considerable.
The decisive question isn't what opportunities artificial intelligence offers, but who or what accesses critical systems with which rights. AI agents are no longer just tools; they increasingly act as independent digital actors and must therefore be governed like identities. Anyone who can't establish that transparency loses control over their own infrastructure.