Permissions & security

An MCP-connected agent can never do more than you can, and usually should do far less. Access is the intersection of what you approved at connect time and what your role still allows right now, re-checked on every tool call.

Two boundaries, both enforced server-side

What an agent can do is bounded by two independent gates. A tool call must pass both:

1. The consent grant — the permissions you approved when you authorized the client. This is a ceiling you choose. Approve read-only, and every action tool disappears from the agent’s view.
2. Your live role permissions — your current access in the organization. If your role is reduced after you authorized the client, the agent’s access shrinks with it on the very next call. No re-consent, no stale permissions.

The effective permission set is the intersection of the two. Neither the client nor the agent can widen it — the checks run on iSearchFrom’s servers, not in the client.

Why this matters

This is the same least-privilege model the rest of the platform uses. Connecting an AI agent doesn’t create a new, broader kind of access — it’s a scoped-down view of your own account that you can tighten or cut off at will.

The consent screen

When a client connects for the first time, iSearchFrom opens a browser consent screen where you:

• Sign in as yourself.
• Choose the organization the client will act in. Every tool call happens inside that organization and spends its tokens.
• See exactly what’s requested and approve or cancel.

The client receives a token bound to that organization and grant. It reuses the token for later sessions until you revoke it.

The organization is locked at the database

The flexible query layer (describe_schema and query_sql) never touches the same database connection the app uses. It runs as a dedicated non-owner, read-only database role with row-level security that pins every query to your organization.

The query layer

Concretely, query_sql:

• Runs inside a read-only transaction — no writes, no schema changes, ever.
• Is bound to your organization via row-level security — it physically cannot return another organization’s rows.
• Can only read a curated set of columns on a curated set of tables. Sensitive tables (users, sessions, API keys, billing internals, raw scraped HTML) are never exposed.
• Is capped to 100 rows per query and has a short statement timeout, so an agent can’t run away with an expensive scan.
• Only sees tables you were granted read on — describe_schema advertises exactly that subset.

The result is a safe analytical window onto your own data. It’s powerful — the agent can answer novel questions with joins and aggregates — without being a security hole.

Token spend

MCP actions spend tokens identically to the app:

• Read tools are free — whoami, get_*, describe_schema, query_sql, options tools.
• run_proxy_search costs one token per requested page.
• trigger_*_run costs tokens per keyword or prompt checked.
• run_direct_search, create_*, update_*, delete_* are free.

Autonomous agents can spend in a loop

An agent that decides to run many searches will spend tokens for each one. Protect yourself:

• Grant the narrowest scope the task needs.
• Connect a client to an organization whose balance you’re comfortable exposing.
• Have the agent call get_token_balance before batches, and bound its loops.
• Watch spend with get_token_transactions or the app’s token usage view.

Revoke a connection

You can cut off a client at any time — the agent loses access immediately on its next call.

• Revoke the client’s authorization from your account settings in the app (the connected-apps / MCP connections view), or
• Remove the server in the client itself (for example claude mcp remove isearchfrom), which stops it from calling — though revoking in iSearchFrom is the authoritative cut-off.

Revoking is the right move if you no longer use a client, suspect a machine is compromised, or want to re-authorize with a tighter scope.

Good practice

Least privilege

Grant only what the task needs. Read-only for analysis and reporting; add write scopes only when the agent genuinely needs to create or run campaigns.

One client, one purpose

Authorize separate clients for separate jobs so you can revoke one without disrupting the others.

Human-in-the-loop for writes

For autonomous agents, prefer read/search tools. Require a human to confirm before wrapping create, update, delete, or trigger tools into an unattended loop.

Mind the balance

Point agents at an organization with a sensible token balance, and monitor spend.

Related

Connect a clientThe authorization flow in detail.

Tool catalogWhat each permission unlocks.

Roles & permissionsHow organization roles define what you — and your agents — can do.