Skip to main content

Securing Business Actions in production

· 2 min read
Qefro Team
Qefro Team
Qefro

Business Actions let Customer AI and Employee AI call your REST APIs during a conversation. Treat every action like production API traffic — not like a demo plugin.

What a Business Action is​

TermMeaning
Business ToolConnector definition: URL, method, auth, schema
Business ActionOne runtime invocation of that tool

Concept page: What are Business Actions?. Broader threat model: AI Agent Security.

Controls that matter in order​

  1. Workspace scope — tools live inside a workspace; do not attach privileged write tools to a public Customer AI workspace without a hard reason.
  2. Least privilege — start with read-only GET tools. Add writes only after logging and authz are proven.
  3. Encrypted secrets — store credentials in the Admin Console; never in browser JS or prompts. See Secrets.
  4. SSRF-aware egress — tool URLs must not become a path to cloud metadata or internal networks.
  5. Identity forwarding — for customer-facing tools, use widget identify() so your API authorizes the end user, not only Qefro’s service credential.
  6. Execution logs — review unexpected calls as incidents. See Audit logs.

Prompt injection is a blast-radius problem​

No platform can honestly claim “prompt injection solved.” Design for containment:

  • Hostile text may appear in user messages and uploaded documents.
  • Validate tool arguments on your API, not only in the model prompt.
  • Prefer idempotent writes; require human approval for irreversible money movement.

Implementation path​

Follow the guide Secure Business Actions, then:

  1. Connect REST APIs or Import OpenAPI.
  2. Test the tool in the console before enabling chat invocation.
  3. Monitor GET /api/v1/tools/:id/logs (or the console equivalent) during pilot traffic.

When in doubt, ship knowledge-only assistants first. Actions can wait until retrieval quality and isolation are solid.