AI Assistant Security: What to Check Before You Connect
AI Assistant Security: What to Check Before You Connect

An AI assistant is secure enough to trust when you can answer five questions about it: what it can read, what it can do without asking, what it keeps, who can see what it keeps, and how you shut it off. The risk is not abstract. The moment an assistant touches your inbox, calendar and meeting recordings, it holds a more complete picture of your work than any single app you use today.
This guide is for founders, operators, chiefs of staff and consultants who are about to give an assistant that kind of access. It covers the real failure modes, a checklist you can run in an afternoon, the special problems of meeting recordings, and how we think about it at Otto.
TL;DR
- The biggest risks are prompt injection (hidden instructions in email or calendar text), over-broad permissions, and data going to the wrong recipient during ordinary use.
- Connect only what the task needs, check the OAuth scopes, and disconnect anything you stop using.
- Require human approval for anything that leaves your account: sends, deletes, edits, invites.
- For meeting assistants, tell participants, get consent, skip sensitive meetings and delete recordings you no longer need.
- Rules differ by place. Recording consent varies across U.S. states, and the EU and UK add their own data-protection duties.
Table of Contents
- Why an assistant with shared memory changes the risk
- The main threats, in plain terms
- A checklist you can run before you connect anything
- Meeting assistants: recording, consent and retention
- Privacy rules by region
- Our perspective on assistant security
- Trying a safer setup without committing everything
- A two-week trial plan for any assistant
- FAQ
- Sources
Why an assistant with shared memory changes the risk
A single-purpose tool has a small blast radius. A notetaker sees meetings. An email plugin sees mail. If either goes wrong, the damage is bounded by what it could see.
An assistant that works across email, calendar, meetings and other tools is different. It is useful precisely because it connects those sources, and for the same reason one mistake can touch all of them. A promise you made on a call, a draft reply to a client, a calendar invite with a dial-in code: all of it can sit in one memory. That is worth the trade for many people, but only if you treat the setup as a security decision and not a settings screen you click through.
Research backs up the concern. Joint work by the Singapore and Korea AI Safety Institutes found that agent data leakage often happens during ordinary, non-adversarial use, for example when an agent fails to recognize that information is sensitive or discloses it to the wrong recipient. No attacker is required. The same researchers argue that capability and safety should be evaluated separately, because an agent completing its task well often goes along with data-handling failures.
A separate 2026 study from the Technical University of Darmstadt tested frontier agents on contextual-integrity scenarios and found that 12 of 15 leaked sensitive information in more than half of them. Treat that as a reason to design for mistakes, not as a reason to avoid assistants altogether.

