How Zanbase Agent uses your permissions

Zanbase Agent works on behalf of the person asking it to do something. That is what delegated authority means here: the software uses your permission to carry out a request. It does not receive a separate right to read the whole workspace because it is AI.

I want that boundary to be understandable before anyone asks it to change a project or read a document. Your access sets the limit. The actions available to Zanbase Agent, and the place where you ask, can narrow that limit further.

There are three useful questions to keep separate: whose permissions apply, who performs the action, and whether that action needs approval. They answer different parts of the same request.

Your access sets the boundary

If you can read a document, Zanbase Agent can use an available document-reading action on your behalf. If you cannot read it, asking Zanbase Agent does not create access. Knowing a document’s name or supplying its identifier does not replace permission.

The same distinction applies to changing work. Being able to read a project does not necessarily mean being able to edit it. A request to create or update a task must pass the permission checks for that project.

For example, suppose you can read a project but cannot change its tasks. You ask Zanbase Agent to update a deadline. The request cannot succeed simply because you describe the change clearly or because Zanbase Agent has a task-editing action available. The missing permission still matters.

Permission is also only one requirement. An agent’s configured tools determine which actions it can attempt. Access to a document does not promise that every place you speak to Zanbase Agent offers every document action. You can review the available work in what Zanbase Agent can do.

The person asking depends on the conversation

In a chat with Zanbase Agent, the person sending the message supplies the authority for that turn. When someone mentions Zanbase Agent in a conversation, the reply acts for the person who makes the mention.

A meeting has a similar rule with a different way of asking. Zanbase Agent joins a meeting when invited, and a reply acts for the speaker it answers. The person who invites it does not lend their permissions to everyone else in the meeting.

This matters when people with different access work together. If a colleague addresses Zanbase Agent during a meeting, that colleague’s permissions bound the requested action. The meeting does not become a route to another participant’s access.

Keep the audience in mind as well. Before asking for a summary in a shared conversation, choose material suitable for the people reading or hearing the answer. Before pasting private text into a shared prompt, review what you are disclosing. Permission to read something and the decision to share its contents are separate responsibilities.

Review replies and tool results

Permission answers whether an action may happen. Zanbase Agent performs its actions using the asking person’s authority, so it can do only what that person can.

An agent reply appears as an agent reply. In chat, you can inspect each tool’s input and result to check what Zanbase Agent attempted under your permissions.

For a person reviewing the result, the practical habit is straightforward: inspect the actual change. A response that sounds confident is not a substitute for the action’s outcome. In chat, tool results and errors give you evidence of what the requested action returns.

Some actions pause before they run

An interactive chat can ask you to approve an action. Actions marked as requiring approval include sending email and permanently deleting a task. When the request appears, the chat shows Run this action? with Approve and Deny controls.

Read the input before approving. Check the target, the contents, and the scope of the change. A request to remove a task deserves attention to which task; a request to send email deserves attention to the recipient and message.

If you select Deny, the action shows Denied — not run. If you approve it, read the output or error afterward. Approval allows the attempt; the action still has to satisfy your permissions and its other requirements.

Not every workspace change asks for this confirmation. Ordinary available actions can run as part of fulfilling your request. Treat the request itself as an instruction to act, and name the intended target clearly. The approval guide walks through the controls.

The place where you ask limits the tools

Voice replies, mention replies, and inline writing help do not offer the interactive approval controls. Actions that require approval are excluded from those surfaces. They do not run there merely because you have permission to perform them yourself.

There are other capability differences too. Zanbase Agent can create and assign tasks when asked in a meeting, subject to access and its available tools. Writing document content is not available from the meeting’s tool context.

This is why a request can be possible in one place and unavailable in another. If a task needs an approval prompt, use an interactive chat where you can inspect and respond to it. Changing the wording of a request does not add the missing control.

Outside AI tools use your authority too

MCP, the Model Context Protocol, lets an outside AI tool call Zanbase’s available actions. OAuth is the sign-in and consent flow through which you authorize that application. After consent, calls still use the authenticated person’s permissions; connecting a tool does not grant it broader access to workspace content.

The outside tool uses the shared action system. Its default set of actions excludes those requiring interactive approval. Any configured tool allowlist narrows that set further. An allowlist is simply a list of permitted actions, not a new permission to read their targets.

This connection also does not let the outside tool spend your connected service credentials through Zanbase. Keep authorization of an outside AI application separate from connections used by Zanbase’s own agents and automations.

Automations have a named human authority

An automation runs under its author’s authority: the human configured to delegate that work. The event that triggers it does not supply a different person’s permissions. A schedule supplies the time to run, not an independent identity with workspace access.

Turning on an automation approves the outside steps its author writes. Those configured steps run without asking for approval each time. That makes reviewing the program before enabling it part of the decision, including its targets and any outside effects.

Start with the automation guide and inspect the actions you configure. For both an automation and a direct request to Zanbase Agent, keep the same questions close: who supplies the access, what is the intended change, and what result confirms it happened?

Products used

• Zanbase Agent
• Automations