Introduction: From Shadow IT to Shadow AI

For years, businesses have struggled with Shadow IT — software, applications, and services employees use without the IT department’s approval or oversight.

Today, a new challenge is emerging: Shadow AI.

Employees are increasingly using personal AI assistants and AI agents to write code, summarize documents, manage workflows, search for information, and automate everyday tasks. Many of these tools can connect directly to corporate applications, access business data, and perform actions on behalf of their users.

The problem is not simply that employees are using AI tools without permission. The more serious issue is that these AI agents may already have access to enterprise systems through credentials and sessions that security teams cannot see or adequately control.

This situation is closely related to the concept of Bring Your Own AI (BYOAI), in which employees bring their own AI tools into the workplace, often outside formal IT and security policies.

The result is a new identity security challenge: organizations must manage not only human users and traditional applications, but also AI agents operating with the permissions and privileges of those users.

1. How AI Agents Gain Access to Enterprise Systems

AI agents differ from conventional chatbots because they can do more than generate responses. Depending on their capabilities and configuration, they can interact with external services, call APIs, use browser sessions, and execute multi-step tasks.

To perform these activities, an agent may need access to corporate resources. That access can be obtained through several mechanisms.

OAuth tokens

Many enterprise applications use OAuth to authorize access to services such as cloud storage, email, collaboration platforms, and developer tools.

When an employee grants an AI application permission to access an account, the application may receive an access token or refresh token that allows it to act within the scope of the granted permissions.

If the token provides access to sensitive resources, the AI agent may be able to retrieve or manipulate corporate data without requiring the employee to authenticate again for every action.

API keys and personal access tokens

Developers frequently use API keys and personal access tokens (PATs) to connect tools and automate workflows.

An employee might configure a personal AI agent with a token that grants access to a source-code repository, an issue-tracking platform, or an internal API.

If that token has excessive privileges, is stored insecurely, or is never rotated, the agent can become an additional path to sensitive systems.

Browser sessions and saved credentials

Some AI agents operate through a browser or interact with an existing browser session.

In certain configurations, an agent may be able to access resources using the employee’s authenticated session. This creates a security concern because the organization may see a legitimate user session rather than a distinct, identifiable AI agent.

Local agents and third-party infrastructure

AI agents can run locally on an employee’s computer or rely on infrastructure operated by an external provider.

Depending on the implementation, credentials, conversation history, business data, and tool permissions may be distributed across multiple environments.

This makes it more difficult for security teams to determine where sensitive information is processed, which components can access it, and how access can be revoked.

The key takeaway is that an AI agent does not necessarily need a new corporate account to become a security risk. It may inherit access from credentials that already exist.

2. Identity Is the Core Security Problem

Traditional enterprise security models generally distinguish between human users, applications, service accounts, and automated workloads.

AI agents blur these boundaries.

An agent may perform actions on behalf of an employee, use credentials issued to that employee, and access resources through an application registered by a third party. From the perspective of an enterprise system, its activity may look like normal user behavior.

This raises several important questions:

• Which AI agents are accessing corporate systems?

• Who authorized them to access those systems?

• What permissions do they have?

• Which data can they read, modify, or transfer?

• Can the organization distinguish an agent’s actions from those performed directly by a human?

• What happens when an employee changes roles or leaves the company?

Without clear answers, organizations may have limited visibility into how their identities and credentials are being used.

The challenge is no longer just managing who can log in. It is understanding which entities are acting, on whose behalf they operate, and what they are authorized to do.

3. Zero Trust Must Extend to AI Agents

Zero Trust is based on the principle that access should not be granted simply because a user or device is inside a trusted network.

Every access request should be evaluated according to identity, authorization, context, and applicable security policies.

The same principle should apply to AI agents.

Organizations should not automatically trust an agent because it operates on an employee’s computer or uses an approved enterprise account.

A practical Zero Trust approach for AI agents includes the following controls:

• Explicit authorization: Require approval before an agent connects to sensitive enterprise applications.

• Strong identity verification: Identify the user, application, agent, or workload associated with each access request whenever the platform supports it.

• Context-aware access: Consider the resource, requested action, device, environment, and risk level.

• Continuous monitoring: Review agent activity and detect unusual access patterns.

• Revocable access: Ensure that permissions and credentials can be withdrawn when an agent is no longer authorized.

Where possible, AI agents should have dedicated identities or clearly identifiable application identities rather than relying on shared or indistinguishable human credentials.

This improves accountability and makes it easier to investigate suspicious activity.

4. Apply the Principle of Least Privilege

One of the most effective ways to reduce the risk of AI agents is to limit their permissions.

The principle of least privilege requires every user, application, and automated process to receive only the access necessary to perform its intended function.

For example, an AI agent designed to summarize documents should not automatically receive permission to delete files, modify access policies, or export an entire document repository.

Similarly, an agent that helps developers review code should not necessarily have permission to modify production systems or manage repository administrators.

Organizations should consider the following practices:

• Grant read-only access whenever write access is unnecessary.

• Restrict permissions to specific repositories, folders, projects, or resources.

• Separate development, testing, and production environments.

• Avoid sharing broad administrative tokens with personal AI tools.

• Use short-lived credentials where supported.

• Require additional approval for high-impact actions, such as deleting data or changing access controls.

• Review permissions periodically and remove those that are no longer required.

Least privilege is particularly important because AI agents may execute multi-step workflows. An overly permissive credential can turn a small mistake, compromised integration, or unintended action into a much larger incident.

5. Discover and Monitor Shadow AI

Organizations cannot effectively govern AI tools they do not know exist.

