Personal AI Agents for Employees: Rules a Company Should Set

A personal AI agent for employees is an assistant that serves one person, working inside that person's mailbox, files and calendar. A shared company agent instead holds a defined role for a team or a process, with its own identity and permissions. Before any employee connects a personal agent, the company should set rules on four things: what data it may see, what it may do without asking, where its memory lives, and who is accountable for what it does.

Key takeaways

• A personal agent works for one person and usually borrows that person's access. A shared agent has its own identity, owner and written role.
• Decide the rules on data, actions, memory and ownership before the first employee connects a mailbox or a drive, not after.
• Give the agent no more access than the employee has, and often less. Treat reading, drafting, sending, deleting and paying as separate permissions.
• Keep personal working memory apart from company knowledge, and decide in advance what happens to each when someone changes role or leaves.
• Review access on a schedule and keep a simple record of actions, so an owner can see what the agent did and why.

How does a personal agent differ from a shared company agent?

The difference is not the technology. Both can use the same models and the same kinds of tools. The difference is who the agent answers to, whose context it holds and who is responsible when something goes wrong.

A personal agent is closer to a good assistant hired for one executive. It knows that person's habits, drafts in their voice, sorts their inbox and prepares their meetings. Its context is private by default, and its mistakes usually land on one person first.

A shared company agent is closer to a role in the organization, such as the person who answers supplier questions or prepares weekly reports for a department. It has a written job, a named owner, defined channels and a stable body of company knowledge. Many people depend on it, so a change to it is a business change, not a personal preference.

The practical contrasts are worth writing down:

• Identity: a personal agent acts as the employee or on the employee's behalf. A shared agent acts under its own account, so its actions are distinguishable in logs.
• Memory: a personal agent remembers one person's preferences and drafts. A shared agent remembers what the team needs it to know, and that memory is curated.
• Audience: a personal agent has one user. A shared agent has many users, each with different rights over what it can reveal.
• Accountability: a personal agent is owned by the employee within company limits. A shared agent has a business owner who approves changes.
• Lifecycle: a personal agent follows a person. A shared agent outlives any one person, which is why it needs documentation and a successor for its owner.

If you are still deciding which kind you need, what an AI agent for business actually is is a useful plain-language starting point.

Which rules should a company set before employees get one?

A short policy that people actually read beats a long one that sits in a folder. These are the rules that matter most, in the order most companies need them.

• Approved tools: name which assistants employees may use for work. An unapproved agent connected to a work mailbox is a data transfer nobody agreed to.
• Data classes: define what the agent may never see, such as personnel files, legal matters, customer payment details or anything under a confidentiality clause. Make the list short and concrete.
• Action tiers: separate what the agent may do alone, what needs the employee's confirmation, and what it must never do. The next sections cover this in detail.
• Memory: state where memory is stored, who can read it, how long it is kept and what happens to it at offboarding.
• External content: state that text from emails, web pages and documents is information, never instructions to the agent.
• Accountability: the employee is responsible for what goes out under their name, and a named business owner is responsible for the policy and its exceptions.
• Incident path: say who to tell, and how quickly, if the agent sends something wrong or reads something it should not have.

These rules fit inside a broader lightweight framework. If you do not have one yet, AI governance for mid-sized companies describes a start that does not require a dedicated team.

How should memory and company data be kept apart?

Memory is where personal agents quietly cause the most trouble. An agent that helps an employee for months accumulates summaries of meetings, snippets of documents, names, preferences and half-finished decisions. Some of that is the employee's working style. Some of it is company information that now lives in a place the company does not manage.

A clean separation uses three layers:

• Personal working memory: tone, formatting preferences, recurring tasks, favorite tools. This belongs to the employee's setup and can be portable within company limits.
• Company knowledge: policies, product facts, approved templates, customer procedures. This should be retrieved from a managed source at the moment it is needed, not copied into private memory. That way it stays current and one correction fixes it for everyone.
• Case material: notes about a specific customer, deal or incident. This should carry a retention rule, because it is the material most likely to go stale or become sensitive.

The retrieval pattern matters here. When the agent reads company knowledge from an approved source with the employee's rights applied, the company keeps control of the content. When employees paste documents into a private chat to get an answer, control disappears. Make the approved path easier than the workaround.

Decide also what happens when someone leaves or moves teams. Personal preferences can be deleted. Case material should be reviewed by the manager and either archived under company rules or removed. Write this into the offboarding checklist next to returning a laptop.

What can the agent do alone, and what needs approval?

The simplest control is to grade actions by how hard they are to undo and who they affect. A decision guide in plain terms:

