Deleting or corrupting data, exfiltration of sensitive information and escalating privileges are just a few of the risks exacerbated by the expansion of AI attacks on a business through vulnerable identity services. Imagine a threat actor utilizing prompts to trigger financial transactions, modify access policies, or interact with other agents in unpredictable ways. Research indicates that a significant portion of organizations have not yet matured their defenses to handle these emerging threats posed by AI systems.
This is a reality that Meta found all too real in May, when it experienced an attack in which chatbots were used to change the email accounts of several high-profile users (including the account of a former US president), granting the attackers access to change passwords and take control of accounts. According to the BBC, after selecting the account they wanted to access, the hackers sent a message to Instagram’s Meta AI support assistant asking it to link a new email to the account and send a verification code. The bot followed through with the request, sending a code to the hacker’s email, which, when verified, was followed by an email with a link to change their password.
The boom of AI has ushered in many wonderful advancements in how humans research, monitor and detect vulnerabilities. However, it has also introduced a series of new risks to business and identity protection. Yet, understanding these risks enables an organization to create a secure and robust Identity and Access Management (IAM) service that is better prepared for the changing threat landscape.
Understanding the New AI World and Identity
When designing to protect against AI attacks, security architects need to recognize that, at their core, AI identities are still just identities. They need the same level of protection as a human identity. AI doesn’t create a paradigm; it shines a light on the existing risk posed by non-human identities within an organization. Some of the risks include gaps in governance, unclear ownership, and inefficient or non-existent life-cycle management. These gaps can be addressed by securing Non-Human Identities (NHIs) at the same level as human users. However, in most companies, these safeguards are often inefficient, immature or absent.
Concerning the Meta instance, it was a prime example of chatbots with overbroad, under-governed permissions that were allowed to execute sensitive changes to identity profiles, including email and password resets. These sensitive actions should not have been allowed to execute without a human-in-the-loop verification step. This can be viewed as an IAM gap that should have been applied to both human and non-human entities. Not securing human approval created a vulnerability that a threat actor could exploit.
So, how does an organization protect itself from this potential threat? Treat humans, bots and agents equally by adopting an identity-first, zero-trust posture for any identity seeking access to an organization’s network. These suggestions align with industry estimations that NHIs now outnumber human identities and require full-lifecycle governance.
Below are the core principles to securing IAM in the age of AI.
Principle 1: Treat AI agents and NHIs as First-Class Identities
The Cloud Security Alliance and the World Economic Forum both stress that AI agents, API Keys, service accounts and chatbots must be inventoried, governed and monitored like users, because in practice, they are users.
An Identity architecture securing against AI attacks should include a single inventory of all NHIs. That inventory must include AI agents, support bots and automation accounts. In addition, the inventory must document clear ownership for each identity (including the system, team and business owner). This will increase visibility into the identities accessing the system, improving the ability to control who accesses the network, when and why.
Principle 2: Apply Zero Trust to all Human or Non-Human Entities
According to a recent arXiv preprint, the traditional IAM protocols (OAuth, OIDC, SAML) were designed for static, human-based activities and are considered “fundamentally inadequate” for the dynamic, multi-agent demands inherent in AI environments.
To account for this shift, organizations should implement continuous verification and context-aware access controls for AI agents, not just people. Using fine-grained, policy-driven access instead of broad, standing permissions reduces the attack surface and limits the potential impact of compromised agents.
Let’s take high-frequency trading environments, for example. In these fluid situations, an AI agent may be authorized to execute trades only within predefined risk thresholds, approved markets and trading hours. If the agent attempts to access a new market, exceeds risk limits or performs an unusual action, access can be dynamically restricted or revoked until additional verification and approval are completed.
Principle 3: Apply Least Privileges and JIT to all Human and Non-Human Entities
IBM has conducted extensive work on agentic identity management and highlights that agents often accumulate privileges over time, creating invisible access paths that are not typically understood by Identity teams. They recommend enforcing least privilege on every agent, allowing only the APIs, scopes and actions necessary for a task at a specific point in time. Additionally, they advocate for the strict use of Just-in-Time (JIT) credentials, which provide short-lived tokens and ephemeral roles rather than long-lived secrets that are difficult to manage over time. This significantly reduces the risk of credential theft, privilege abuse and lateral movement, as access exists only for the duration of a specific task and automatically expires once the task is complete.
Principle 4: A Strong Architectural Design must be the First Line of Defense
The Meta incident highlights the importance of building security controls directly into system architecture rather than relying solely on operational processes. High-risk actions such as email address changes, password resets, MFA resets, role or privilege modifications and financial transactions should require additional safeguards, including step-up authentication, out-of-band verification or human-in-the-loop approval. Had these controls been embedded in the workflow, they would likely have prevented the weak verification process that allowed a chatbot to make sensitive account changes without the legitimate account owner’s knowledge. Organizations should also establish architectural standards that explicitly prohibit AI-driven support workflows from bypassing existing security controls, ensuring that AI systems remain subject to the same—or stronger—security requirements as human operators.
Principle 5: Strictly Enforce Guardrails for AI Support and Customer-Facing Bots
AI support agents should never be allowed to perform sensitive account actions without additional safeguards. Organizations should prohibit single-step account takeover scenarios and ensure that no bot can independently change a primary email address, reset MFA, or issue password reset links without verifying a second factor or requiring human approval. Policy-as-code should be used to enforce these controls consistently. For example, if the requester is an AI agent and the action involves changing account credentials or identity information, human approval should be automatically required.
Principle 6: Enforce Strong Controls Over Secrets, Tokens and Runtime Activity
Both IBM and the Cloud Security Alliance identify unmanaged tokens and hard-coded secrets as a major source of exposure in AI environments. Organizations should centralize the management of API keys, credentials and tokens within a dedicated secrets management platform and rotate them automatically and frequently.
Organizations should also implement runtime monitoring and enforcement to monitor agent behavior and answer questions such as:
- Which APIs is the agent calling?
- What data is the agent accessing?
- What changes is the agent making?
- Is the agent operating within its approved scope and permissions?
- Is the agent attempting actions that are unusual or inconsistent with its normal behavior?
Anomaly detection should be used to identify suspicious activity, such as a support bot suddenly attempting to modify multiple high-profile accounts or access data outside its normal operating boundaries.
A Critical Control Layer
As AI inundates the enterprise with millions of human and non-human identities, IAM is no longer a discipline; it’s a first and last line of defense. What used to be a manageable ecosystem of user roles and permissions has ballooned into a chaotic constellation of autonomous agents, machine identities, ephemeral workloads and AI-driven services, all demanding trust at machine speed.
Every one of these identities, whether a human employee, a micro-service, a chatbot, or an agent acting on someone’s behalf, can be compromised, manipulated, or misused in ways traditional IAM was never designed to detect. In this new AI-driven world, identity is not just a security function: it is the control layer that determines whether AI becomes an accelerant for innovation or the quickest path to a catastrophic breach.
