> This is Payabli documentation. For a complete page index, fetch https://docs.payabli.com/llms.txt — append .md to any page URL for lightweight markdown. For section-level indexes, query parameters, and other AI-optimized access methods, see https://docs.payabli.com/ai-agents.md

# Amigo boundaries and guardrails

> Understand what Amigo can access, what it won't do, and the controls partners have over it

Before using Amigo™, you'll want to know what it can see, what it can't, and what happens to that data. Amigo's access follows the same boundaries already built into the Payabli Portal. It can reason over your business data, but specific protections keep individual-level and payment-credential data out of reach.

## What Amigo can see

Amigo access is controlled by organization-level enablement and user roles with the `amigo_read` permission. To access data through Amigo, a user must have organization-level user role scope: Amigo doesn't support paypoint-scoped access. See [User Roles overview](/guides/pay-ops-roles-permissions-overview#access-scope) for an explanation of how user roles function in Payabli.

That means Amigo access follows your role's organization scope, not a flat all-or-nothing grant. If you have a flat organization hierarchy, users can query any paypoint's data. If a user's role is scoped only to a sub-organization, they can use Amigo to query paypoints within that sub-organization, but not the parent organization.

Business-level data, like transaction volume or paypoint details, is available to query. Individual-level contact data and payment credentials aren't, no matter how a question is phrased.

Amigo also receives context about the page you're on for the conversation you're having: its type and route. If the page is scoped to a specific organization or paypoint, that context also includes the record's name.

This page context is separate from Amigo's access scope. At the start of a conversation, Amigo receives only a list of the organization IDs you have access to, not their names, hierarchy, or paypoint list. It resolves organization and paypoint names, and re-checks access, on demand as you ask questions, whether page context already surfaced a name.

## What Amigo can't access

Amigo won't return certain categories of data, no matter how a question is phrased. This protects your business and your customers: sensitive data doesn't surface in a response, even by accident.

* **Payment credentials**: card numbers, account and routing numbers, CVV, and expiration dates.
* **Personal contact data**: an individual's personal email, phone number, home address, or date of birth.
* **Credentials and secrets**: passwords, API keys, and similar access credentials.
* **Tax identifiers**: Social Security numbers, EINs, and similar tax IDs.

These exclusions are enforced in Amigo's underlying data access layer, not only through its instructions, so they hold regardless of how a question is phrased or reworded.

### Business contacts and individual contacts

Amigo's redaction boundary depends on entity type as well as data type. A business entity, like a paypoint or organization, returns its own business phone number, email, and address. Amigo still refuses to name an individual owner or contact tied to that entity, even though it just returned the business's own contact details.

For example, asking for a paypoint's business contact information returns fields like phone, email, address, website, and status. Asking a follow-up about a specific owner or individual contact gets refused. Amigo explains that individual contact names, personal phone numbers, and personal email addresses aren't surfaced for privacy reasons. It suggests checking the boarding application or using the business's general phone number instead.

## What Amigo won't do

Beyond specific data categories, Amigo has behavioral boundaries that apply regardless of what you ask.

Amigo surfaces analytics and answers questions. It doesn't take actions or change your configuration, so it can't approve a boarding application, issue a refund, or update an organization's settings.

Amigo also can't act on what's on your screen. Page context tells it the type of page you're on and, if applicable, the name of the record you're viewing — not the data displayed there. Pointing it at something visible doesn't give it access beyond what your role and Amigo's access scope already allow.

The same access model applies here: anything Amigo returns stays scoped to your own organizations, never blended with another partner's data.

## Admin controls

Admins control who can use Amigo on a per-user basis, using roles and permissions.

**Per-person restriction** depends on the `amigo_read` permission. Certain built-in roles include it by default (Admin, Manager). Contact your Payabli representative to confirm which ones apply to your organization. Within an enabled organization, an admin can also build a custom role that leaves it out to remove a specific person's access.

## Related resources

See these related resources to help you get the most out of Payabli.

* **[Amigo Chat overview](/guides/platform-amigo-overview)** - Understand how Amigo works before evaluating its boundaries and guardrails

- **[User roles overview](/guides/pay-ops-roles-permissions-overview)** - Explains how user roles and organization scope work in Payabli

* **[Use Amigo Chat to generate insights and analytics](/guides/platform-portal-amigo-use)** - Learn how to open Amigo, ask questions, and revisit past conversations in the Payabli Portal