Security Overview

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

​

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 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 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 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: 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 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