A new class of personal AI assistant is asking business owners for standing access to email, calendars, files, and payment methods. In some cases, it also asks for the account password and the authenticator secret itself.
Assessed against enterprise agent security baselines, several of these designs fail core controls.
The three most serious findings are:
- The assistant can enroll as the authenticator, with the seed stored beside the password in the same cloud vault. That collapses two-factor authentication into one factor.
- Disconnecting a service does not automatically delete data already collected from it.
- No published defenses against prompt injection were identified.
Businesses should not connect corporate email, payment methods, or MFA secrets to these tools in their current state.
This assessment concerns an invite-only autonomous AI assistant currently in private beta. The assistant is backed by significant venture funding and reportedly carries a multi-billion-dollar valuation while still in private beta. The larger issue, however, is not one vendor. It is the security model being introduced across this product category.
What We Audited and How
The assistant is text-first. Users interact with it through a phone or messaging channel, while the underlying agent operates on a persistent cloud computer.
That computer can maintain browser sessions, store credentials, access connected services, and act without the user sitting in front of it. Depending on the permissions granted, it can read email, inspect calendars and files, send messages, make purchases, and enter agreements on the user’s behalf.
The product’s beta terms also disclaim that the service may contain defects, errors, or inaccuracies that could cause failures, corruption, or loss of data.
Our assessment is based on:
- Published terms and privacy documents
- Company statements
- Reports from early users
- Press coverage describing observed behavior
This was not a penetration test. We did not independently inspect the product’s source code, cloud environment, encryption implementation, or internal controls. Where a finding rests on the absence of public disclosure rather than a demonstrated exploit, we say so plainly.
The benchmark is standard enterprise agent security practice, including OWASP’s LLM risk taxonomy, NIST guidance, and published approaches from major identity and cloud vendors. OWASP’s 2026 list ranks prompt injection first, sensitive information disclosure second, and excessive agency third. Those three categories dominate this review for a reason.
The Architecture Problem: Standing Ambient Authority
The central security issue is the combination of three design choices. Together, they create standing ambient authority rather than scoped, task-by-task access.
- Persistent cloud execution: The agent runs on its own cloud machine with saved browser sessions and account tokens. It can re-enter authenticated dashboards without the user being present.
- Broad connected-service authority: The terms authorize the service to access, copy, collect, and index data from connected services, exchange data with them, and take actions on the user’s behalf.
- Authority to bind the user: The terms appoint the service as the user’s agent for agreements, commitments, and transactions. Those commitments are treated as binding on the user as if the user entered them directly.
This is architecturally different from an agent holding short-lived, narrowly scoped credentials for one task.
It is closer to handing someone a keyring and a power of attorney, then hoping the software is careful.
Findings Summary
| Finding | Severity | What it means for a business |
|---|---|---|
| Authenticator enrollment with the seed stored beside the password in the same cloud vault | CRITICAL | Two-factor authentication degrades to one factor in substance. |
| No published credential encryption detail for the vault | HIGH | The company does not publicly describe the encryption algorithm, key management, or hardware security module, and has not published an audit or bug bounty. |
| Disconnecting a service does not delete collected data | HIGH | Disconnect and delete are separate actions. Revoking access does not revoke copies already collected. |
| No published prompt injection defenses | HIGH | The top risk category in the industry’s own taxonomy has no published testing methodology, detectors, or disclosure channel. |
| Training on user data by default with a limited opt-out | HIGH | The opt-out is forward-looking only and does not unwind models already trained. |
| Agent actions bind the user while liability is capped very low | MEDIUM | The consequences sit with the customer, while recovery does not. |
| No retention schedule or deletion timetable published | MEDIUM | Customers cannot determine what is retained, for how long, or whether backups and derived data are covered. |
Finding One: The Vault
The assistant includes an in-product credential store where users can place third-party usernames and passwords. The purpose is straightforward: the agent uses those credentials to sign in on the user’s behalf.
The one clearly documented safeguard is that vault contents will not be used to train AI models.
That is useful, but it does not answer the more basic questions about protecting the secrets themselves.
The public materials do not identify:
- An encryption algorithm
- A key hierarchy
- Use of a hardware security module
- Whether company employees or vendors can decrypt stored secrets
- A security documentation page
- An independent audit or penetration test
- A bug bounty or coordinated disclosure program
In a separate reported incident, the assistant itself reportedly confirmed that ingested email was stored in plain text for later searching. That concerns email rather than the vault specifically, so it is not proof that vault passwords are stored in plain text. It does, however, fail to build confidence in the broader storage model.
The product has since announced an integration with a well-known password manager using just-in-time credential delivery. That is a genuine improvement in direction. A brokered model can reduce the need for a permanent raw password store.
However, no technical specification for that integration has been published. It is also not confirmed whether the agent process ever handles plaintext credentials during the login flow.
Finding Two: The Authenticator
This is the most severe finding.
Rather than allowing the user to keep an independent authenticator app, the assistant can enroll itself as the authenticator on an account. It stores the shared TOTP secret in the same vault as the password and generates the six-digit codes on the user’s behalf.
The security consequence is precise.
A password is normally the “something you know” factor. An authenticator device or app is the “something you have” factor. The purpose of using two factors is to keep those secrets independent.
When the TOTP seed is stored beside the password in the same cloud vault, a single compromise of the assistant can yield both factors.
The factors collapse into one.
That does not mean the account has no protection. It means the account has essentially the protection it would have had with a password alone, plus a false sense of having more.
The public materials also do not disclose:
- An encryption scheme for the TOTP seed
- A rotation policy
- An export or recovery procedure
- Whether employees or vendors can access stored authenticator secrets
The practical rule for businesses is simple:
For any account that requires MFA for compliance, insurance, or contractual reasons, enrolling a third-party agent as the authenticator should be treated as defeating the control, not satisfying it.
If your organization has signed a cyber insurance attestation about MFA, this distinction matters.
Finding Three: Disconnect Does Not Mean Delete
The documented retention model separates connectivity from deletion.
The terms state that disconnecting a connected service does not automatically delete information already collected from that service. The company may continue using indexed data unless the user follows a separate deletion request process.
Account deletion does not provide a hard deletion guarantee in general. There is one documented exception for data collected through the APIs of a particular major productivity provider. The same assurance does not clearly extend to other productivity suites, messaging services, screen captures, audio, or location data.
Early users reported that after disconnecting an integration:
- The assistant continued delivering summaries from that data source hours later
- Copies of messages remained in the assistant’s own records
- An account export contained full message text
Following public criticism, the company added a deletion tool and acknowledged that the earlier behavior represented a gap.
The finding remains:
Disconnect and delete are different operations.
Revoking an integration does not revoke the copy already collected.
There is still no published retention schedule, deletion timetable, or clear statement about whether deletion reaches backups, caches, or data already used to train or fine-tune a model.
For a business, that means data exposed to the assistant may persist beyond the decision to stop using it. You may also have no way to prove otherwise to a client, auditor, or insurer.
Finding Four: Prompt Injection
An agent that reads your email will read anything people send you, including instructions crafted to manipulate it.
If that agent can also act on what it reads, untrusted text becomes untrusted commands.
The product’s privacy policy acknowledges this risk by warning about third parties sending misleading instructions intended to influence autonomous agents. The problem is that no matching defenses have been published.
Reported demonstrations show a consistent pattern:
- A user sent instructions from an unrelated account, and the assistant followed them. The user then deleted the account and said it was not yet safe to give an AI read and write access to an inbox.
- Another user reported that the assistant sent an email on their behalf without confirmation and then disconnected email access.
- Another reported an injection message circulating through the assistant’s own inbound email identity, demonstrating the additional risk created when an agent has an inbox of its own.
The public materials do not describe:
- A prompt injection testing methodology
- Red team results
- Detection systems
- Guardrails for high-impact actions
- A bug bounty
- A coordinated disclosure path for researchers
This is the most important gap in the audit. Prompt injection is ranked as the number one risk in the industry’s own taxonomy for these systems, and the consequences become more serious when the agent has access to business data and the ability to act on it.
Finding Five: Terms and Data Rights
The original terms granted a broad license over user materials. The definition included items such as screen recordings, cursor movement, and keystrokes. The license was described as transferable and sub-licensable, and the original version also described it as perpetual and irrevocable. AI model training was an explicit purpose.
The original privacy notice also listed personalized advertising as a permitted use.
After public criticism, the company made meaningful changes:
- The words perpetual and irrevocable were removed
- Explicit references to screen captures, cursor movement, and keystrokes were removed
- The advertising reference was removed
- The company added a statement that it does not sell user information
Those are genuine improvements.
The current operative language still presents a concern. Training on user materials remains the default. The opt-out is forward-looking only, does not apply to material flagged for safety review, and does not undo models already trained or improved using the customer’s data before the opt-out.
There are two important carve-outs, one for vault contents and one for API data from a particular major productivity provider. There is no equivalent carve-out for other productivity suites, messaging platforms, screen captures, audio, or location data.
The enterprise default is the opposite. Well-run organizations keep customer data out of model training unless a data processing agreement explicitly authorizes it.
A product that trains by default and offers only a forward-looking opt-out is asking the customer’s data to fund product improvement. The customer cannot fully get that data back.
Agent Authority and Liability
Two additional clauses compound the data risk.
The terms appoint the service as the user’s agent for binding agreements and transactions. Disputes remain between the user and the third party, rather than becoming the assistant’s responsibility.
The terms also cap total liability at a very small amount, while directing most disputes to individual arbitration and waiving class actions. Financial, contractual, and legal consequences of the agent’s actions are assigned to the customer.
The benefit of autonomous action is real. So is the asymmetry.
The assistant can commit you, and it cannot meaningfully compensate you.
Why This Matters Beyond One Product
The patterns in this audit are appearing across the broader autonomous assistant category:
- Persistent credentials are being used instead of scoped, short-lived credentials
- The MFA factor is being centralized beside the password
- “Disconnect” is being treated as a privacy control when it is only a connectivity control
- Prompt injection is being recognized as a major risk without published defenses
Any business evaluating an autonomous assistant should start with those four questions.
This is the same principle we apply elsewhere in cybersecurity: access you cannot enumerate is access you cannot revoke.
| What these assistants typically do | What enterprise agent security practice requires |
|---|---|
| Store passwords in a general-purpose cloud vault | Use a dedicated secrets manager with documented encryption, access controls, logging, and rotation |
| Enroll the agent as the authenticator | Keep MFA authenticators under organizational control and separate from agent credentials |
| Maintain browser sessions and standing tokens | Use short-lived, per-task credentials that expire automatically |
| Request broad access to email, files, calendars, and payments | Apply least privilege, narrow scopes, and separate identities for each workflow |
| Treat disconnecting an integration as sufficient | Provide verifiable deletion across primary systems, backups, caches, and derived data |
| Train on user data by default | Keep training off unless explicitly authorized by contract |
| Rely on general safety language for prompt injection | Publish testing, monitoring, approval gates, and high-impact action controls |
| Provide limited public security information | Maintain independent assessments, vulnerability reporting, and incident disclosure processes |
| Assign consequences to the customer while limiting liability | Provide clear accountability, reasonable liability terms, and meaningful recovery options |
The enterprise baseline is achievable. Well-run organizations already demand these controls from their vendors.
Which Stage Are You In?
Stage one: Personal use only
An employee or owner is experimenting with an assistant on a personal account. Nothing corporate is connected yet.
This is the moment to set a policy before experimentation becomes access.
Stage two: Creeping access
Someone has connected a work calendar, mailbox, shared drive, or payment method. Nobody reviewed it, and the tool is not in your vendor inventory.
This is the danger zone. It is where many organizations are right now.
Stage three: Governed
You have a written position on which AI tools may touch business data. You know which assistants are connected to which accounts. MFA is enforced with authenticators your organization controls. You can revoke access and prove it.
That is the standard to aim for.
Practical Takeaways
- Never store a business account password in a third-party assistant. Never let an assistant enroll as the authenticator on an account that matters. If you have done either, rotate the password and re-enroll MFA on a device you control.
- Treat disconnect and delete as separate actions. Ask vendors in writing what deletion covers, including backups, caches, logs, and derived data.
- Add assistants to your shadow IT inventory. Check corporate tenants for connected third-party applications with standing access. Our shadow IT and AI restrictions article covers how that access accumulates.
- Assume anything an agent can read may be used to instruct it. Do not grant read and write access to a mailbox without a documented reason, approval, and review date.
- Verify MFA attestations. If you have attested to MFA for insurance or compliance, confirm that nobody has delegated the second factor to an autonomous tool.
This is the kind of product review and access governance work we do for clients, including evaluating tools before they touch business data, reviewing connected applications, enforcing MFA with authenticators the organization controls, and documenting access so it can be revoked. We hold our own contractors and virtual assistants to the same standard.
Our Managed IT services in Phoenix include the monitoring and governance work needed to keep new tools from quietly becoming permanent access paths. We also use our MSP AI agent Hermes to help surface new connected applications and unusual activity, so a human can get involved when a decision is needed.
Limitations
No independent audit or penetration test of this product has been published. This assessment reflects the documents, company statements, and early user and press reports available at the time of writing. Some findings describe missing disclosures rather than confirmed implementation weaknesses. The absence of public documentation is not proof that a control does not exist, but it is a meaningful limitation for any business considering the product.
If someone on your team has already connected an AI assistant to a work account, we can review what it can still reach.
