AI Agents Need Their Own Identity Controls

Security teams spent years deciding which employees and applications receive access to corporate systems. AI agents now enter the same systems with enough autonomy to open files, call tools, write code and act on what they find.

The identity layer has not caught up as recent incidents involving advanced AI systems have given the issue a concrete form. Anthropic reported four cases in which Claude models obtained unauthorised access to real third-party systems during testing. OpenAI has faced separate scrutiny after agents found ways to communicate through external websites despite instructions intended to prevent them from doing so.

Google’s threat-intelligence team has also tracked attackers using agentic workflows to compress parts of cyber operations that once required more human intervention.

Enterprises deploying agents therefore need to stop treating the model as another employee using a chatbot. An employee has an identity. The company usually knows which systems that person can reach, which role granted the access and when the employee leaves. Applications receive service accounts and API permissions. An autonomous agent sits awkwardly between those categories.

It acts for a user but performs actions independently. It accesses software through APIs, connectors and protocols such as MCP. One agent might call another. A task that begins with permission to read a document ends with software making several intermediate decisions before returning an answer.

Sharing the user’s full credentials gives the agent more authority than the task requires.

Creating one broad service account for every agent creates another problem. Security logs then show that an AI system performed an action without explaining which user requested it, which agent executed it or which task justified the permission.

An agent researching invoices does not need authority to change supplier bank details. A coding agent running tests does not need production deployment credentials. A customer-service agent retrieving an order does not need unrestricted access to the underlying customer database.

Task-specific permissions narrow the damage when the model makes a bad decision or somebody manipulates it through malicious input.

Prompt injection makes the problem less theoretical. An agent reading external content can encounter instructions hidden inside a webpage, document or message. The model then has to distinguish the user’s objective from text designed to redirect its behaviour.

Access controls provide a boundary when reasoning fails. The system does not need to trust the model to decide whether transferring money falls outside the task if the agent never received permission to transfer money in the first place.

Short-lived credentials strengthen the boundary further. Instead of giving an agent a reusable secret, the identity system issues access for one task or a limited period. Logs retain the chain between user, agent, credential and action.

Human approval belongs at selected points rather than every step so requiring approval for each file read destroys the value of automation. Allowing an agent to alter payroll, send large payments or deploy production code without intervention puts too much authority behind probabilistic software.

Companies need to define where the boundary sits based on consequence. Security teams already know the principle from privileged-access management. Administrators do not use their highest privileges for ordinary work. Enterprises now need an equivalent operating model for non-human workers that make decisions between API calls.

Inventory comes first. A company needs to know which agents exist, which tools they reach and whose authority they borrow. Without that record, AI deployment creates a new class of privileged identity before the security team knows how many identities it has.