Artificial intelligence is moving into the enterprise faster than almost any technology we have seen before.
Employees are using generative AI to write code, summarize documents, analyze information, develop marketing content, automate workflows, and improve productivity. Organizations are simultaneously embedding AI models into applications, cloud platforms, customer-facing services, and internal business processes.
The opportunity is enormous.
So is the security challenge.
A recent GenAI Security Best Practices guide from Wiz makes the challenge clear: security teams need to understand not only the technical aspects of artificial intelligence, but also the broader AI security landscape, gain visibility into how AI is being used throughout the organization, and establish processes capable of detecting and responding to AI-related threats.
The document identifies four important objectives:
Visibility. Zero critical risks. Democratization. Prevention.
Those principles provide an excellent foundation for securing enterprise AI.
But as organizations implement them, another question quickly emerges:
Who, or what, is allowed to access the AI in the first place?
Because whether we're protecting a generative AI model, its training data, an API, a cloud environment, or the administrative systems surrounding it, virtually every security control eventually encounters the same fundamental problem:
Identity.
Generative AI Creates New Security Risks
GenAI is different from conventional enterprise software.
Generative systems ingest enormous quantities of unstructured information—text, images, audio, code, documents, prompts, and other data—and produce new content based on those inputs.
That flexibility is precisely what makes GenAI useful.
It's also part of what makes securing it complicated.
The Wiz guide highlights several important threats organizations should consider, including:
Data poisoning — deliberately manipulating training data to influence an AI model's output.
Model theft — unauthorized access to and duplication of proprietary models.
Adversarial attacks — specially crafted inputs intended to cause incorrect, misleading, or harmful model behavior.
Model inversion attacks — queries designed to extract sensitive information from training data.
Supply-chain vulnerabilities — exploiting third-party software dependencies or other components in the AI ecosystem.
These threats are different technically.
But many ultimately involve something familiar:
Unauthorized access.
Who can access the model?
Who can access its data?
Who can modify it?
Who can train it?
Who can deploy it?
Who can call its APIs?
Who has administrative privileges?
And most importantly:
How certain are we that the person requesting that access is actually who they claim to be?
AI may be transforming computing, but it hasn't eliminated one of cybersecurity's oldest problems.
You still have to establish trust.
1. Eliminate Shadow AI
The first security practice identified in the Wiz document is eliminating shadow AI.
Organizations cannot secure technologies they don't know employees are using.
The problem should sound familiar.
We previously experienced: Shadow IT.
Then: Shadow cloud.
Now we have: Shadow AI.
Employees can create accounts with AI providers, install AI-enabled applications, connect services to corporate information, and begin using generative AI tools without necessarily involving security or IT.
The Wiz guide recommends developing an AI-BOM—or AI Bill of Materials—to inventory AI-related assets, establishing controls over approved and prohibited GenAI providers, and educating employees about acceptable AI use.
That's a strong starting point.
But visibility must eventually be accompanied by identity.
Once you've identified an authorized AI application, the next question is:
Who should be allowed to use it?
2. Protect the Data Feeding AI
The second recommendation may be one of the most important:
Protect your data.
AI systems can interact with enormous quantities of information, potentially including:
Customer information
Intellectual property
Financial information
Source code
Healthcare information
Employee records
Proprietary research
Contracts
Business strategies
Personally identifiable information
The Wiz document recommends discovering and classifying data according to sensitivity, encrypting information at rest and in transit, sanitizing data, implementing Data Loss Prevention policies, and auditing who can access specific information.
That last point deserves particular attention:
Audit who has access.
Because encryption can protect data.
DLP can help prevent inappropriate data movement.
Classification can identify sensitive information.
But eventually, the system still has to make a decision:
Should this identity be allowed to access this resource?
And if the identity has been compromised, the access-control policy may work perfectly while allowing the wrong person through.
3. Secure Access to GenAI Models
The third recommendation brings identity directly into the conversation:
Secure access to GenAI models.
The document specifically identifies a well-defined Identity and Access Management (IAM) configuration as a prerequisite for assets associated with GenAI deployments and recommends role-based access control.
It also recommends controls such as:
Authentication for API usage
Rate limiting
Restricted access to model weights
Limiting who can initiate training
Limiting who can initiate deployment pipelines
Monitoring excessive permissions
Following the principle of least privilege
This is exactly where the AI security conversation and the authentication conversation intersect.
You can establish perfect permissions.
But permissions only work if the identity receiving those permissions can be trusted.
Consider an administrator authorized to deploy an AI model.
The access-control system says:
This account has permission.
But cybersecurity needs to answer another question:
Is the person using that account actually the authorized administrator?
Those are two very different questions.
AI Makes Compromised Identities More Dangerous
This is where organizations should think beyond conventional IAM.
Suppose an attacker steals the credentials of someone authorized to:
Access proprietary AI models
Modify training data
Deploy models
Change guardrails
Access sensitive datasets
Retrieve API credentials
Modify AI infrastructure
From the application's perspective, the account may be authorized.
From the organization's perspective, the user isn't.
Authorization without strong authentication can become authorized access for an unauthorized person.
And as AI systems gain access to more valuable enterprise information and increasingly powerful business capabilities, compromised identities can potentially have a much greater blast radius.
4. Use Built-In LLM Guardrails
The fourth practice is implementing the security capabilities available within GenAI models themselves.
Depending on the provider and model, these controls can include:
Content filtering to remove or flag inappropriate or harmful content.
Abuse detection to identify potential model misuse.
Model configuration controls that affect how predictably the model responds.
These controls are important because security should be layered.
But guardrails shouldn't become another example of misplaced trust.
An organization might have excellent guardrails protecting ordinary users while providing administrators with the ability to modify those guardrails.
Which leads back to identity:
Who is authorized to change the security controls?
And:
How strongly have we authenticated them before allowing that change?
5. Detect and Eliminate AI Attack Paths
The fifth recommendation is attack path analysis.
Instead of looking at individual vulnerabilities in isolation, organizations should examine how multiple weaknesses could be chained together.
The Wiz guide recommends looking for:
AI model vulnerabilities
Missing patches
Malicious models
AI misconfigurations
Excessive permissions
Network exposure
Exposed secrets
Sensitive data
Weak access controls
The objective is to understand how an attacker might move through the environment and reach a critical AI resource.
The diagram on page 5 illustrates this concept particularly well: an internet-exposed system can potentially become the beginning of a path leading toward a high-value AI training resource.
This is an important shift in security thinking.
Don't just ask:
"Is this vulnerability dangerous?"
Ask:
"What could an attacker reach if they exploit it?"
We should apply exactly the same thinking to identity.
Don't just ask:
"Was this user authenticated?"
Ask:
"What can this authenticated identity reach?"
6. Monitor for Anomalies
The sixth recommendation is continuous monitoring.
The document recommends watching AI environments for unusual input and output behavior, suspicious AI-pipeline activity, unexpected latency changes, and other anomalies.
The goal is early detection.
Because prevention will never be perfect.
If something unusual happens, security teams need to identify it quickly enough to contain the blast radius.
Identity telemetry should be part of that same philosophy.
For example:
Why is this user suddenly accessing a sensitive system?
Why is an administrative identity behaving differently?
Why are repeated authentication requests occurring?
Why is access coming from an unexpected device?
Why is an account requesting resources it normally doesn't use?
Authentication shouldn't exist as an isolated doorway into the application.
Identity should become part of the security context surrounding the entire transaction.
7. Have an AI Incident Response Plan Before You Need One
The final Wiz recommendation is something organizations sometimes postpone until it's too late:
Incident response.
AI-specific incident response may require isolation, backups, traffic control, rollback procedures, integration with existing SecOps platforms, and an AI-focused incident-response plan.
The key word is before.
The worst time to decide what to do during an AI security incident is while the incident is happening.
Organizations should know in advance:
Who can disable an AI system?
Who can revoke access?
Who can modify models?
Who can restore data?
Who can initiate rollback procedures?
Who can change security policies?
And again:
How will we authenticate those people securely during an incident?
A compromised administrator account during an incident could make a bad situation significantly worse.
The Missing Layer: Strong Authentication
The Wiz document provides an excellent framework for GenAI security.
Its recommendations repeatedly intersect with:
IAM
Access controls
Permissions
Least privilege
API authentication
Data access
Administrative authority
This leads to a conclusion every organization deploying AI should consider:
AI security ultimately depends, in part, on identity security.
You can know exactly where your AI models are.
You can classify the data.
You can establish perfect RBAC policies.
You can monitor the infrastructure.
You can identify attack paths.
You can establish an incident-response program.
But if an attacker can successfully impersonate someone authorized to access those resources, many of those defenses become considerably less effective.
Passwords Are a Weak Foundation for the AI Era
This creates an interesting contradiction.
We're building some of the most sophisticated computing systems ever created.
And many organizations still protect access to them with technology developed decades ago:
The password.
Passwords can be:
Phished
Stolen
Reused
Shared
Guessed
Keylogged
Exposed in breaches
Purchased from criminal marketplaces
Traditional MFA improves the situation considerably.
But depending on the implementation, attackers may still attempt:
MFA fatigue
Push bombing
Social engineering
Adversary-in-the-middle phishing
Lookalike authentication sites
Credential and session theft
The AI era deserves an authentication architecture designed for today's threat environment.
Passwordless Authentication Changes the Equation
Instead of surrounding passwords with more defenses, organizations can eliminate dependence on reusable passwords.
A passwordless authentication architecture can use:
Something you have:
A trusted device.
combined with:
Something you are:
A locally verified biometric.
That can provide multiple authentication factors without requiring a reusable password.
For employees, the experience can become simpler.
For attackers, there is no conventional password available to steal through traditional credential phishing.
But removing the password is only part of the answer.
Authentication Intent Matters
AI systems can perform increasingly consequential actions.
That makes it important to know not only who authenticated, but whether the legitimate user actually intended to initiate the authentication.
Identité can provide contextual information during authentication on the same screen.
For example, the user can be explicitly asked:
"Did you request this authentication session?"
The screen can also present an image and three-digit verification number associated with the authentication interaction.
The distinction is important.
A generic MFA request essentially asks:
"Approve?"
A contextual authentication experience can ask:
"Did YOU initiate this?"
That's the difference between merely requesting approval and helping establish intent.
But AI Security Raises Another Authentication Question
Suppose we establish that the person accessing the AI environment is legitimate.
There's still another side to the transaction.
Is the system they're connecting to legitimate?
Attackers don't only impersonate users.
They impersonate:
Corporate websites
Cloud applications
Authentication portals
SaaS services
Banks
Healthcare portals
Microsoft 365
Internal business applications
With AI increasingly assisting attackers in generating convincing content, fraudulent destinations may become even harder for ordinary users to recognize.
A perfect copy of a login screen is still a fake login screen.
So why should authentication occur only in one direction?
Full Duplex Authentication®: Both Sides Establish Trust
This is the principle behind Identité's patented Full Duplex Authentication® (FDA).
Traditional authentication asks: "Are you the legitimate user?"
Full Duplex Authentication® adds: "Is this the legitimate destination?"
Both sides participate in establishing trust.
That's mutual authentication.
This becomes particularly relevant to AI security because AI systems increasingly sit behind APIs, portals, cloud services, administrative consoles, and enterprise applications.
A fraudulent destination may imitate the appearance of a legitimate service.
But appearance isn't identity.
Authentication should establish legitimacy rather than relying on the user to recognize it visually.
Decentralized Biometrics Matter Too
When biometrics are used, organizations should also ask:
Where is the biometric information stored?
Identité uses a decentralized architecture in which biometric verification occurs on the trusted user's device.
The biometric doesn't need to be transmitted to Identité or placed in a centralized Identité biometric repository for matching.
The user's biometric data stays on the user's device.
This is particularly relevant as organizations become increasingly concerned about centralized repositories of highly sensitive identity information.
Passwords can be changed after compromise.
Your fingerprint cannot.
Architecture matters.
PasswordFree® for SaaS Authentication
Identité's PasswordFree® is our SaaS passwordless authentication solution.
PasswordFree® is designed around capabilities including:
Passwordless authentication
Patented Full Duplex Authentication®
Mutual authentication
Trusted-device authentication
Decentralized biometric verification
Contextual authentication
Authentication intent
Emergency PIN Authentication
Secure Backup & Restore
Compatible third-party authentication options
For organizations building or deploying cloud and SaaS applications—including AI-enabled applications—the objective is straightforward:
Reduce password dependence while increasing confidence in the authentication relationship.
NoPass™ for Enterprise AI Environments
For enterprises requiring deeper integration and greater infrastructure control, Identité offers NoPass™, our PaaS solution powered by patented Full Duplex Authentication®.
NoPass™ can be deployed in the cloud or on premises and can support enterprise environments involving:
Microsoft Active Directory
Microsoft Entra ID
Microsoft 365 / Office 365
Microsoft Azure
This deployment flexibility can be especially important for:
Financial institutions
Healthcare organizations
Government
Critical infrastructure
Highly regulated enterprises
Organizations that are reluctant to place sensitive authentication infrastructure or information in the cloud can maintain greater control through an on-premises NoPass™ deployment.
AI Security Needs Zero Trust—and Zero Assumptions
One of the strongest lessons from the Wiz document is that AI security cannot depend on a single control.
Organizations need:
Visibility.
Data protection.
Access control.
Guardrails.
Attack-path analysis.
Monitoring.
Incident response.
And I would add one more:
Strong identity authentication.
The security principle should be simple:
Never assume identity simply because credentials were presented.
Establish it.
And don't assume the destination is legitimate simply because it looks legitimate.
Authenticate that too.
Seven AI Security Questions Every Organization Should Ask
As organizations implement GenAI, leadership and security teams should be able to answer these questions:
Do we know every AI system being used within our organization?
Do we know what sensitive information those systems can access?
Do we know who has access to our models, data, APIs, and training pipelines?
Are those permissions based on least privilege?
Can we detect abnormal behavior and potential attack paths?
Do we have an AI-specific incident-response strategy?
Are we certain the person accessing our AI resources—and the destination receiving the authentication—are both legitimate?
That seventh question connects AI security with identity security.
And it will become increasingly important as AI systems become more powerful.
The Identité Perspective
Artificial intelligence may change almost everything about how enterprises use technology.
It doesn't change the fundamental requirement for trust.
AI models need protection.
Training data needs protection.
APIs need protection.
Administrative consoles need protection.
Cloud environments need protection.
And the identities authorized to access all of them need protection.
The Wiz guide concludes that organizations need a proactive and agile approach to GenAI security capable of keeping pace with the speed at which AI is being developed and adopted.
We agree.
But as organizations build that strategy, identity cannot become an afterthought.
With Identité:
The biometric can help establish:
"I am the authorized user."
The trusted device participates in establishing:
"This is the authorized device."
Contextual authentication can ask:
"Did I initiate this authentication session?"
The image and three-digit number provide additional authentication context.
And patented Full Duplex Authentication® addresses:
"Is this the legitimate destination?"
The result is a broader trust relationship built around:
Identity + Device + Intent + Context + Destination
AI is rapidly changing what technology can do.
Security has to evolve with it.
Because the more powerful our systems become, the more important one question becomes:
Who are we trusting… and how do we know?