Data & administration
Roles & security
Who can do what in your workspace, how hosted content is protected, and the audit trail underneath it all.
The four roles
Every seat in a workspace has one of four roles. In plain terms:
| Role | Who it's for | In short |
|---|---|---|
| Owner | The workspace owner. | Everything, including the few decisions that can't be delegated. |
| Admin | A trusted teammate helping run the workspace. | Manages content, projects, squads, seats, exports, and the audit view — nearly everything an owner can do. |
| Runner | A teammate (or CI agent) whose job is executing rounds. | Runs rounds and reads what's needed to run them — but doesn't edit personas, scenarios, or workspace settings. |
| Viewer | Someone who reads results — an advisor, a stakeholder. | Sees content and the ledger. Changes nothing, runs nothing, and never touches credentials. |
A SQUAT platform operator is not a fifth workspace role. Inside a customer workspace, the highest ordinary role is owner; platform status does not silently add anyone to the workspace or grant access to protected customer content. Support access requires the owner's separate, explicit authorization.
A license key or connector pass carries its assigned workspace role. People who share an owner credential share owner authority. Give each teammate a separate, least-privilege credential and revoke it when their access should end.
Capability by capability:
| Can they… | Owner | Admin | Runner | Viewer |
|---|---|---|---|---|
| View personas, scenarios, results, the ledger | Yes | Yes | Yes | Yes |
| Export the workspace | Yes | Yes | No | No |
| Run rounds | Yes | Yes | Yes | — |
| Create/edit personas, scenarios, projects, squads | Yes | Yes | — | — |
| Inspect/manage raw persona sources, permissions, communication ranges, and auditions | Yes | Yes | — | — |
| Use compiled provenance-excluding runtime personas | Yes | Yes | Yes | — |
| Manage seats, keys, and billing; view the audit log | Yes | Yes | — | — |
| Authorize purpose-bound SQUAT support access | Yes | — | — | — |
| Set issue dispositions | Yes | Yes | — | — |
| Delete rounds, restore from trash, purge | Yes | Yes | — | — |
| Prepare and execute deletion requests | Yes | Yes | — | — |
| Authorize a deletion request or activate retention | Yes | — | — | — |
UAT login secrets are not stored in SQUAT. Scenarios contain only non-secret authentication policy and readiness attestations; the operator prepares the browser session outside SQUAT.
What's protected, and what remains readable
SQUAT protects customer-content fields and hosted artifact-library files automatically inside the authenticated service. Clients do not perform a separate workspace-key setup.
The line SQUAT draws is your intellectual property. Everything your research produces or describes — what you are building, who you tested it with, what they said, and what you concluded — is encrypted, and we do not exercise discretion about which parts of it look sensitive enough to deserve it. What stays readable is the operational record needed to run your account and compute your ledger: who holds which seat, roles and statuses, machine-generated identifiers, timestamps, and counts. That set is deliberately small, and none of it describes your product or your findings.
| Protected content role-restricted | Operational metadata needed for the ledger to work |
|---|---|
|
|
Put plainly: SQUAT can process the protected content an authorized role requests, while ordinary ledger queries use the operational metadata. Protected bodies are not copied into indexes, cards, audit rows, or broad list views. Reads return only role-appropriate content.
Provenance-excluding role bundles
Raw source governance is owner/admin material. SQUAT-generated runtime and role bundles omit source identity, basis, permission evidence, raw samples, operator commentary, real/synthetic labels, and cross-role fields. Evaluators receive scoring material without provenance until scoring is complete. The authenticated coordinator chooses which structurally separated bundle to request, and SQUAT records that choice. It cannot identify a downstream model context, stop the coordinator from merging responses, or attest that an external model host isolated the contexts. Clients remain responsible for separate subagents or model calls. Legacy rounds without a validated runtime-artifact pin are labeled legacy-unverified.
Withdrawing a source sets it ineligible for future compilation and blocks every dependent communication range and actor briefing. Historical round pins remain append-only. Withdrawal is not a claim of retroactive deletion; legally required erasure is a separate lifecycle.
The persona record retains its acquisition/source-basis note. Performance-role bundles omit that provenance so it cannot shape the performance.
When you explicitly authorize support
A workspace owner can deliberately grant temporary, purpose-bound administrative support access for a named case. The grant names the exact protected fields, purpose, and duration. It contains no encryption key material, and an admin cannot approve it on the owner's behalf.
Letting SQUAT support look at specific records
When a support case needs eyes on your actual data — say, one persona profile that won't load — you stay in control the whole way. The flow:
- Support names the case and the exact records in the ticket — which records, which fields, and why.
- You tell your AI assistant, in plain language, to grant it — for example, “Grant SQUAT support access to that persona's profile for case 4821, for two hours.” Only the workspace owner can create the grant.
- The server returns a grant ID — a safe, non-secret reference to your authorization. It is not a password or key, and it unlocks nothing on its own.
- You paste the grant ID into the ticket. Because it's non-secret, that's safe.
- Support's audited identity can read only those exact fields, only for that case, until the grant expires — anywhere from 15 minutes to 7 days, your choice.
- You watch and end it. Ask for the grant's status anytime, revoke it the moment the case is done — or simply let it expire.
Nothing in this flow involves sharing a password, license key, or any other secret. You authorize; the service does the rest inside its own protected boundary. Anyone who asks you for a credential “so support can take a look” is not following SQUAT's process — see Troubleshooting.
This flow is the only way anyone outside your workspace can ever be granted access to protected content — and it opens solely by the owner's explicit, case-bound, time-limited action. There is no standing support backdoor to misuse, because none exists.
Grant creation, status reads, support use, and revocation are all audited. The service refuses a target that changed after authorization or falls outside the grant. Revoking the authorization prevents later use, but it cannot erase information already legitimately viewed during the authorized case. Grant access only for the minimum scope and time you are comfortable with.
The audit trail
Key system operations leave an audit record — who acted, through which client, what action and target were involved, when it happened, and the outcome. Customer content itself is not copied into the audit row. Important stored-data changes commit their audit record with the change; actions involving external files keep resumable progress records so an interrupted operation can be reconciled. Append-only panel-reaction corrections and Research Report invalidations are included in that audit trail.
Owners and admins can review the audit log anytime — recent entries, filterable by operation.
Seats and access
Every human account license ships with at least one seat — when your key is issued, your account, seat, and assigned license are bound together. SQUAT checks that binding when you use account sign-in and applies the lower of the seat and license roles. The seat also carries your message state. Hosted content protection is automatic after authorization.
Adding a teammate, step by step
Add the seat. On the Seats page of your account at www.squat.pro, add a seat for your teammate by their SQUAT account email. Your plan sets how many seats the workspace holds — see the tier table in Setup & connection. If that email already has a SQUAT account, the seat is created and bound to them on the spot. If it doesn't, SQUAT emails them — but today the seat is not created automatically when they sign up: once their account exists, add them again and it completes immediately. A self-completing invitation, where signing up finishes the seat on its own, is planned.
Choose the role. Owner, admin, runner, or viewer — the four roles above. Least privilege is the habit that pays off: viewer for a stakeholder who reads results, runner for a person or automation whose job is executing rounds, admin only for someone helping run the workspace.
Your teammate signs in. They connect their own AI client with their own account sign-in (see Signing in from a connector). No license key is required — the seat's credential is their verified sign-in, and their role applies from the first request.
Optionally, attach a key. If they need a license key — for an agent or CI connection, or a client that connects by key — attach one to their existing seat from the Seats page. The key belongs to the seat: it does not consume a second seat, and the raw value is shown exactly once, at attach time.
Mind the device slots. Each key works on up to three active devices. The Devices page of the account shows and de-registers them, and a device pack expands the budget when a team outgrows it.
Seats and keys can carry a friendly name — “CI key”, “Dana's laptop” — set and renamed anytime on the Seats page, so two keys are never just two prefixes.
When access must end, two moves do different jobs. Revoking a key cuts off that key's devices and connections but keeps the person's seat and their signed-in access — the right move for a leaked or retired key; attach a replacement afterwards. Revoking the seat removes the person: every credential and session tied to that seat stops working. A workspace can never lose its last owner this way — that removal is refused until another owner seat exists. And one plain caveat in either case: removal prevents future authorized access, but it cannot erase content someone already exported or copied while authorized.
Signing in from a connector
When an account-enabled SQUAT catalog offers connector sign-in, you sign in with your verified account in the browser and the connector receives a short-lived pass. Current direct-license clients can still enter the license key on SQUAT's own sign-in page. In either route, the credential does not enter the AI conversation.
Your license key authorizes access; it is not the key that encrypts your workspace data. SQUAT cannot reconstruct a lost raw license key, but your operator can issue a replacement and revoke the old credential without deleting or re-encrypting the workspace. If a key may have been exposed, issue and verify its replacement, then revoke the exposed key.
- Passes expire and rotate. The one the app uses day to day is good for about an hour; a longer-lived renewal pass issues the next one and is itself replaced every time it's used. Nothing sits around indefinitely.
- Disconnecting cuts access immediately. Remove the connector and its passes are revoked on the spot — nothing to wait out.
- A revoked key kills every pass made from it. Rotate or cancel your license key and every app that signed in with it stops working on its very next request. One action, everywhere at once.
- A pass can never outrank current authority. SQUAT re-checks the license on every request; an account pass also re-checks the user and seat and uses the lower seat/license role.
Signing in establishes the workspace and role used for every request. Hosted content protection is automatic; there is no second client-key setup step.
How SQUAT addresses you
SQUAT greets you by your preferred name in email — set it to whatever you'd like to be called (a first name or a nickname) and account messages use it in place of your full name. You can set or change it two ways: on your account profile page on the SQUAT site, or from an MCP session by asking your AI to update your profile (the update_profile tool, which only ever changes your own account). It takes effect for future email; leave it blank to fall back to your account name.
Your data, your methodology line
One boundary runs through everything: your data is always yours — persona profiles, scenarios, transcripts, results, learnings, intents, the whole ledger. Owners/admins can export it anytime, free at every tier; ordinary runner/viewer reads stay narrower than a bulk extract. SQUAT's testing methodology — the served interview structures, evaluation instructions, and scoring internals your AI fetches while operating — is licensed content and stays confidential; your AI will politely decline to print it. Describing what it does (as this manual does) is fine; reproducing its text is not.
Retention, portability, and deletion
SQUAT's retention posture is simple: portability plus deletion. Owner/admin portable and full-backup exports are free at every tier; security control-plane material never travels (see Maintenance). You can request deletion for an exact resource or participant data registered in the workspace index. SQUAT inventories and rechecks the authorized scope, runs its own safety checks, and leaves a content-free completion certificate. Broader account or workspace deletion is not executed from a partial inventory. Authorized operators retain the workspace export path.