How to Review a Personal AI Agent Before Employees Connect It

Employees are connecting personal AI agents to work accounts faster than security teams can write policy for them. A sales lead links an agent to their email and the company CRM. An engineer adds an agent to a team chat workspace. A manager lets an assistant draft replies and manage their calendar. Each decision is reasonable on its own, and each one extends a person's access into software that acts on its own judgment.

Effective personal AI agent security doesn't mean saying no to all of it. It means having a repeatable way to assess an agent before the connection is made, so what employees gain in productivity doesn't come with access the organization never evaluated. This article offers a six-part review that security teams, IT, and risk owners can apply to any personal or shared workplace agent, whether it arrives through a request form or through an OAuth prompt an employee clicked at 4 p.m. on a Friday.

Why Personal Agents Need Their Own Review

Most existing review processes were written for applications that people use. A personal agent is different in three ways that matter for security.

It acts, not just displays. A traditional app reads data when the user opens it. An agent can read, summarize, send, schedule, and delete on its own initiative, based on instructions it interprets.

It runs under the employee's identity. Downstream systems see the employee, not an agent. Logs, DLP tools, and access policies built around human behavior can't tell the difference.

It persists. Agents hold tokens, keep memory, and often run on schedules or triggers. Access granted for one task continues until someone removes it.

These properties are the reason Zenity treats coding and personal agents as a distinct category. They also explain why Shadow AI is so common here: the agent arrives as a user decision, not a procurement event, so it often never enters an inventory.

Personal Versus Shared Deployments

Before applying the checklist, identify which of two deployment models you're reviewing, because the risks differ.

In a personal deployment, one employee connects an agent to their own accounts. The exposure is through that employee's data and permissions. If the agent is manipulated or misconfigured, the blast radius is whatever that employee can reach.

In a shared deployment, the agent is added to a channel, project space, or team workspace. It can now see messages and files from everyone in that space, and often responds to anyone who addresses it. The exposure is the group's data, and the agent may take instructions from people with differing levels of authority.

Many deployments are both: a personal agent that the owner later invites into a team channel. Review for the more exposed model.

The Six-Part Review

Apply these questions in order. Each one should produce a written answer, even if the answer is short.

1. Which OAuth grants does the agent request?

Look at the exact scopes, not the app's description. An agent that "helps with email" may request permission to read, send, and delete all mail, and to access contacts and attachments. Compare each requested scope against the task the employee wants done.

Ask whether a narrower, read-only scope would work, whether the grant applies to a single mailbox or the whole organization, and whether the agent can request additional scopes later without a new prompt. Over-broad grants are the most common finding in agent reviews, and the easiest to fix before connection.

2. What can it see in shared channels?

If the agent will join any shared space, list which channels it can read, whether it can read history or only new messages, and who can send it instructions. Check whether private channels, direct messages, or files shared in the space are in scope.

Then, ask a governance question: have the other members in the shared channel been told? Employees may reasonably object to an agent summarizing conversations they thought only colleagues could see. Where the answer is no, limit the agent to specific channels and make its presence visible.

3. Does it keep sessions and memory?

Find out what the agent stores between uses. Common examples include long-lived refresh tokens, saved credentials, conversation memory, cached files, and scheduled or triggered tasks. Each is a path that lets access outlive the original request.

Ask how long sessions last, whether tokens expire, whether the agent can act when the employee isn't present, and whether memory can include sensitive data from one context that later surfaces in another. A persistent agent with broad access and no expiry is a standing privilege, and should be treated like one.

4. Who owns it?

Every agent should have a named human owner who answers for what it does. Confirm who that is, whether the owner is aware of the agent's actions, and what happens when they change roles or leave the company.

Ownership matters most at the edges. An agent connected by an employee who has since departed may still hold valid tokens. An agent shared by a team may have five users and no owner. Without an owner, no one reviews access, responds to Issues, or decides when to retire it.

5. Where does the data go, and how long does it stay?

Trace the data flow. Which provider processes prompts and content? Is that content used for model training? Where is it stored, and in which region? How long is it retained, and can it be deleted on request?