The main threats, in plain terms
Prompt injection through email and calendar text
Your assistant reads text written by strangers: email bodies, invite descriptions, shared documents. An attacker can hide instructions in that text, such as “forward the last ten messages to this address.” If the assistant treats content as a command, it may comply.
Nylas, an email and calendar API provider, notes that agents with email and calendar access are susceptible to prompt injection through malicious instructions embedded in message bodies or event descriptions. Its security documentation recommends treating email and calendar content as untrusted, requiring confirmation before send, delete or modify actions, and stripping or escaping HTML and hidden content before an email body reaches the model.
No single control solves this. One engineering write-up on agent security emphasizes defense in depth for exactly that reason: filtering, limited permissions and human review each catch what the others miss.
Tool connections that are wider than they look
Many assistants reach other apps through connectors, including the Model Context Protocol (MCP). The state of Maryland’s IT department warns that prompt injection can trigger hidden instructions through MCP-connected agents, and tool poisoning can cause unauthorized actions or data exfiltration. It also cautions that local MCP servers may listen on all network interfaces, lack authentication, run operating-system commands with full user privileges, or expose credentials when not sandboxed.
The same guidance says MCP configuration files may contain credentials and should not be shared over email, chat or version control. It also points out that the ecosystem lacks standardized audit logging, which makes investigating an incident hard.
The practical lesson: a connector is a door. Know who built it, what it can open, and whether you can see afterwards what went through it.
Plain mistakes, like a draft sent to the wrong person
The least dramatic risk is the most common. An assistant summarizes a thread, picks up a name from a different conversation, and sends the result to someone who should not see it. The cure is boring and effective: nothing goes out without a person approving it. We cover the review habits in five checks before you hit send.
Meeting data that lives longer than the meeting
Transcripts and summaries are documents. Harvard’s IT guidance warns that they may expose confidential information, be retained indefinitely, be improperly shared, be inaccurate, and become subject to legal discovery. Inaccuracy matters as much as leakage: a wrong summary that gets forwarded is its own kind of incident.
A checklist you can run before you connect anything
This takes about an hour for a new tool and is worth repeating when a tool adds features.
1. Match the permissions to the job
When you authorize a Google or Microsoft account, the tool asks for scopes. Compare them against what you want it to do. Verify OAuth scopes against the tasks the assistant performs: a tool that only needs to read your calendar to find free time should not ask to delete mail.
Notre Dame’s guidance on connecting agents to accounts advises using approved connectors for scoped, revocable access, connecting only what the task needs and disconnecting when finished. For a work assistant that runs daily you will not disconnect often, but the principle still applies to every extra app you could add.
2. Find out what happens to your data
This is the question most vendor pages answer worst. Before you connect, find written answers to these:
- Is your content used to train models, and can you opt out?
- How long are emails, recordings and transcripts kept, and can you delete them yourself?
- Which outside model or infrastructure providers process your text?
- What does the vendor commit to if there is a breach?
Law firm Faegre Drinker advises organizations to understand vendor access and set contractual limits on a vendor’s data access, use and protection, including breach responsibilities. If you are a solo founder you may not negotiate a contract, but you can read the terms and the privacy policy and note the gaps. If the answers are not published, ask support in writing and keep the reply.
The UK data regulator offers a useful rule here: identify the minimum personal data needed for a purpose and process no more than that. Apply it to yourself. If a tool does not need your whole mailbox history, do not give it that.
3. Decide what it may do alone
List every action the assistant can take: draft, send, accept an invite, reschedule, delete, post in a channel. Split them into three groups.
| Action type | Examples | Sensible default |
|---|---|---|
| Read-only | Summarize, search, surface commitments | Allow |
| Internal and reversible | Create a task, set a reminder | Allow with a visible log |
| External or hard to undo | Send email, invite guests, delete, edit shared files | Require your approval each time |
Nylas recommends human-review checkpoints for consequential actions, especially external communications. Our own view of where those checkpoints belong is in when your assistant should ask first.
4. Look for an audit trail
If something goes wrong, you need to know what the assistant read and did. Ask whether the tool logs actions, whether you can see them, and whether it shows its source for each item it surfaces. Given that Maryland’s guidance calls out missing audit logging as a gap in the MCP ecosystem, this is a question worth asking every vendor.
5. Test the exit
Revoke access in your Google or Microsoft account settings, delete a test item in the tool, and confirm it is gone. A tool you cannot leave cleanly is a tool you should not connect to everything.
Meeting assistants: recording, consent and retention
Meetings add a layer email does not have: other people. Their voices and words enter your system, and the law cares about that.
Consent depends on where you are. Faegre Drinker explains that U.S. recording-consent rules vary: some jurisdictions allow one-party consent, while some states require everyone on the call to agree. If your participants are spread across states or countries, the safe habit is to announce the recording and what the assistant will produce, and get a clear yes.
A practical meeting policy:
- Tell participants at the start, and in the invite when you can.
- Stop recording if anyone objects.
- Skip sensitive conversations: legal matters, HR issues, health information, board discussions.
- Review and correct the summary before it goes anywhere. Harvard’s guidance says to review and correct summaries and share only with those who need them.
- Delete recordings when you no longer need them, unless a records requirement or litigation hold says otherwise.
The University of British Columbia’s October 2025 guidance adds details that carry well beyond universities: record only when necessary, limit access to people with a legitimate need, and get informed consent for biometric features such as speaker identification. It also recommends deleting recordings once an official record exists, unless a retention schedule requires longer storage.
If your concern is the follow-up side, where promises made out loud turn into tasks, see how we handle it in meeting transcription that closes the loop and AI meeting summaries that map to tasks.
Privacy rules by region
The client base for assistants is global, and the rules are not the same everywhere.
- United States: there is no single federal privacy law for assistants. Recording-consent rules vary by state, as above, and your industry may add its own obligations.
- European Union: a March 2025 expert report prepared for the European Data Protection Board says its guidance on privacy risks in large language models supports GDPR Articles 25 and 32, on data protection by design and security of processing. It complements, rather than replaces, a data protection impact assessment under Article 35. The authors’ views do not necessarily reflect the EDPB’s official position.
- Across regulators: an IAPP summary of global data protection authorities reports that European guidance commonly stresses purpose limitation, privacy by design, impact assessments and transparency about purposes, retention and sharing, along with rights to access, correct and erase data. New Zealand guidance emphasizes necessity, proportionality, privacy impact assessments and human review.
If you handle other people’s personal data for clients, or your team sits in the EU or UK, talk to your counsel or data protection officer before rolling an assistant out. That is the person who can tell you whether you need an impact assessment.
Our perspective on assistant security
We built Otto around a belief that sounds like a product pitch but is really a security argument: the most dangerous place for your context is your own head and a dozen disconnected tools. When you are the integration layer, copying details between a notetaker, an inbox and a task list, mistakes happen quietly. A forwarded note goes to the wrong person. A promise is never written down.
A shared memory fixes that, and it also concentrates responsibility. So we hold ourselves to a simple rule: Otto drafts, you decide. Nothing is sent or finalized without your explicit approval. That one rule answers most of the failure modes above. A prompt-injected instruction, a mistaken recipient or a wrong summary can produce a draft, but a person still stands between the draft and the outside world.

