Back to the blog
Security & privacy

How agent permissions work in Skybits

Understand the difference between agent identity, connector scopes, document access, and account action controls in Skybits.

An agent needs both access to information and authority to perform actions. In Skybits, these decisions involve the connection's identity, document permissions, and applicable agent controls. Connecting an agent does not remove the need to check each of those boundaries.

Imagine an analyst who wants an assistant to read a forecast and explain the assumptions. Reading may be enough. An assistant preparing new tables needs editing authority as well. Neither task necessarily needs permission to share the forecast or move it to Trash.

Identity answers who is acting

An agent connects using an authenticated route such as OAuth or a connector API key. The connection acts for an accountable user and is checked against that user's relevant authority.

Skybits checks agent credentials and document permissions. Review the connection status and expiry in Settings; a prompt is not a substitute for an authorized connection.

A friendly agent name is useful for recognizing activity. It should not be confused with a separate security boundary or independent verification of the software behind the connection.

Scopes answer which tools a connector may use

For API-key connections, the documented setup lets you choose Read documents and, when needed, Create and edit documents. A summarization client can start with reading. A temporary editing task can use a key with an expiry.

Tool scopes are one layer. They do not automatically create a selected-document allowlist. The underlying document access still matters.

OAuth connections use the authorizing user's document authority; their controls should not be assumed identical to API-key scope selection. Check how the particular client connects before copying instructions from another assistant's setup.

Document permissions answer which work is reachable

Agent requests are checked against the relevant document permissions. Where an incoming share requires acceptance, agent access waits for acceptance.

Review access inherited from folders and tags as well as direct grants. An agent that can search accessible work may have a wider view than the item currently visible in your browser.

Account controls answer which sensitive actions are allowed

The current Guide describes account settings for agent sharing, Trash, and restoring versions. Agent sharing is off by default. When it is enabled, the configured limits govern the audience and roles the agent may grant.

An enabled permission authorizes an action within its limits. It does not necessarily add an interactive approval dialog to each tool call. If you want a person to make the final sharing decision, leave that authority restricted and have the agent stop with a draft.

Version restoration also deserves care. The documented operation can replace the complete current item, including its comment threads, with a prior revision. Recovery authority can therefore affect other people's current work.

A practical setup for a bounded task

  1. Name the exact sources and expected output.
  2. Review the account's accessible items and sharing inheritance.
  3. Start with read-only connector scopes if reading is sufficient.
  4. Add editing only when the task requires it.
  5. Keep sharing and other management actions restricted unless needed.
  6. Set an expiry where appropriate and store the secret securely.
  7. Review the result, then revoke a temporary connection when finished.

Skybits permissions constrain Skybits actions. If the same agent also has local files, shell access, email, or other services, those permissions need their own review.

Next step: Review Skybits Help. Ask for less authority before asking the model to behave more carefully.

Try your first doc now

Start now