For years, organizations have focused on securing human users, service accounts, applications and machines.
Now, a new category of identity is entering the enterprise: the AI agent.
Unlike traditional AI assistants that mainly generate answers, agentic AI systems can reason, make decisions, access applications, retrieve sensitive data, call APIs and execute actions with limited human involvement.
An AI agent may soon be able to:
- Read and respond to emails
- Access customer or employee records
- Modify cloud configurations
- Generate and deploy code
- Approve or initiate workflows
- Communicate with other agents
- Trigger financial or operational transactions
This capability can deliver significant productivity improvements. It can also create a new class of highly privileged, autonomous identities.
The question is no longer only, “Is the AI model secure?”
Organizations must also ask:Who is the agent, what is it permitted to access, who is responsible for it and how can its authority be withdrawn?
From Model Risk to Action Risk
Traditional generative AI security often focuses on risks such as prompt injection, sensitive-information disclosure, insecure output handling and data poisoning.
Agentic AI expands the problem.
An agent does not simply produce content. It can translate that content into action by using tools, credentials, APIs and enterprise applications.
A manipulated chatbot may provide an incorrect response. A manipulated AI agent could change a configuration, disclose sensitive information, delete data or execute an unauthorized transaction.
This is the difference between model risk and action risk.
The greater an agent’s autonomy, connectivity and access privileges, the greater its potential blast radius.
Recognizing this shift, NIST launched its AI Agent Standards Initiative in 2026 and began examining how established identity and authorization practices can be applied to software and AI agents.
OWASP’s Top 10 for Agentic Applications also highlights risks such as agent goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, insecure agent communication and rogue-agent behaviour.Agent security is quickly becoming an identity-security challenge.
Why Every AI Agent Needs Its Own Identity
An agent should never operate as an invisible extension of a human account or through a shared, permanently privileged credential.
Every production AI agent should have a unique and verifiable identity.
That identity should establish:
- The agent’s business purpose
- Its human or departmental sponsor
- The environment in which it operates
- The tools and information it can access
- Whether it acts independently or on behalf of a user
- The actions it is authorised to perform
- The date its access must be reviewed or withdrawn
Separate identities make it possible to enforce least privilege, monitor behaviour, investigate incidents and revoke access without affecting unrelated users or agents.
If multiple agents share the same identity, security teams may be unable to determine which agent performed an action or whether it was initiated by a user, an agent or a compromised integration.Accountability begins with identity.
Five Identity Risks Created by AI Agents
1. Excessive privileges
Agents are often given broad access because developers want them to complete workflows without interruptions.
An agent that only needs to read support tickets should not be able to delete them. An agent that recommends cloud changes should not automatically have permission to deploy those changes.
Convenience must not replace least privilege.
2. Agent sprawl
Business teams may create AI agents faster than security and IT teams can discover or govern them.
Without a central inventory, organizations can accumulate unknown, duplicated or abandoned agents connected to sensitive systems.
This resembles service-account sprawl, but with an added layer of autonomy.
3. Shared or inherited credentials
An agent may inherit the permissions of its creator or use a shared API key. If the agent is compromised, an attacker may gain the same access.
Long-lived credentials also make revocation and attribution more difficult.
4. Goal hijacking and tool misuse
Malicious instructions hidden inside emails, documents, websites or external data can influence an agent’s behaviour.
If the agent can access powerful tools, manipulated instructions may lead to unauthorized data retrieval, message sending, code execution or configuration changes.
5. Incomplete audit trails
Traditional logs may record that an API was called without explaining which agent initiated it, which user request triggered the action or what information influenced the decision.
Security teams need visibility across the complete chain:
Human request → Agent decision → Tool invocation → System action → Business outcomeWithout this context, investigation and accountability become extremely difficult.
Building an Identity-First Security Model for AI Agents
Organizations do not need to abandon their existing security foundations. They need to extend them to autonomous systems.
A practical identity-first approach should include the following controls.
Discover and classify every agent
Maintain a central inventory of production and experimental agents.
Record the agent’s owner, purpose, environment, connected systems, data access, model, tools and operational risk.
Assign a unique identity
Every agent should have its own managed identity rather than using a shared account or impersonating its creator.
The organization must be able to distinguish between:
- A human acting directly
- An agent acting independently
- An agent acting on behalf of a human
Enforce least-privilege access
Access should be limited by task, resource, environment, time and risk.
An agent should receive only the permissions required for its approved purpose. Privileged access should be temporary wherever possible.
Introduce approval gates
High-impact activities should require explicit human approval.
These may include:
- Deleting information
- Sending external communications
- Modifying access permissions
- Deploying code
- Changing production configurations
- Making payments or contractual commitments
Autonomy should be proportional to risk.
Protect credentials and tokens
API keys, secrets and access tokens should be stored in approved secrets-management systems, rotated regularly and prevented from appearing in prompts, memory or logs.
Short-lived credentials are preferable to permanent access.
Monitor agent behaviour
Security teams should establish normal behaviour for each agent and detect unusual actions, access patterns, tool usage or data movement.
Logs should capture the agent identity, initiating user, requested objective, tools invoked, resources accessed and final action.
Govern the complete lifecycle
Agents should be provisioned, reviewed and decommissioned through a controlled lifecycle.
When an owner leaves, a project ends or an agent is no longer required, its credentials and access must be revoked immediately.
Test before granting autonomy
Organizations should evaluate agents for prompt injection, excessive agency, tool misuse, data leakage, privilege escalation and unexpected behaviour before production deployment.
Security testing must cover the complete agent workflow—not only the underlying model.
Questions Leaders Should Ask Today
Before deploying an AI agent, security and business leaders should be able to answer:
- Does this agent have a unique identity?
- Who is accountable for its actions?
- Which systems, tools and datasets can it access?
- Are its permissions limited to its approved purpose?
- Which actions require human approval?
- How are its credentials protected?
- Can every important action be traced and explained?
- How quickly can its access be suspended?
- What happens if its instructions, memory or tools are compromised?
- When will its access and business need be reviewed?
If these questions cannot be answered, the agent is not ready for unrestricted enterprise access.
The Next IAM Challenge Has Already Arrived
AI agents are becoming part of the enterprise workforce, but they cannot be governed exactly like employees or treated merely as traditional service accounts.
They combine machine speed, delegated authority, dynamic decision-making and access to business systems.
That combination makes identity the control plane for autonomy.
Organizations that establish agent discovery, unique identities, least privilege, approval gates, lifecycle governance and behavioural monitoring early will be better positioned to adopt agentic AI securely.
Those that delay may find themselves facing the next major identity crisis: thousands of autonomous, over-permissioned and poorly governed digital actors operating inside the enterprise.
The future of AI security will not depend only on building more capable agents.It will depend on ensuring that every agent is identifiable, accountable and authorised.
– Wiseman CyberSec