However, identifying Shadow AI is not as simple as searching for unfamiliar applications. Agents may operate through approved services, browser sessions, local software, API integrations, or third-party infrastructure.

A comprehensive discovery strategy should combine several sources of visibility.

Identity and access management

Review OAuth application grants, third-party integrations, service accounts, and other authorization records.

Identify applications with access to sensitive resources, especially those requesting broad permissions or operating without a clear business owner.

Endpoint monitoring

Where legally and operationally appropriate, use endpoint management and security tools to identify unauthorized agent software, suspicious credential access, and unexpected local processes.

API and audit logs

Analyze enterprise application logs for unusual patterns, such as unexpected data exports, abnormal API activity, or access to resources that an employee or application rarely uses.

AI governance and inventory

Maintain an inventory of approved AI tools and agents, including their owners, purposes, data access, permissions, and deployment locations.

Provide employees with a clear process for requesting approval for new tools. A practical approval process can reduce the incentive to bypass security controls.

The objective is not necessarily to prohibit every personal AI tool. It is to establish sufficient visibility and governance to make informed decisions about risk.

6. Employee Offboarding Must Include AI Agent Access

Employee offboarding is a familiar security process, but AI agents introduce additional complications.

Disabling an employee’s corporate account may not immediately invalidate every credential or authorization previously granted to an external application.

Depending on the integration, access may persist through OAuth refresh tokens, API keys, personal access tokens, local configuration files, or other credentials.

Organizations should therefore extend their offboarding procedures to cover AI-related access.

A comprehensive process should include:

1. Disable or appropriately restrict the employee’s corporate identity.

2. Revoke OAuth grants and application sessions where applicable.

3. Revoke or rotate API keys and personal access tokens associated with the employee.

4. Review service accounts, integrations, and automated workflows the employee created.

5. Transfer ownership of business-critical agents and workflows to an authorized employee.

6. Verify that no unnecessary access remains active.

7. Retain relevant audit records according to the organization’s security and compliance requirements.

The same review should apply when an employee changes roles, a contractor’s engagement ends, or an AI tool is retired.

Offboarding should remove the access that the person and their associated tools no longer need — not merely disable the person’s primary account.

7. Identity Controls Alone Are Not Enough

Identity security is essential, but it cannot address every risk associated with AI agents.

Even an authorized agent with appropriately scoped permissions may expose sensitive information through its processing, outputs, integrations, or handling of untrusted input.

Organizations should therefore combine identity controls with broader AI security measures.

These may include:

• Data loss prevention (DLP): Detect or restrict the transfer of sensitive information to unauthorized destinations.

• Data classification: Identify information that requires additional protection before it can be processed by an AI tool.

• Network and egress controls: Limit unauthorized communication with external services.

• Audit logging: Record agent actions and relevant authorization events.

• Human approval: Require confirmation before high-impact or irreversible actions.

• Secure development practices: Protect agent configuration, tool integrations, secrets, and execution environments.

• Incident response: Establish procedures for investigating compromised agents, revoking credentials, and assessing potential data exposure.

Organizations should also evaluate how each AI provider processes data, retains information, handles credentials, and isolates customer environments.

These controls should be proportionate to the sensitivity of the data and the potential impact of the agent’s actions.

8. Where Should Organizations Start?

A practical BYOAI security program does not need to begin with a complete redesign of enterprise infrastructure.

Organizations can start with a phased approach.

Phase 1: Discover

Identify the AI tools and agents employees are using, along with their integrations, identities, and access to corporate data.

Prioritize tools that can access sensitive information or perform actions on behalf of users.

Phase 2: Assess risk

Evaluate each agent based on its permissions, data access, deployment model, external dependencies, and potential business impact.

Pay particular attention to long-lived credentials, excessive permissions, and integrations that lack clear ownership.

Phase 3: Establish governance

Define which AI tools are approved, what data they may process, and what authorization is required before they connect to enterprise systems.

Publish clear policies and provide an accessible approval process for employees who need new capabilities.

Phase 4: Enforce access controls

Apply least privilege, revoke unnecessary credentials, restrict high-risk actions, and require stronger approval for access to sensitive systems.

Use dedicated identities and short-lived credentials where supported.

Phase 5: Monitor and improve

Review logs, investigate unusual activity, reassess permissions, and update policies as AI capabilities and organizational needs evolve.

Security teams should also test whether their existing incident response and offboarding procedures can reliably revoke an agent’s access.

Conclusion: AI Agents Need an Identity and Security Strategy

Personal AI agents can help employees work faster, reduce repetitive tasks, and automate complex workflows. Banning them outright may not be practical, especially when employees can easily adopt new tools outside formal procurement processes.

However, allowing agents to connect to enterprise systems without appropriate visibility and control creates unnecessary security risks.

The most important lesson is that AI agents must be treated as entities with access rights, operational responsibilities, and security implications — not simply as extensions of an employee’s browser or desktop.

Organizations need to know which agents exist, who owns them, what they can access, how their actions are monitored, and how their credentials can be revoked.

As AI agents become more capable and autonomous, identity security will remain a critical foundation for enterprise AI governance.

The question is no longer whether employees will use AI at work. It is whether organizations can ensure that the AI agents they use operate within clearly defined and enforceable security boundaries.

References

• The Hacker News — Bring Your Own Agent: Your Employees' Assistants Are Already Logged In

• NIST SP 800-207 — Zero Trust Architecture

• NIST AI Risk Management Framework (AI RMF)

• IETF RFC 9700 — Best Current Practice for OAuth 2.0 Security

test code