Hiring a virtual assistant used to involve exactly one straightforward access conversation. Which tools do they actually need, what permissions do those tools require, and when does that access get revoked if the working relationship ends.

Photo by cottonbro studio: https://www.pexels.com/photo/a-woman-with-number-code-on-her-face-while-looking-afar-5473956/ 

That conversation still matters just as much as it always did. But most remote teams now have a second category of worker entirely, one that nobody actually onboarded or interviewed, and the old access rules don’t fit it at all.

The Access Rules You Already Know

Start with the human side, since this is the part most business owners already handle reasonably well in practice.

When you bring on a VA, the access checklist is fairly intuitive to put together. Email, calendar, maybe a CRM login, a password manager entry, a few project management tools. You grant what the role genuinely requires, you document it somewhere, and you revoke it when the contract eventually ends. Simple enough in principle, even if it slips sometimes.

The problem is that even this well-understood side is usually handled considerably worse than people assume it is. 

Palo Alto Networks’ 2026 Identity Security Landscape report, based on responses from more than 2,900 cybersecurity decision-makers worldwide, found that 96% of organizations report human identities operating with access far beyond what their actual roles require. Nine out of ten organizations faced a successful identity-related breach in the previous twelve months alone.

That’s the baseline problem sitting there before AI enters the picture at all. Most teams already over-grant access to the humans they hired deliberately, with a signed contract and a proper onboarding call.

Why Agentic AI Access Needs Its Own Rulebook

Here’s the second category, and it’s growing considerably faster than most remote teams actually realize is happening.

AI agents now routinely handle scheduling, inbox triage, CRM updates, and customer follow-up, often connected through OAuth grants that an individual team member approved without much thought at all. The scale of this shift is genuinely striking once you look at it. According to the Cloud Security Alliance’s research, non-human identities now outnumber human users by an average of 45 to 1 across enterprises, and in cloud-native environments that ratio can climb as high as 144 to 1.

This is precisely the governance problem Ory’s agentic AI work addresses directly, and it’s exactly why agentic AI identity security has emerged as a distinct discipline rather than just a subset of regular access management. 

An AI agent isn’t a tool sitting passively somewhere in your stack waiting to be used. It authenticates, makes real decisions, and writes into business systems autonomously without a person watching each action, which means it genuinely needs its own identity, its own scoped permissions, and its own revocation process, exactly like the VA you actually took the time to interview.

The Gap Between These Two Rulebooks

Most remote teams apply genuinely rigorous rules to the first category and almost nothing at all to the second one.

The consequences of that gap show up clearly in the data. Research covered by The Hacker News describes non-human identities, including AI agents, API keys, and OAuth tokens, as the fastest-growing and least-governed attack surface in the modern enterprise. These identities routinely carry elevated privileges while receiving only a fraction of the oversight that gets applied to ordinary human accounts doing similar work.

The visibility problem is the sharpest part of the whole thing. Reporting on Cloud Security Alliance survey data found that 53% of CISOs said they could confidently enumerate fewer than half of the machine identities running in their own environments. If security leaders operating at that level genuinely can’t inventory what’s connected to their systems, a small business running a handful of VAs and a few AI tools almost certainly can’t either without deliberately trying.

What This Means Practically for Remote Teams

None of this requires an enterprise security budget or a dedicated IT hire. It requires applying the same discipline you already use for human hires to the AI tools already running quietly alongside them.

Treat every single AI agent connection as a genuine onboarding event, not just a routine settings change nobody needs to know about. Write down what it can access, who approved it, and what business purpose actually justifies that access, exactly the same way you’d document a new VA’s tool permissions on their first day of work.

Require approval before anyone connects a new AI tool to shared accounts. The OAuth screen most people click straight through without reading is functionally a hiring decision, granting ongoing access to calendars, inboxes, and customer records without any interview or reference check attached to it.

Build in periodic reviews covering both categories together, rather than treating them as separate problems. A quarterly pass through active human access and active AI connections catches the orphaned permissions that accumulate quietly on both sides, from VAs who moved on months ago and from AI trials nobody ever formally cancelled after the free period ended.

The Real Shift Here

The genuine change here isn’t that AI agents are somehow inherently risky while human VAs aren’t, because that framing misses the actual point entirely. It’s that remote teams now run on two completely distinct categories of worker, and only one of them ever gets a proper onboarding conversation with real thought behind it.

Your VA signed an agreement, went through a proper introduction, and has a named person responsible for managing their access over time. The AI agent connected to that exact same calendar usually has none of those things in place at all, despite touching much of the same sensitive client and business data every single working day. 

Closing that gap doesn’t mean adopting either less AI or hiring fewer VAs, and nobody should read it that way. It means recognizing that both categories genuinely need a rulebook of their own, and only ever bothering to write one of them was always going to leave something quietly exposed somewhere.