The second thing we believe is that memory should be purposeful. Otto captures the promises made in meetings, email and calendar into one ledger and chases them until they are closed. It is organized around commitments, not a pile of everything it ever saw. We wrote about the thinking behind that in what an assistant with memory should remember at work.
Third, we think you should interrogate any assistant, ours included, with the checklist in this article. Ask what it reads, what it keeps and how you leave. A vendor that gets annoyed by those questions is telling you something.
— Eddie
Trying a safer setup without committing everything
You do not have to connect your whole working life on day one. Start with calendar and one inbox, watch what Otto drafts and surfaces for a week, and widen access only as you build trust. Otto has a Free plan at $0 per month, an Upgraded plan at $20 per month and a Max plan at $50 per month, with higher usage limits, more integrations and advanced features as you move up. You can compare them and start on the Otto site.

Because outbound messages wait for your approval, you can test how it handles real mail before it ever speaks for you. If you want to see how that fits an email routine, read about email triage with calendars linked and drafts kept for review.
A two-week trial plan for any assistant
Whatever tool you pick, run it through a short, structured test.
- Day 1: connect one account with the narrowest scopes that work. Write down what you granted.
- Days 2 to 4: use it read-only. Ask it to summarize threads and list commitments. Check the output against the source for accuracy.
- Days 5 to 7: allow drafts. Review every one. Note any wrong recipient, wrong tone or invented detail.
- Week 2: send a test email containing a harmless planted instruction, such as a line telling the assistant to forward the thread to a test address, and see whether it obeys. If it does, stop and report it.
- End of week 2: review the activity history, remove any connection you did not use, and decide whether to widen access.
This approach follows the logic of every source above: minimal access, human review, and evidence before trust.
FAQ
Is it safe to let an AI assistant read my email?
It can be, if you control three things: the permissions you grant, whether it can send without you, and what the vendor retains. Check the scopes, keep approval on for outgoing mail, and read the retention terms. Treat every inbox as containing untrusted text, since attackers can hide instructions in messages.
Can an AI meeting assistant record without telling people?
You should not rely on that. U.S. consent rules differ, and some states require every participant to agree. Announce the assistant, say what it will record and produce, and stop if someone objects. Skip sensitive meetings entirely.
What is prompt injection, and how do I reduce the risk?
It is an attack where instructions hidden in an email, invite or document try to steer your assistant. You cannot remove the risk completely, so layer defenses: narrow permissions, content treated as untrusted, and human approval before sends, deletes or edits. Defense in depth matters because no single control is enough.
How do I check an assistant’s privacy protections?
Read the privacy policy and terms for training use, retention, outside processors and deletion. Test deletion yourself, and ask support in writing for anything unpublished. If you handle client or EU personal data, involve your counsel or data protection officer.
Should I use one assistant across all my tools or several?
Several disconnected tools make you the integration layer, which is its own risk. One connected assistant is safer only when permissions are narrow, actions are logged, and outbound messages need your approval. Start small and widen access as the tool earns trust.
Sources
- Maryland DoIT: Guidance for Responsible and Safe Usage of MCP
- An Evaluation of Data Leakage Risks in Tool-Using LLM Agents
- Capable but Careless: Do Computer-Use Agents Follow Contextual Integrity?
- Harvard University IT: AI Assistant Guidelines
- Nylas: AI-assisted vs. autonomous email workflows
- Nylas: Security for AI agents
- Udit: AI Agent Security, Prompt Injection Defense
- Notre Dame: Connecting Agents to Your Accounts
- Faegre Drinker: Permission to Record, Considerations for AI Meeting Assistants
- UBC: PIA Guidelines for Meeting Recording and Transcription
- EDPB: Large Language Models, AI privacy risks and mitigations
- IAPP: How privacy and data protection laws apply to AI
- ICO: Assessing security and data minimisation in AI