> ## 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. # Security Overview > Configure Duckie with scoped access, safe tools, guardrails, testing, and review workflows Duckie security is configured in layers. Use workspace roles to control who can change Duckie, API and MCP scopes to control machine access, tool access to control what agents can do, guardrails to define hard boundaries, testing to validate behavior before production, and run history to review what happened. This page is a starting point for security setup. Use the linked pages for detailed configuration steps. ## Security Layers | Layer | What it controls | Where to configure it | | ------------------------ | ------------------------------------------------------------------ | ------------------------------------------------------------------------- | | **Workspace access** | Which teammates can view, build, deploy, test, and manage settings | [Team Members & Roles](/settings/members) | | **API and MCP access** | Which external clients can read or update Duckie objects | [API-Key Management](/api/api-key-management) and [MCP](/api/mcp) | | **Agent tool access** | Which tools each agent or assistant can use | [Agent Configuration](/agents/configuration) and [Tools](/tools/overview) | | **Account-safe actions** | Which customer, account, ticket, or record an action can affect | [Account-Safe Actions](/security/account-safe-actions) | | **Guardrails** | What agents must block or escalate | [Guardrails Overview](/guardrails/overview) | | **Testing** | Whether agent behavior is safe before it reaches customers | [Testing Overview](/testing/overview) | | **Run history** | What the agent saw, retrieved, called, and returned | [Run History](/analytics/runs) | | **Deployment model** | Where Duckie runs and who operates the runtime environment | [Self-Hosting](/self-hosting) | ## Start With Least Privilege Give each person, key, agent, and integration only the access it needs. For human access, use workspace roles and custom permissions. Limit administrative access to users who need to manage organization settings, members, roles, connections, and API keys. For machine access, create separate API keys for separate integrations. Give each key only the scopes needed for that integration, set an expiration when possible, and revoke keys that are no longer used. For agents, enable only the tools, knowledge, guardrails, workflows, runbooks, and callable agents needed for that agent's job. ## Keep Actions Scoped When an agent can update customer data or call an external API, the highest-risk failure mode is acting on the wrong account or record. Use [Account-Safe Actions](/security/account-safe-actions) to design these flows. The recommended pattern is: 1. Choose an authoritative account or customer identifier. 2. Pass record selectors from verified context, fixed values, or workflow lookup output. 3. Use workflows for lookup, comparison, approval, and write steps. 4. Add guardrails for wrong-account requests and cross-customer disclosure. 5. Test misuse cases before enabling the agent in production. ## Secure Tool Boundaries Tools are where agents read context and take action. Duckie supports Duckie tools, app tools, custom tools, and MCP servers. Use [Tool & Integration Security](/security/tool-and-integration-security) when configuring tools that can read external data, send messages, update records, or call customer-defined APIs. Key patterns include: * Enable tools per agent or assistant. * Use fixed values, org variables, context variables, and workflow outputs instead of asking the agent to invent record IDs. * Mark tools that change external state as write actions. * Require approval for sensitive side effects. * Review tool inputs and outputs in run history. ## Reduce AI Misuse Risk Customer messages, synced knowledge, webpages, and tool outputs can contain instructions that should not override your configured agent behavior. Use [AI Safety & Prompt Injection](/security/ai-safety) for patterns that help reduce this risk: * Keep durable instructions in agent configuration, workflows, runbooks, guidelines, and guardrails. * Treat customer and retrieved content as data. * Use deterministic workflow checks for sensitive paths. * Add restrictions and escalation rules for unsafe requests. * Include adversarial and cross-account prompts in test suites. ## Test Before Production Use Duckie's testing surfaces before changing a live deployment: | Testing method | Use it for | | ----------------------------------------- | ------------------------------------------------------------- | | [Playground](/testing/playground) | Quick interactive checks while configuring an agent | | [Replay Testing](/testing/replay-testing) | Validating behavior against historical conversations | | [Batch Testing](/testing/batch-testing) | Repeatable regression coverage before launch or major changes | For security-sensitive agents, test happy paths, false positives, guardrails, tool execution, wrong-account requests, and prompt-injection attempts. ## Review What Happened Use [Run History](/analytics/runs) to inspect the conversation, execution steps, knowledge retrieved, tool calls, inputs, outputs, status, and final response. Run history is the primary place to confirm whether an agent used the intended context, called the expected tools, followed guardrails, and produced the expected outcome. ## Related Docs Manage workspace roles, API keys, MCP scopes, connected apps, and agent access. Configure tools, credentials, write actions, approvals, and safe external calls. Reduce prompt-injection and misuse risk with workflows, guardrails, and testing. Configure support agents to act on the right customer, account, and record.