When Your Employee's AI Becomes Your Liability: The Bring Your Own Agent Problem

TBDCyber | Agentic AI Security Series

This is our sixth article in our Agentic AI Security series. Our first two articles have discussed the problem framework (see The 45 Billion Identity Problem Nobody Is Talking About and The Identity Paradox: Why Agentic AI Breaks IAM by Design). Articles 3-4 mapped internal and external agent risk (Shadow AI Is Already Here, And Your Security Team Doesn't Know It and The Vendor in Your Environment You Didn't Hire: Third-Party Embedded AI Risk). In our fifth article (Who Governs the Agents You Didn't Build? The Platform Vendor Conflict of Interest), we discussed the platform vendor governance accountability gaps. In this article, we examine the governance challenges around “bring your own agent”.

***

"Bring Your Own Device" took roughly a decade to move from fringe practice to mainstream enterprise policy challenge. Organizations had time to watch it develop, assess the risks, build MDM programs, negotiate conditional access frameworks, and write policies that balanced employee productivity against corporate data protection.

"Bring Your Own Agent" won't give you a decade to develop a response.

Employees are already using personal AI assistants (e.g., Claude, ChatGPT, Gemini, Perplexity) to perform work tasks. Drafting communications. Summarizing documents. Analyzing data retrieved from corporate systems. Researching decisions. In many organizations, this is happening now, at scale, and is entirely invisible to the security team.

The governance challenge it creates is distinct from BYOD in one critical respect that most security programs have not yet fully internalized. A personal device can be managed. It has a hardware footprint, a network connection, and an identity on the corporate directory or MDM platform. Control exists. An employee's personal AI agent has none of these. It has no device footprint that existing controls can address. Its interactions with corporate data may occur entirely within the employee's own authenticated sessions, through approved applications, in ways that are technically indistinguishable from the employee's own actions. From the perspective of the corporate audit trail, it is invisible.

What Is Actually Happening Right Now

The scenarios that make BYOA a governance problem are conditions that exist in most large organizations today, ungoverned, because no one has yet asked the right questions about them.

A senior executive has connected their personal AI assistant to their corporate calendar, email, and document store via standard OAuth integrations that consumer AI platforms actively encourage and enterprise platforms passively permit. The assistant has been granted access to years of correspondence, including board-level discussions, M&A deliberations, and personnel decisions. The organization has no record of this access, no governance over how the assistant processes that data, and no mechanism to revoke it independently of revoking the executive's own credentials.

A sales representative connects a personal AI tool to their CRM instance to help with pipeline management and customer outreach. The tool ingests customer contact records, deal information, and communication history. When the representative leaves the organization, their CRM access is revoked, but the personal AI tool retains cached data, stored embeddings, or persistent session tokens. The data the agent processed does not leave with the credential. It persists in the agent's environment, outside the organization's data governance perimeter, and there is no technical mechanism to remediate it.

A contractor working on a sensitive engagement uses their personal AI assistant to process project documents they access through shared collaboration tools. The contractor's access is time-limited and formally terminated at the end of the engagement. The agent's access to everything it processed is not.

A finance analyst retrieves a data set from the corporate ERP, pastes it into a personal ChatGPT session to perform analysis, then acts on the output within corporate systems. Every corporate control worked exactly as designed: the analyst authenticated, accessed data within their authorized scope, and completed a business task. But a third-party AI system processed sensitive financial data without organizational governance, a contractual basis, or an audit record of its involvement in the decision.

The Invisible Identity Problem

What makes BYOA structurally different from almost every other identity governance challenge is that the agent does not present as an agent. It presents as the human.

When a personal AI assistant takes actions within corporate systems, whether directly through OAuth integrations or indirectly through an employee who acts on its output, those actions are recorded under the employee's identity. There is no separate agent identifier. There is no flag in the audit trail indicating that a non-human entity was involved in the decision or the action. The log shows an authenticated human user performing authorized actions within their permitted scope. Everything looks normal.

This is the Bring Your Own Agent problem in its most precise form: an entity operating within the organization's environment under an employee's credentials, performing consequential work, generating no independent identity record, and carrying no organizational accountability. The most sophisticated identity governance program in the world will not detect it, because there is nothing for it to detect. The agent never authenticated. The agent never requested access. The agent never appeared in any system the organization controls.

The BYOA problem is not a gap in existing governance tools. It is a category for which no current technical control exists. Security leaders should understand this clearly: the reason their organization has not addressed BYOA is not a resource or priority failure. It is that no vendor currently provides comprehensive governance of personal AI agents used by employees for work purposes. The market has not yet built the solution. The problem, however, is here now.

The Regulatory Exposure Most Compliance Teams Haven't Mapped

The invisible identity problem becomes a regulatory liability when it intersects with data protection obligations, and that intersection is happening in most organizations today.

Data protection regulations (e.g., GDPR, CCPA, HIPAA, and sector-specific frameworks in financial services and healthcare) impose obligations on organizations acting as data controllers. Those obligations apply to processing performed by agents acting on the organization's behalf, regardless of whether those agents are formally registered as part of the organization's IT estate.

When an employee uses their personal AI tool to process customer personal data while performing work for the organization, there is a credible legal argument that the organization is the data controller for that processing. The fact that it was performed through an employee's personal, informal use of a consumer tool does not eliminate that liability. It makes it harder to demonstrate that appropriate measures were in place.

Consider what "appropriate technical and organizational measures" means in this context. For BYOA, it would require, at minimum, a policy prohibiting the processing of regulated data through unmanaged personal AI tools, active communication of that policy, technical controls, where feasible, to prevent the highest-risk data exposure paths, and evidence that the organization took reasonable steps to enforce it. In most organizations today, none of these exist. The policy has not been written. The communication has not happened. The technical controls are not in place. There is no evidence of reasonable care.

The regulator's question, whether appropriate controls were in place to protect the data, will not be answered by the personal and informal nature of the processing. It will be answered by whether the organization has a program. Most do not.

Regulated industries carry additional dimensions of this exposure. Financial services firms subject to SEC, FINRA, or insurance-sector recordkeeping requirements face specific obligations around the retention and completeness of business communications and decision records. If consequential decisions (such as investment recommendations, underwriting assessments, risk evaluations) involved material AI assistance through personal tools that left no audit trail, the completeness of those records may be in question.

The Offboarding Gap You Haven't Closed

Even organizations that have begun thinking about BYOA governance tend to underestimate one specific exposure: the gap between revoking an employee's credentials and addressing the agents they operated during their tenure.

Standard offboarding processes are built around the premise that revoking access terminates the exposure. Disable the Active Directory account. Revoke the VPN credentials. Remove the application access. The data in corporate systems is now beyond the departing employees’ reach.

This model does not address BYOA, and the exposure runs in both directions.

The departing employee's personal AI tool may retain data from its corporate interactions long after their credentials are revoked. Cached documents, stored embeddings, indexed email content, persistent OAuth tokens. Consumer AI platforms are not designed with enterprise offboarding workflows in mind, and the data they have ingested during employment does not disappear when the employment relationship ends. If that data includes personal information, intellectual property, or regulated data, the organization has a post-employment data governance problem and no mechanism to remediate it.

In the other direction: agents the employee built or configured during their tenure may continue operating under their credentials, or under credentials derived from their access, after departure. We examined this pattern in the context of citizen developer agents in a previous article. BYOA extends it to the personal context, where the agent was never inside the organization's governance perimeter at all, and where the offboarding process has no checklist item to address it.

What Security Leaders Can Do Now

Comprehensive BYOA governance is not achievable today with the tooling currently available. The standards, protocols, and identity frameworks needed to manage personal agents operating across organizational boundaries are in early development. Clean technical solutions are not coming in the next twelve months.

That does not mean the appropriate response is to wait. It means the response is to manage the risk that can be managed now while the market catches up.

Write the policy and communicate it. An explicit policy on use of personal AI tools for work involving corporate data (e.g., what is permitted, what is prohibited, what data classifications are off-limits regardless of tool) is the foundation of any compliance defense. In practice, it is also the only current control available for the personal agent that operates entirely within an employee's own sessions. A policy that has been written, communicated, and acknowledged creates a compliance baseline. The absence of one creates a defense gap.

Assess OAuth integration exposure. The highest-risk BYOA scenarios (e.g., the executive with board-level correspondence access, the departing employee with persistent CRM tokens) share a common technical footprint: OAuth integrations that consumer AI platforms encourage and that enterprise platforms permit. Tools like Obsidian Security and Astrix Security provide discovery of OAuth integrations granted to third-party applications, including personal AI tools. Identifying which personal AI platforms have been granted access to corporate systems and building a revocation workflow into the offboarding process immediately address the most auditable exposure.

Update offboarding to explicitly address personal AI tool integrations. This is a procedural change that requires no new tooling. Add a checklist item to offboarding processes that require identification and revocation of OAuth integrations granted to personal AI tools. Assign ownership of that step. It will not address the data already ingested by those tools, but it closes the access window going forward.

Escalate the regulatory exposure to compliance and legal leadership. Most compliance functions have not yet assessed the data controller liability implications of employee BYOA use. They should. The assessment does not require a technical solution to be useful. Understanding the scope of exposure, identifying which regulatory frameworks apply, and documenting the gap as a known open risk constitute a defensible compliance posture.

***

BYOA is the identity governance problem that most closely mirrors what organizations face with agentic AI more broadly: an entity operating in the environment without an independent identity, independent accountability, or a technical control category built to govern it. The difference is proximity. This one is already inside, operating under credentials your employees hold today.

The organizations that navigate this well will be the ones that recognize it as a governance problem requiring active management rather than a future technology problem awaiting a vendor solution. The policy, the OAuth inventory, and the offboarding process update do not require a new platform. They require recognizing the problem is here and deciding to own it.

This is the sixth article in TBDCyber's Agentic AI Security series. For a deeper look at how BYOA fits into the wider identity governance crisis, see our full research report.

The next article examines what happens when an agentic AI incident occurs and why the audit trail you think you have may not be the one a regulator or court will find adequate.

TBDCyber advises security leaders on identity governance, agentic AI security, and emerging threat architectures. To discuss what this means for your organization, contact us.