AgentQ Permissions
AgentQ is governed by the platform-level user role. There is no datastore-level team permission for it, because the AI provider configuration belongs to the whole deployment rather than to any one datastore.
What Each Role Can Do
| Action | Member | Manager | Admin |
|---|---|---|---|
| Chat with AgentQ in the full page, the floating chat, and the embedded assistant | |||
| Start, resume, rename, archive, restore, delete, and search your own chats | |||
| Open Settings in the AgentQ sidebar | |||
| Connect, change, or disconnect the AI provider | |||
| Set the access level | |||
| Open the AgentQ audit |
What AgentQ Can Reach on Your Behalf
AgentQ runs its tools as the person chatting with it, so it never widens what that person can already reach. A user whose access is restricted to a team sees only that team's datastores through AgentQ, the same as in the web app, even when their role would otherwise reach further.
The access level applies on top of this and narrows it further for everyone at once. See AgentQ Access Controls.
Team Permissions Behind the Tools
The role decides whether you can use AgentQ at all. What AgentQ may then do on your behalf comes down to your team permissions on each datastore, checked tool by tool with the same rules as the rest of the platform.
| Kind of tool | Typical requirement |
|---|---|
| Reading assets, profiles, scores, checks, anomalies, operations, and schedules | Reporter team permission |
| Reading comments through reporting queries | Reporter team permission |
| Writing comments, and checking an operation's progress | Viewer team permission |
| Creating a check as a Draft, and dry running a check | Drafter team permission |
| Creating a check as Active, and updating, validating, or deleting a check | Author team permission |
| Updating an anomaly's status, tags, assignees, or description | Author team permission |
| Archiving an anomaly | Editor team permission |
| Creating a computed table, file, or join | Editor team permission, or Author when you will own the asset, the same rule the form uses. For a join, that applies to the datastore the join lands in; the other side only has to be readable, at Viewer |
| Changing or deleting a computed table, file, or join | Editor team permission |
| Creating, changing, or deleting a computed field | Editor team permission, or Author when you own the field |
| Creating, changing, and deleting containers, datastores, and score settings | Editor team permission |
| Running operations, and creating, changing, running, pausing, or deleting schedules | Editor team permission |
| Deleting an operation record | Editor team permission, and you must have started the operation yourself unless you have the Admin role |
| Managing global templates and global tags, and sending through integrations | Manager or Admin role |
Team permissions build on one another: Editor includes Author, Author includes Drafter, Drafter includes Viewer, and Viewer includes Reporter, so a higher level always meets a lower requirement. Comments are personal: you can edit or delete only your own, although an Admin can delete any comment.
If you lack the permission for a tool, AgentQ tells you the action was not permitted rather than working around it. It cannot act outside your access, and it cannot grant itself more. The one exception is the Admin role, which has access to every datastore and is not subject to team permission checks.
Writes take effect as soon as a tool runs. There is no confirmation step built into the tools, so AgentQ is instructed to get your agreement before anything destructive or irreversible. What a deletion does depends on the tool. Deleting a field, a quality check, or a check template archives it rather than removing it, and an archived field or check can be restored. Deleting a check also removes the anomalies it raised by default, unless you ask to keep them. The same goes for deleting a source table or file, while deleting a computed asset, a computed field, a tag, a schedule, a comment, or an operation record is permanent and cannot be undone. The validate and dry run tools let you check a definition before committing to it.
Actions AgentQ Performs
When AgentQ creates or changes something in the platform, the change is recorded against whoever authenticated, not against a shared AgentQ identity. In the chat that is the person typing. Through the AgentQ API, it is the owner of the token, so a call made with a service account's token is attributed to that service account and inherits its role and teams. The audit shows the action, the record it touched, and the transaction it belongs to. See AgentQ Audit.
See Also
-
How It Works
Where AgentQ appears, how a turn runs, and what it is allowed to see.
-
The Chat Interface
Every control in the full-page and floating chat, and what the input accepts.
-
MCP
What the Model Context Protocol is, how it works, and why it matters.
-
AgentQ in Action
How Qualytics implements MCP, with its endpoint, tools, and tool step labels.
-
Tool Catalog
Every tool AgentQ can call, what each one does, and what it shares with the model.
-
Semantic Reporting
The structured query interface AgentQ uses to count, filter, and inspect platform resources.
-
Access Controls
How an administrator chooses what chat may share with the model, and what each level unlocks.
-
AgentQ Audit
What each audit entry holds, how cost estimates work, and what the period summary reports.
-
Supported AI Providers
Every provider you can connect, what the Beta badge means, and which ones take file attachments.
-
Amazon Bedrock Authentication
The three ways to authenticate to Bedrock, and what an IAM role setup expects.
-
Conversations, Responses & Context
How to write prompts, read AgentQ responses, and work with context-aware chats.
-
AgentQ Limits
Rate limits, token usage, timeouts, SQL constraints, and scope constraints.
-
Examples
Worked scenarios showing what you ask AgentQ, what it does, and the shape of the answer.
-
Best Practices
Prompt design, cost management, guardrail behavior, rate limits, and async operation patterns.