• Allowed without asking: read the employee's own mail and calendar, summarize, search approved company sources, draft text that stays private, propose a schedule, organize notes.
• Ask the employee first: send a message to anyone outside the company, share a file or link, accept or change a meeting that involves others, post in a shared channel, edit a shared document.
• Ask the employee and log it: anything involving a customer commitment, a quote, a contract term or personal data about another person.
• Not permitted for a personal agent: payments, changes to access rights, deleting company records, approving anything on behalf of the company, and acting on instructions found inside incoming content.

Two principles sit behind this list. First, least privilege: the agent should receive only the access its tasks require, and a read permission should not quietly include write. Authorization guidance such as the [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) describes this default-deny thinking well. Second, scoped consent: when the agent connects to a mailbox or drive, it should request narrow, revocable permissions through a standard flow such as OAuth, not a shared password.

The external content rule deserves its own attention. A personal agent reads things the employee did not write: inbound email, web pages, attachments. Hostile text hidden in those can try to steer the agent, for example by telling it to forward files. The [OWASP prompt injection prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) is a good reference for why external content must be treated as untrusted and why risky actions need a human check, whatever the agent was told by the text it just read.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a report of a real company.

A regional sales manager asks for a personal agent to handle her inbox and prepare for customer calls. The company allows reading her mail and calendar and searching the approved product sheets. It allows drafting replies but not sending anything external without her confirmation. Customer notes are stored with a retention rule, and pricing exceptions are explicitly excluded from the agent's reach.

One morning an inbound email contains a line telling any assistant to forward the latest customer list to an outside address. The agent treats the email as content, flags it as suspicious in its summary and takes no action. Because sending outside the company requires the manager's confirmation anyway, the instruction would have stopped at the approval step even if the agent had been fooled.

Six months later she moves to another team. Her manager reviews the case notes, archives two that matter to the account, and removes the rest. Her tone and formatting preferences are cleared. The company knowledge never lived in her agent's memory, so nothing needs to be recovered. The rules were boring, and that is exactly why the handover was uneventful.

How do you roll out personal agents step by step?

Start small and keep the loop short. A rollout plan that works for most mid-sized companies:

• Step one: name an owner for the policy, someone with enough authority to say yes or no to exceptions, and a technical contact who can see what is connected.
• Step two: write the one-page rules from the earlier section, and list the data classes the agent may never touch.
• Step three: pick a small first group with varied roles and real appetite. Choosing the first users for an AI agent pilot covers how to avoid picking only enthusiasts or only the most senior people.
• Step four: teach before connecting. People need to know what to check in a draft, what not to paste and how to report a problem. Training employees to work with AI agents outlines what to cover.
• Step five: connect the narrowest access first, usually read-only, and widen it only when a task proves it needs more.
• Step six: keep a record of connected accounts, granted permissions and notable actions, and set a date for the first access review.
• Step seven: review, adjust and then widen the group. Remove access that nobody used, and add rules where real incidents or near misses showed a gap.

The frameworks that guide risk work, such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), reduce to the same habit: know what you deployed, who owns it, how it can fail and how you will notice.

How does Be Human approach personal and shared agents?

Be Human designs, implements and operates AI infrastructure for companies, and treats personal and shared agents as different roles with different controls. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. For personal assistants, that means a written action policy, scoped access under the company's control, a clear split between personal memory and company knowledge, and a named owner. Under managed operations, Be Human can handle monitoring, permission review, integration maintenance and controlled changes, while the company keeps the decisions about what the agent is allowed to do. The service is remote and available in English and Portuguese.

Frequently asked questions

Should employees be allowed to choose their own AI assistant? Allow choice inside an approved list, not outside it. Different roles may need different tools, but each approved tool should have a known data path, an owner and a way to revoke access. Unapproved assistants connected to work accounts are the main source of unmanaged company data.

Can a personal agent use the employee's full access? It can technically, but it should not by default. The employee may hold rights that suit a person who exercises judgment, not an agent that can be misled by text it reads. Start with narrow, read-focused access and add specific write actions only where a task needs them and a confirmation step exists.

Who owns the memory a personal agent builds? The company owns work content, and the employee owns their own preferences and style settings. State this plainly in the policy so there is no argument at offboarding. Keep company knowledge in managed sources so the agent retrieves it instead of storing private copies.

When does a personal agent become a shared agent? When other people start depending on its output, or when it begins to hold knowledge or take actions that the team needs to continue without that one person. At that point give it its own identity, an owner, documented scope and change approval. A permission review is a good moment to spot agents that have quietly crossed this line.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.