Your API stays in control

Dubot does not see or store customer auth tokens for your product.

Action execution runs client-side inside the customer’s application. Your integration supplies its own fetchFn, and auth headers, CSRF tokens, and tenant context are injected there — from your app’s own trusted session — never modeled as parameters the LLM fills in. Dubot manages the conversation layer and structured tool calls; execution stays inside your authentication boundary.

For sensitive actions, your backend enforces policy before execution. Product permissions, account state, and business rules stay in your system.

Confirmation for sensitive actions

Dubot lets teams require end-user confirmation before an action runs.

Every action carries an execution policy — automatic or confirm-first. Many teams use automatic execution for low-risk lookups and require confirmation for actions that create, modify, publish, submit, export, or trigger an external effect. A risk classification on the action pre-fills a suggested policy, but the admin can always override it explicitly.

Confirmation gives the end user a final review step before an action reaches your product or another system.

Defined action boundaries

The model does not invent arbitrary API calls.

Actions are defined by schema in your action library. The model selects from your configured actions and fills typed parameters. If an action isn’t enabled in your library, the model cannot see or execute it — disabled actions are never published to the registry an agent reads from.

Your product remains the source of truth for authorization. Your API should enforce its own access controls, validation, and business rules before any action runs.

When the AI gets it wrong

Language models can make mistakes, misinterpret intent, or be manipulated by hostile inputs such as prompt injection from content the agent is reading.

Actions are defined by schema, not generated freely. The model selects from your configured actions and fills typed parameters.

Sensitive actions can require end-user confirmation. The user sees the resolved call before it runs.

Your API enforces final authorization, validation, and business rules. Dubot cannot bypass it.

Action and conversation history can be reviewed to understand what happened and refine the action or agent definition.

Action history and analysis

Dubot records action and conversation history for review, including who triggered an action, what ran, what inputs were submitted, what changed or returned, completion status, and timestamps.

Action history is designed for support, security, and customer escalation workflows — it helps teams review what the agent attempted, what the customer approved, what your API returned, and where a failure occurred.

Codebase connections for action discovery

Engineering can connect a GitHub, GitLab, or Bitbucket repository so Dubot can discover and propose an action catalog automatically, kept in sync as your product evolves. This is separate from product action execution — Dubot can execute governed actions without any repo connection at all.

Data processing and subprocessors

Dubot processes customer data as described in its data processing, security, and subscription terms. For infrastructure, hosting, and compliance details, see our Privacy Policy.

Contact

Need a security review? Email security@dubot.ai.