What can an AI agent actually reach?
An AI agent can reach only the accounts and permissions you explicitly grant. The risk is not the agent's name; it is the scope of the keys, tokens and scopes you hand over. Least privilege means tying that access to the job it was hired for, making it expire, and removing it when the job ends.
How does an AI agent get into your accounts?
Most agents do not bypass account security. They are invited in through a delegated grant, a key or a session token. Each grant has a specific reach, but it is easy to approve more than the task requires, especially when a connector asks for read, send and delete at once.
The table below shows common ways an agent receives access. The question to ask is not whether the agent is legitimate, but what a stolen or confused agent could do with the grant you approved.
| Method | Typical reach | Least-privilege check |
|---|---|---|
| OAuth scope | Act as your account within the scopes you approve | Review each scope and deny write access where read-only is enough |
| API key | Call a service directly, often without per-action prompts | Restrict to one service and regenerate regularly |
| Session token | Carry an existing logged-in session | Set short expiry and revoke from account security |
| Shared password | Sign in as you, with full account rights | Avoid; use delegated access instead |
What should an agent actually be able to reach?
Least privilege begins with a simple rule: grant the smallest set of permissions that lets the agent do the specific job. If the job is to summarise incoming mail, read-only access to a labelled mailbox may be enough. If it must send replies, add send access only for that mailbox.
Use these terms when reviewing a permission screen or an API key.
- Scope
- A named permission that limits what an application can do with a connected account.
- Token
- A revocable credential that represents delegated access, often with an expiry.
- Read-only access
- Permission to view data without changing it.
- Write access
- Permission to create, send or delete data.
Why is 'it has not done anything bad yet' not a control?
That phrase describes the past. It tells you nothing about what the agent can reach later, what a malicious prompt might instruct, or whether the credential has been copied somewhere you cannot see.
A dormant permission is still a live permission. Treat past behaviour as a comfort, not a control. The control is the scope, the expiry and the audit trail.
- A quiet agent may still hold write access to an account it no longer needs.
- A well-behaved token is not the same as a narrow token.
- The control is the scope and expiry, not the agent's reputation.
How do you narrow an agent's access without making it useless?
Start with read-only, one connector and one account. Add write permissions only when a production task genuinely needs them, and add them to a dedicated service account rather than a personal account where possible.
If you connect a tool like GROX to email and calendars, review the scopes the connector requests and decline anything unrelated to the job. GROX acts inside existing tools through connectors, so the access you approve is the access it uses.
When is a simpler tool the better choice?
A simpler tool is the better choice when the work is a single, repeatable action and no memory or cross-app context is needed. A script, a native filter or a built-in integration may do the job with fewer permissions.
Choose an agent when the task needs reasoning across messages, calendar and files. If it only needs to post a weekly schedule, a calendar sharing rule is probably cleaner than a standing agent credential.
Common questions
Can an agent read my email if I only asked it to draft replies?
It depends on the permission you approve. If the connector requests read access to your mailbox, it can read messages even if you primarily use it for drafting. Check the scope list before connecting. Drafting replies usually requires some read access, but it should not require permission to delete mail or change account settings.
How do I revoke an agent's access?
Disconnect the application or integration from your account security settings, revoke its token, and remove any API key you issued. If you shared a password, change it and enable two-factor authentication. After revocation, check recent account activity to confirm the agent can no longer act.
Do read-only permissions still expose sensitive data?
Yes. Read-only access can still view messages, files, calendars and financial positions. Treat read access as sensitive because it discloses content, not just metadata. Grant read-only permissions only to the resources the agent actually needs, and revoke them when the task ends.
Can I grant an agent access that expires automatically?
Some platforms issue short-lived tokens or allow you to set expiry dates. Where that option exists, use it. Where it does not, create a reminder to review and revoke access on a set schedule. Avoid permanent credentials for agents that only need occasional access.
If you want to see how GROX handles account connectors under your own scope review, start with the free tier and check the Help Centre before you connect anything.