Skip to main content

Protect integrations, functions, and secrets

An attached function can move data or change an external system. Treat capability design as an authorization problem, not only a prompting problem.

Connect securely​

Use the Wirevox integration setup or provider OAuth consent flow. Never paste access tokens, API keys, passwords, client secrets, or one-time codes into prompts, variables, knowledge bases, Vox chats, or support messages.

Integration access and refresh tokens are stored through Supabase Vault. The decrypted integration view is denied to anonymous and ordinary authenticated database roles and is available to the backend service role. Credential-based provider payloads use the same protected secret path.

Apply least privilege​

  • Connect a test account before production.
  • Approve only the provider scopes needed by enabled actions.
  • Create separate read and write functions when the catalog permits it.
  • Attach only the functions required by the agent's role.
  • Disable guest-test tools unless external side effects are intended.
  • Use a human handoff for unusually sensitive or irreversible actions.

Defense in depth for actions​

The system prompt should define trigger, required inputs, confirmation, success, empty result, and failure behavior. The server-side adapter must independently validate inputs and workspace/provider state.

Never rely on “ignore prompt injection” wording as the only control. A model instruction cannot replace scoped credentials, parameter validation, rate limits, idempotency, audit records, or approval.

Vox approvals​

Vox read operations use the authenticated user's workspace permission boundary. Write, external, and destructive capabilities create approval records containing hashed arguments, an idempotency key, status, result or error, and an expiration time. Execution rechecks the action's argument integrity and authorization.

Only a succeeded action record proves completion. A prepared or pending approval has not changed the platform.

Disconnect an integration​

Disconnecting removes agent tool connections for that provider and calls the secure deletion procedure for its integration record and Vault secrets. Where supported, Wirevox also requests provider-side OAuth revocation.

Disconnection does not:

  • delete appointments, contacts, emails, or cases already created externally;
  • erase tool results already stored in Wirevox conversation records; or
  • remove prompt text that still references the function.

After disconnecting, review affected agents, detach or replace the function, resolve prompt warnings, test, and publish.

Rotate after exposure​

If a secret may have been exposed, revoke or rotate it at the provider first, disconnect and reconnect Wirevox, inspect recent tool activity, and remove the secret from every prompt, message, log, file, and repository where it appeared.