Granting an AI agent access to company data is usually framed as a yes or no decision. It is not. The safe version is a series of small scoping choices that together give an agent exactly what a task needs and nothing more. This guide walks through those choices, with a worked example and a checklist you can reuse.
Why granting access is the hard part
The default path is the dangerous one. Most connectors ask an AI client to authorize with a broad OAuth scope, and a single grant hands the agent every message, file, or event the user can see. That is convenient and it is also how a helpful assistant becomes a data exfiltration path or, in well-documented cases, an inbox-deletion incident. Granting access well means narrowing that grant before the agent ever touches your data.
Scoped credentials, not raw OAuth
The first move is to stop handing agents raw provider tokens. With PortEden, the user connects an account once, and you mint a scoped credential for each agent instead of sharing the underlying Google or Microsoft refresh token. The credential carries its own scope and can be revoked on its own, so one agent never holds the keys to the whole account.
The six scoping decisions
For each agent, decide six things. These map to PortEden's six access-control layers, but the questions apply to any access model:
- Visibility: how much of a record does the agent see? Full content, filenames only, or free/busy only?
- Resources: which mailboxes, folders, or boards are in scope, and which are explicitly excluded?
- Actions: read only, or also draft, send, or delete? Most agents should start read only.
- Time window: the last 30 days, or the whole archive? Narrow windows shrink the blast radius.
- Account scope: which connected accounts or workspaces can this credential reach?
- Data reduction: what is redacted from responses before the agent sees it?
A worked example
Say you want an assistant to triage support email. The grant might be: visibility set to full body but with PII redacted, resources limited to the support label only, actions limited to read and draft (never send), a 30-day time window, scoped to the shared support mailbox only, and customer identifiers redacted. The assistant can summarize and draft replies all day, and it can never read the CEO's inbox, send a message, or see a raw account number.
Enforce at the boundary, not the prompt
A scope written into a prompt is a suggestion, and a model can be talked out of a suggestion by later input or a prompt-injection attack. Real access control is enforced by the system that brokers the request, so the rule holds regardless of what the prompt says. That is the difference between hoping an agent behaves and knowing it cannot exceed its grant.
Plan for revocation before you grant
Every grant should come with a clean way to take it back. Because each agent holds its own scoped credential rather than a shared token, you can revoke one agent in a single action without disconnecting the others or forcing the user back through a provider consent screen. If an agent is compromised or simply no longer needed, access ends immediately.
A grant checklist
- Mint a scoped credential per agent, not a shared OAuth token.
- Start read only; add write actions only when a task requires it.
- Limit resources to the specific labels, folders, or boards needed.
- Set the narrowest time window the task allows.
- Redact PII and secrets before the agent sees a response.
- Confirm every action is recorded in an audit trail.
- Keep a one-action revocation path ready.
For the underlying model, see AI access control and the definition of AI model access controls.