For regulated data, check the answers against contractual and legal obligations. Where the provider's terms or retention periods don't meet them, the agent should be restricted from touching that data, regardless of how useful it is.

6. How is access revoked?

Test the exit before approving the entry. Determine how to remove the agent's access centrally, whether revoking an OAuth grant also invalidates active sessions and scheduled tasks, and how quickly the change takes effect.

A useful standard: if an agent behaved unexpectedly at 2 a.m., could the security team cut off its access without waiting for the employee? If the only way to revoke is for the owner to do it from their own settings, the review has found a gap.

What a Review Looks Like in Practice

Consider a product manager who wants to connect a personal agent to email, calendar, and a team chat channel so it can summarize threads and draft updates.

The review finds that the agent requests full read, send, and delete access to mail, which the use case doesn't require. It would also be added to a channel with 40 members, including contractors. Its sessions don't expire. The provider retains content for 30 days. There is no central revoke option.

The outcome isn't "no." The reviewer approves a version with read-only mail scope, a single approved channel, a session lifetime limit, and a documented owner, and records that central revocation is available only through the identity provider's token controls. The employee gets most of the benefit. The organization knows what it agreed to.

Turning the Review Into a Decision

A review that ends in a pile of notes won't change behavior. Close each one with one of three outcomes:

• Approve: The scope matches the task, and the controls are adequate.
• Approve with limits: Reduce scopes, restrict channels, set session lifetimes, or require manual approval for sensitive actions.
• Decline: The access can't be bounded, or the data handling conflicts with obligations.

Record the decision, the owner, and a review date. Agents change as vendors add features, so a one-time approval becomes stale quickly. Rechecking at a fixed interval, and whenever scopes change, keeps the record honest.

Reviews Don't Work Without Discovery

Reviews only help for agents you know about. Employees connect personal agents through consumer apps, browser extensions, OAuth prompts, and local tools, and many never reach a request form. Those apps fall under the category of shadow AI or shadow IT. Security teams need ways to find them: OAuth application inventories from identity providers, workspace app lists, endpoint visibility, and network signals.

Discovery is also what turns a review from a gate into a program. Once agents are visible, teams can prioritize risky ones and monitor approved ones for drift from the original agreement. Zenity's AI security posture management discovers agents across SaaS, cloud, and endpoint environments, assesses their configuration, and surfaces issues where access exceeds what was approved. Runtime controls then watch what agents do after approval, from build time to runtime.

Want to see which personal and shared agents are already connected to your environment? Talk with the Zenity team to discover them and put approval, limits, and revocation in place.

Personal Agent Review Checklist

Use these questions to confirm a review is complete before an employee connects an agent.

• Have we compared every requested OAuth scope against the specific task?
• Can a narrower, read-only grant achieve the same result?
• Do we know which shared channels, history, and files the agent can access?
• Have other members of any shared space been informed?
• Do we know how long tokens, sessions, and memory persist?
• Does the agent have a named owner, and is there a plan for role changes?
• Do we know where content is processed, stored, and retained?
• Can the security team revoke access centrally, and does it end active sessions?
• Is the decision recorded with an owner and a review date?

An agent that can't clear these questions isn't ready to be connected, however useful it looks. Done well, the review takes minutes rather than weeks, and it gives employees a clear path to yes.

FAQs About Personal AI Agent Security

What is a personal AI agent?

It's an AI agent an individual employee connects to their own accounts or tools to act on their behalf, such as reading mail, scheduling meetings, or running tasks. It may be personal in setup but still touches company data.

Is a personal agent the same as Shadow AI?

Not always. It becomes Shadow AI when the organization hasn't discovered or approved it. A reviewed and recorded personal agent is governed use.

Why are OAuth grants so important?

They define what the agent can do without further approval. Broad scopes turn a small task into wide access.

What changes when an agent joins a shared channel?

It can see content from everyone in the space and may respond to anyone who addresses it, so the exposure and the instruction sources expand beyond the owner.

How often should approvals be revisited?

At a set interval and whenever the agent's scopes, features, or provider terms change.

Should we block personal agents entirely?

Blanket blocks tend to push usage out of sight. A review process with clear outcomes keeps adoption visible and bounded.