Integrations & credentials — Pazi Documentation

Integrations & credentials

Integrations give agents approved ways to use the web and third-party services. Saved credentials are encrypted business-scoped secrets that Pazi makes available only to future agent runs that need them.

Web browsing

Open Integrations and use the Web Browsing switch to allow or block web search, page fetching, and browser-use work. New accounts start with browsing enabled.

When browsing is off, an agent cannot silently work around it. Supported browser routes return a permission request so you can decide whether to enable browsing. See Browser permissions for domain rules and approval levels.

How an agent requests a secret

An agent should call Pazi's secure credential request instead of asking you to paste a secret into chat. The web conversation renders a form with the service and required field names.

Submit the values only after checking the service, fields, and requesting agent. The browser sends them once to the encrypted save path; no API returns the saved values back to the browser later.

Business scope

Saved credentials belong to one user and one business. Every agent in that business can use them on future runs, regardless of which agent originally requested or saved them.

Credentials never cross into another business or account. An agent without a business has no saved-credential pool.

This means “connect GitHub for this business” is usually a one-time action. Do not save a credential if every agent in that business should not be allowed to receive it.

When a saved value becomes available

Pazi rebuilds the credential environment at the start of every web, Slack, email-triggered, or scheduled run. Saving a credential while a run is already executing does not inject it into that process.

After saving, send a normal follow-up so the next run starts with the new credential. The agent receives named environment variables and value-free metadata; it should not print the secret.

Storage and redaction

Credential values are encrypted by the Pazi API and are not stored in chat, Redis queues, ordinary database fields, workspace files, or runner output. Provider and encryption keys remain on the server.

Pazi treats secret credential fields as redaction targets when agent-influenced content leaves the runtime for web chat, Slack, email, logs, or callbacks. Non-secret metadata such as an account email, scope, or expiry can remain visible for context.

Redaction is defense in depth, not permission to ask an agent to echo a secret. Never test a connection by telling the agent to print the value.

Review and delete credentials

The selected agent's Integrations page shows available service connections without revealing values. Account → Saved Credentials shows service names, field names, and save dates for the selected business pool.

You can delete one credential, delete all credentials in the selected pool, or ask an owner-authorized agent to delete an exact credential record. Deletion affects future runs; it cannot remove a value already injected into a process that is still running.

After deletion, stop any active work that should no longer use the credential and start a fresh run when it is safe.

Slack credential forms

Slack can show a signed button and modal for a credential request. Values do not appear in the channel history, but the modal payload passes through Slack.

Use the Pazi web form instead when your policy requires secrets to be entered only on Pazi. Scheduled or unsupported conversations direct you back to a web conversation for secure entry.

Interactive website logins

A browser login and a saved API credential are different. When the agent asks you to sign in through Live View, enter the password directly on the verified website. Do not save the website password in chat, memory, files, or a skill.

Good credential hygiene

  1. Grant the narrowest service scope that completes the job.

  2. Use separate test and production credentials where the provider supports them.

  3. Review which agents share the business before saving a powerful credential.

  4. Rotate a credential after suspected exposure.

  5. Delete connections that are no longer needed.

  6. Require review before the agent performs irreversible external actions.