Connector access has three separate layers: a member's connection, an agent's authorization, and the named permissions granted to that agent. Connecting a service does not silently grant every agent every action.
Connection, authorization, and permission
| Layer | What it controls |
|---|---|
| Connection | Which member account or credential can be used for the service. |
| Agent authorization | Which agent may use that connected service. |
| Permission grant | Which named actions that agent may request, and for how long. |
For services with per-member credentials, each member connects their own account. A shared agent still acts through the connected account and grants of the member running it; it does not inherit a teammate's inbox, token, or private chat history.
Granting access
When an agent needs a connector permission it does not have, Okou shows a permission request. Review the connector, agent, permission name, and reason before choosing Allow or Deny.
An allowed permission can use one of the durations offered in the product:
- Allow for 1h
- Allow for 24h
- Allow for 7d
- Allow always
After a time-boxed grant expires, the agent must request it again. Denying one permission does not disconnect the account or remove unrelated permissions.
Manage an agent's current connector access from its authorization settings. The connector access view shows which agents are authorized and whether their permission state is allowed, denied, or mixed.
Credential handling
OAuth tokens and manually entered secrets are stored on the platform. For connector requests, the firewall injects the credential at the network boundary; the secret is not exposed to agent code as an environment variable.
Do not paste API keys, OAuth tokens, passwords, or client secrets into a chat, agent instruction, workflow instruction, or attached file. Use the connector's connection flow instead.
Disconnecting a member's connector removes that connection from future runs. Removing an agent authorization prevents that agent from using the connector while leaving other authorized agents unchanged.
Approval boundaries
The enforceable boundary is the connector's named permission grant. Do not rely on a generic action category to guarantee that every email, post, payment, infrastructure change, or deletion will always pause in the same way.
For work that must stay human-reviewed:
- Grant only the read or draft permission, and deny the final write or send permission where the connector exposes them separately.
- State the review requirement in the agent or workflow instruction.
- Keep the final action with the human, for example by producing a Gmail draft or a proposed change instead of sending or applying it.
Use upstream service controls as well: scoped API keys, least-privilege OAuth scopes, repository permissions, and separate production credentials.
Chats, logs, and admin visibility
Members access their own chat threads. Publishing an agent or workflow does not publish the member's private chat history or connector credential. Share a conversation or artifact only through an explicit sharing surface.
Workspace admins can see member-level usage aggregates used for billing and capacity management. That does not give an automatic cross-member view of private chat contents.
Within a member's own chat, the activity view records the visible run sequence, connector activity, artifacts, statuses, and errors. Use it to verify whether a requested connector action ran and whether it succeeded.
Review checklist
- Is the connector linked to the intended member account?
- Is the intended agent authorized?
- Are only the permissions needed for this task allowed?
- Can the grant expire after 1 hour, 24 hours, or 7 days instead of remaining permanent?
- Does the workflow keep irreversible or external-facing actions in a human-reviewed step?
- Can the upstream credential be narrowed further?
What's next
- See Chat for what happens inside a chat boundary.
- See Connectors for the catalog and what each one can do.
- See For teams for org-level permission setup.