Security & privacy.
The connection is built to give an assistant the least it needs and nothing more — scoped tokens, tenant isolation, and a publish path that can't go live on its own.
A connection to your ScoutRival account is powerful, so it's designed to hand out as little authority as the job needs. Tokens are stored as a one-way hash, every request is resolved back to the account behind it, and the one action that could go public — publishing — can't be triggered without a human. This page walks through each safeguard.
How tokens are stored
When you create a connection token, ScoutRival keeps only a one-way hash of it — a scrambled fingerprint, not the token itself. That's why the token is shown once, at creation, and can't be recovered afterwards: neither we nor anyone who reached our storage can read it back. Tokens travel over HTTPS in the Authorization header, never in a URL. Revoking a token takes effect immediately, so a device you no longer trust loses access at once.
If you connect by signing in instead — the OAuth path used by claude.ai on the web and ChatGPT — no password and no long-lived secret is ever handed to the assistant at all. It receives a scoped token issued after you sign in, and that token obeys every rule below.
Least privilege by design
Every connection has an access level, and that level is the ceiling on what it can do. The default is Read-only — it can read your data but spend nothing and change nothing. You raise it to Content or Full only when you need those tools, and no further.
- Scope to specific brands. A token can be limited to one or more of your brands, so a connection made for one client can't touch another.
- Set a daily credit cap. Any token can carry a daily ceiling on how many credits it may spend, so a runaway loop can't drain your balance.
See scopes and access levels for what each level unlocks, and create and manage tokens for the settings themselves.
Tenant isolation
Every request is resolved to the owner behind the token before it does anything. The brand it acts on is then validated against the brands that owner actually has and against the token's own brand scope — the brand is never taken on trust from the request. A connection can't reach another account's data, or a brand it wasn't scoped to, simply by naming it in the call. The check happens on our side, on every request, not in the assistant.
Draft-only publishing
The one tool that could put something in public — publish_to_wordpress — always creates a draft, never a live post. The assistant can prepare the article, format it and file it in your WordPress; a person then reviews it and presses publish. This is a hard rule in the connection, not a setting you could flip off, so no automated loop can put a post live on its own.
Your competitive data stays yours
The set of domains you track is exactly the kind of information a rival would love to see, so we don't leak it for convenience. ScoutRival doesn't send your tracked domains to third-party logo or favicon services — a common leak in this category — because we sell privacy and won't trade your competitive set to save a request. And when a tool fetches a URL you supply, that fetch is checked so the connection can't be pointed at a private or internal address inside our network.
What you can do
- One token per device. Give each machine its own token so you can revoke one without disturbing the others.
- Keep everyday connections Read-only. Raise the level only on the connection that needs to generate or run something.
- Cap the spenders. Put a daily credit cap on any Content or Full token so its spend can't surprise you.
- Revoke anything you're unsure about. It's free and it's instant — there's no cost to being cautious.
A Viewer teammate's connection is always read-only, whatever level was chosen — the token can never grant more than the person behind it already has.
A read-only, brand-scoped token can look but not spend and not change anything. It's the right default for a shared machine or a new client — you can raise the level later on a token you trust.