> ## Documentation Index > Fetch the complete documentation index at: https://docs.duckie.ai/llms.txt > Use this file to discover all available pages before exploring further. # Access Control > Apply least privilege across teammates, API keys, MCP clients, integrations, agents, and approvals Access control in Duckie is layered. Workspace roles control human access, API keys and MCP scopes control machine access, connected app permissions control external data, agent tool access controls what agents can do, and approvals add review before sensitive side effects. ## Start With Workspace Roles Manage teammate access from [Team Members & Roles](/settings/members). Use roles to separate responsibilities: | Access area | Typical owner | | -------------------------------------------------- | -------------------------------------- | | Organization, members, roles, and billing settings | Workspace admins | | Agent, workflow, runbook, and tool configuration | Builders and support operations | | Knowledge, guidelines, and guardrails | Training and content owners | | Testing and analytics | Operators, reviewers, and stakeholders | Create custom roles when a built-in role is broader than the job requires. Review roles regularly, remove departed users, and keep the number of admin users small. ## Separate Human Access From Machine Access API keys are for integrations and external clients, not individual teammate login. Create API keys in [Settings -> API & MCP](/api/api-key-management). Each key has a name, scopes, creator, created time, last-used time, expiration, and status. The full key is shown only once; after creation, Duckie stores a hash and preview. Use separate keys for separate integrations so you can: * Grant different scopes. * Rotate one integration without affecting another. * Set different expiration schedules. * Revoke unused or compromised access quickly. Duckie rejects revoked, expired, or insufficient-scope API credentials. ## Scope API and MCP Clients Duckie API keys use scopes. Customer API scopes control direct `/api/v1` requests, while Duckie Assistant MCP scopes control the first-party MCP core object tools. | Scope group | Use for | | ------------------------------- | ------------------------------------------------------------------ | | Customer API read scopes | Reading runs, tools, agents, guidelines, guardrails, and runbooks | | Duckie Assistant MCP core read | Listing and retrieving core objects through MCP | | Duckie Assistant MCP core write | Creating, updating, and deleting writable core objects through MCP | MCP clients see only the wrapper tools allowed by the credential's scopes. Prefer read-only scopes unless the client must create or update Duckie configuration. Learn more in [MCP](/api/mcp) and [API-Key Management](/api/api-key-management). ## Limit Connected App Access At The Source Connected apps determine what Duckie can read or update in external systems. Before connecting an app, decide which account, workspace, project, repository, channel, or knowledge source should be available. Use [Connections](/settings/connections) to manage integrations, and use provider-side permissions where possible. For example, connect accounts and tokens that have only the external access needed for the intended agent workflow. For supported app categories, see [Supported Integrations](/integrations/supported-integrations). ## Limit What Each Agent Can Do Tool access is configured per agent and for the internal assistant. Enable only the tools that match the agent's job. | Tool type | Access control pattern | | ------------ | -------------------------------------------------------------------------- | | Duckie tools | Enable only the built-in actions the agent needs | | App tools | Connect the app, then enable specific app tools for the agent or assistant | | Custom tools | Keep each custom tool narrow and enable it only where needed | | MCP tools | Connect the MCP server and expose only the needed tools | For agents that can update customer records, combine tool access with [Account-Safe Actions](/security/account-safe-actions), workflows, and approvals. ## Require Approval For Sensitive Actions Use approval before sensitive or high-impact changes, especially when a tool can: * Change billing, plans, entitlements, account ownership, or security settings. * Send a customer-visible message. * Update external systems. * Delete, close, resolve, or transfer records. * Change Duckie configuration through MCP write tools. Custom tools can be marked as write actions and configured to require approval before execution. When approval is enabled, a run can pause until the action is approved or rejected. See [Write Actions and Approvals](/tools/custom-tools#write-actions-and-approvals) for custom tools. ## Review Run History Use [Run History](/analytics/runs) to review what the agent did. Run details show the triggering conversation, execution steps, knowledge retrieved, tool calls, inputs, outputs, status, and final response. For access reviews, sample recent runs for agents with write tools or broad knowledge access. Confirm that the agent used expected tools, record selectors, and guardrails. ## Least-Privilege Checklist | Area | Check | | -------------- | ----------------------------------------------------------- | | Members | Only users who need admin access have it | | Roles | Custom roles match real job responsibilities | | API keys | Separate keys exist for separate integrations | | API scopes | Keys use the narrowest scopes that work | | Expiration | Keys have expiration dates where practical | | MCP clients | Write scopes are enabled only when needed | | Connected apps | External accounts and tokens are limited at the provider | | Agent tools | Each agent has only the tools required for its role | | Approvals | Sensitive writes require review before execution | | Review | Run history is checked after launch and after major changes | ## Related Docs Invite members, assign roles, and configure permissions. Create, scope, expire, rename, and revoke API keys. Configure each agent's tools, knowledge, guardrails, and behavior. Review steps, tool calls, inputs, outputs, and final outcomes.