Public beta preview — you're seeing the sneak peek

Permission boundaries

read as .md

Guuey runs many builders’ apps for many users on shared infrastructure. This page counts the guarantees that keep them apart across three boundaries: your app and the platform, one app and another, and one user and another inside the same app.

A guarantee is counted here only when it is enforced on this version of Guuey: Guuey’s code makes the check, and an automated test covers that check. A guarantee that is still being built, or is not yet live on this version, is not counted. Those join this page as each one ships.

The rows group related things, for example everything about an app’s billing. The columns are who is asking: a guest using an app without signing in, a signed-in user of an app, or a builder acting through the console, the CLI or an API key. The last column names the kinds of check that enforce that row. An empty cell means this version lists no enforced guarantee for that pairing.

For how the runtime, network and credentials are built, see Security & isolation and The identity model.

Your app and the platform

What an app, or the builder behind it, can reach of Guuey’s own platform.

More guarantees join this page as each one ships.

No-code apps

	A signed-in user	A builder	Enforced by
Platform credentials and tokens		3 enforced	server-side check
Secrets and keys your app holds		4 enforced	server-side check, cloud IAM, key sealing (KMS)
Runtime and network	1 enforced		server-side check

Platform credentials and tokens

A builder: A personal access token that is revoked or expired, or a key issued through an OAuth sign-in that is past its maximum session length, is refused with the same response. The response does not say which case applies.
A builder: A revoked service token and an unknown one get the same refusal, so the response does not say whether the token ever existed.
A builder: A workspace key that is revoked or unknown gets the same refusal as a refused personal access token, and the response does not say which case applies.

Secrets and keys your app holds

A builder: A builder’s pre-registered OAuth client secret is unlocked only for that app and server, and is used only with the server and authorization server it was registered for.
A builder: During sign-in, an app’s bring-your-own OIDC client secret is unlocked only for that same app.
A builder: The app secret your backend uses to mint user tokens is shown once, and Guuey keeps only a one-way hash of it.
A builder: When a hosted MCP server is called, Guuey decrypts that server’s own secrets and passes them to that server. A caller cannot supply its own, and a failed decryption stops the call without revealing a secret.

Runtime and network

A signed-in user: A signed-in user can check public MCP endpoints within an hourly allowance. Private network targets are refused with the same answer as an unreachable server.

Code-mode apps

Being measured. Guuey is checking this boundary for code-mode apps now, so no count is shown yet. The runtime boundary in Security & isolation applies to code-mode apps today.

One app and another

What one builder or workspace can reach of another’s apps, secrets, data and money.

More guarantees join this page as each one ships.

No-code apps

	A signed-in user	A builder	Enforced by
Platform credentials and tokens		13 enforced	server-side check
Secrets and keys your app holds	1 enforced	10 enforced	data API authorization, server-side check
Connected accounts		2 enforced	server-side check
Conversations and user data		8 enforced	server-side check
Apps, deploys and ownership	1 enforced	15 enforced	data API authorization, server-side check
Workspaces and roles		1 enforced	server-side check
MCP servers you host	1 enforced	12 enforced	data API authorization, server-side check
Billing, wallet and spend	2 enforced	68 enforced	data API authorization, server-side check
Logs		1 enforced	server-side check

Platform credentials and tokens

A builder: A read-only personal access token reaches only the actions Guuey marks as safe for read-only use. Some reads that can expose secrets, such as logs and the values of your app’s environment variables, need a full-access token, and so does any action Guuey does not recognize.
A builder: A service token can be created only by a personal app’s owner, and not for a workspace app. It is shown once, and Guuey stores a one-way hash of it, not the token itself.
A builder: A service token can be revoked only through its own app, by someone with write access to that app. A token that belongs to another app looks like it does not exist.
A builder: A service token can only reconcile, roll back and read deployments. Guuey refuses every other request it makes.
A builder: A service token never works on a workspace-owned app, even for the person who minted the token, so an app’s service tokens stop working once the app moves into a workspace.
A builder: A workspace key is for CI on its own workspace’s apps. Guuey refuses it wherever a person must act, including app creation and deletion, widget keys, domains, conversation transcripts and hosted MCP servers.
A builder: An app’s service token works only on its own app, and only while that app is personal. It stops working once the app moves into a workspace.
A builder: Any active member of a workspace, viewer and up, can list its keys without seeing their stored hashes. Anyone outside the workspace is refused before any of its keys are read.
A builder: Guuey refuses a workspace key when the owner or admin who holds the key is no longer an active owner or admin of that workspace, even if nobody has revoked the key.
A builder: Only an active owner or admin of a workspace can create a workspace key. Its secret is shown once and Guuey stores a one-way hash, not the secret itself.
A builder: Only an admin or owner of a workspace can create or revoke its API keys, viewers and above can list them without seeing the secret, and another workspace’s keys stay out of reach.
A builder: Only an owner or admin of a workspace can revoke its keys, and only keys that belong to that workspace. Another workspace’s key looks like it does not exist.
A builder: When a key holder is removed from a workspace, leaves it, or is demoted below admin, Guuey revokes the keys they hold for that workspace. Erasing their account deletes those keys.

Secrets and keys your app holds

A signed-in user: No signed-in builder or end user can read or change stored provider keys, hosted MCP secrets or pre-registered OAuth client secrets directly.
A builder: A member, admin or owner of the workspace that owns a hosted MCP server can list its secrets by name only. The list returns neither a secret’s value nor its encrypted form.
A builder: A saved provider key is always filed under its app’s own owner and workspace, taken from the app and not from the request. Guuey stores the key encrypted, and what it shows back, such as the provider, a short prefix and the key’s status, never includes the full key.
A builder: A workspace member with read-only access to an app sees its configuration without the OIDC client secret or the webhook secret, only whether an OIDC client secret is set.
A builder: Active members, admins and owners of a hosted MCP server’s workspace can list its secret names, but viewers cannot. Listing, setting or removing a secret never returns its value.
A builder: An app’s signing keys and the app secret your backend uses to mint user tokens are created, rotated or revoked only by the app’s personal owner or an owner or admin of its workspace. Members and viewers are refused, and strangers see no app.
A builder: Guuey accepts a pre-registered OAuth client secret when you save it and never shows it back. Later reads only confirm that a secret is on file.
A builder: Managing hosted MCP servers, including setting their secrets, needs a signed-in person. A workspace API key is refused.
A builder: Only a personal app’s owner, or an active owner or admin of the app’s workspace, can set or remove its model provider keys. Other active workspace members, viewers included, can see which keys are set, and strangers or anyone removed from the workspace, even the app’s creator, are refused.
A builder: Only an active admin or owner of the workspace that owns a hosted MCP server can set or remove its secrets. Members, viewers and outsiders are refused before anything changes.
A builder: Only an admin or owner of the workspace that owns a hosted MCP server can set or remove its secrets, and a member of that workspace is refused.

Connected accounts

A builder: A builder with read access to an app sees counts, times and the latest error for end users’ connected accounts, never who connected, their connection handles or their tokens.
A builder: An app’s pre-registered OAuth client secret is stored sealed, and Guuey never shows it back.

Conversations and user data

A builder: A builder who does not own a personal app, or who is not or is no longer a member of a workspace app’s workspace, cannot list or open that app’s sessions, and opening a session under one app never returns another app’s session.
A builder: A builder without an active membership in the app’s workspace, including one who was removed, suspended or only invited, reads none of its conversations.
A builder: A personal access token needs full access to use the admin operations on end users’ stored MCP server data. A read-only token is refused.
A builder: An app’s declared access to user profiles changes only through an accepted deploy, and deploying needs write access to the app.
A builder: Only a viewer or higher in a workspace can read its audit history, and what they see is limited to that workspace’s own entries.
A builder: Only its owner can read a personal app’s conversations through Guuey’s builder tools. Anyone else is refused without learning whether a conversation exists.
A builder: Only the workspace that owns a hosted MCP server can manage its end users’ stored state. Members and above can list it, admins and owners can export or wipe it, and using the server in an app grants none of this.
A builder: Opening a conversation through one app never returns a conversation that belongs to a different app. It is treated as if it does not exist.

Apps, deploys and ownership

A signed-in user: Guests cannot read an app’s private settings. A signed-in end user can read them directly only if the app is recorded under their own account, as its owner or its creator.
A builder: A builder cannot name their own personal workspace as the destination of an app transfer.
A builder: A builder who is not an active member of a workspace, including one only invited, cannot create an app in it and gets the same not-found answer as for a workspace that does not exist.
A builder: A new app is created only through the platform’s own app-creation steps, never by a direct write from any user.
A builder: A new workspace’s short name must be well formed, not reserved and not already taken. An account that has created 20 workspaces, counting its personal workspace, cannot create another.
A builder: A personal access token or console session acts with the holder’s current workspace membership. Someone who is not, or is no longer, a member of a workspace cannot open or change its apps.
A builder: A transfer out of a workspace can be accepted only while the person who started it is still an admin or owner of that workspace. Otherwise the acceptance is refused.
A builder: A workspace API key acts only on apps its own workspace owns. For another workspace’s app or any personal app, it gets a not-found answer.
A builder: A workspace key reaches only its own workspace’s apps. Personal apps and other workspaces’ apps look exactly like apps that do not exist.
A builder: An app moves into a workspace only when an active admin or owner of that workspace accepts the transfer.
A builder: An app transfer that has not been accepted can be cancelled only from the sending side, by the app’s personal owner or an active admin or owner of the sending workspace.
A builder: Any signed-in builder with a free app slot can create a personal app, and the new app starts out owned by that builder alone, not by another account or a workspace.
A builder: No other builder can read or change your personal app. Membership in a workspace gives no access to it.
A builder: Only an app’s personal owner, or an active admin or owner of the workspace that owns it, can start a transfer of that app. Having created a workspace app grants no such right.
A builder: The Guuey console shows a workspace app’s settings only to active members of its workspace. Members who cannot edit the app do not see its webhook secret or its stored sign-in client secret.
A builder: When an app moves into a workspace, its original creator stays recorded as its creator only if they are an active member of that workspace.

Workspaces and roles

A builder: Each account’s personal workspace is tied to that account’s verified sign-in, and Guuey confirms the workspace belongs to that account before handing it over.

MCP servers you host

A signed-in user: Any signed-in user, builder or end user, can browse the platform’s catalog of MCP servers, and it never lists a server owned by a workspace.
A builder: A builder who was removed or suspended from a workspace, or only invited to it, cannot manage or view its hosted MCP servers, even if they once owned it.
A builder: A hosted MCP server owned by another workspace gets the same not-found answer as one that does not exist. Someone outside a workspace is refused before any of its servers’ details are read.
A builder: A hosted MCP server’s deployment status is readable only by a member or above of the workspace that owns it.
A builder: A workspace API key, which has no person behind it, is refused on every request to manage or browse hosted MCP servers before the platform acts on it.
A builder: No builder or end user can read the stored records of MCP servers, their tools, deployments or secrets directly, for any workspace.
A builder: Only a member or above of a workspace can list which catalog MCP servers that workspace has turned on.
A builder: Only an active member, admin or owner of a workspace can list its hosted MCP servers. A viewer, a non-member or a removed member cannot.
A builder: Only an admin or owner of the app’s workspace, or a personal app’s owner, can refresh an app’s tools, and only for hosted MCP servers the app has been granted.
A builder: Only an admin or owner of the owning workspace can delete a hosted MCP server or check its deletion. Another workspace’s server gets the same not-found answer as one that does not exist.
A builder: Starting an MCP server build needs an admin or owner of the workspace, and the build reads only source uploaded under that workspace and that server.
A builder: Tool definitions of a workspace’s own hosted MCP server are readable only by that workspace’s members, admins and owners. Those of a platform catalog server are readable by a member, admin or owner of any workspace.
A builder: Uploading MCP server source needs an admin or owner of the workspace, and the upload lands only under that workspace and a server it owns or a fresh one.

Billing, wallet and spend

A signed-in user: A signed-in user outside a workspace, such as an end user of its apps, cannot add, remove or see its apps’ provider keys or read their monthly usage.
A signed-in user: An end user outside a workspace cannot delete that workspace’s apps from the CLI or end their plans that way.
A builder: A builder who does not own a personal app cannot change its plan, see its billing or add credit for it, whatever workspace roles they hold.
A builder: A paid top-up credits only the wallet it was bought for, and only when that wallet’s own Stripe customer made the payment.
A builder: A read-only personal access token cannot make billing changes such as a top-up, a new plan, an auto-recharge change or using a trial slot.
A builder: A role in one workspace, from viewer to owner, gives no access to the provider keys or usage export of another workspace’s apps.
A builder: A workspace API key can change the pod limit, scaling and memory reservation of its own workspace’s apps, while an app service token or a read-only personal access token cannot.
A builder: A workspace API key can export usage only for apps in its own workspace, and an app service token cannot export usage at all.
A builder: A workspace API key cannot view an app’s Design evolution setting, and a read-only personal access token cannot change it.
A builder: A workspace API key cannot view billing or invoices, start a plan, buy credits or use a trial slot through the CLI or API. An app service token cannot start a plan, buy credits or use a trial slot.
A builder: A workspace API key or a read-only personal access token cannot deploy a hosted MCP server.
A builder: A workspace API key stops spending from the workspace wallet once the owner or admin who holds it leaves the workspace or drops below admin.
A builder: A workspace API key, an app service token or a read-only personal access token cannot delete an app from the CLI or end its plan that way.
A builder: A workspace admin can start or cancel a transfer of one of the workspace’s apps, and can accept an app transferred into the workspace.
A builder: A workspace admin invited into another person’s personal workspace cannot see whether that person’s personal apps are on a plan Guuey assigned or not billed.
A builder: A workspace member cannot cancel or resume the workspace’s MCP hosting subscription.
A builder: A workspace member cannot change a workspace app’s pod budget, the monthly amount set for its extra pod time, even for an app they created.
A builder: A workspace member cannot change a workspace app’s spending cap or whether it is a hard or soft cap, even for an app they created.
A builder: A workspace member cannot choose or remove the plan Guuey assigns to a workspace app, even one they created.
A builder: A workspace member cannot lift a pod cap Guuey placed on a workspace app or change that app’s spending cap.
A builder: A workspace member cannot read the credit movements of that workspace’s wallet.
A builder: A workspace member cannot start a transfer of one of the workspace’s apps or accept an app transferred into the workspace. Both need the admin role or higher.
A builder: A workspace member or viewer, even one who created the app, and a creator no longer in the workspace cannot delete a workspace app from the CLI.
A builder: A workspace member, admin or owner can see the status, number of hosted units and billing period of the workspace’s MCP hosting subscription.
A builder: A workspace owner can start or cancel a transfer of one of the workspace’s apps, and can accept an app transferred into the workspace.
A builder: A workspace owner or admin can cancel the workspace’s MCP hosting subscription at period end, and automatic hosted unit updates do not reverse that cancellation.
A builder: A workspace owner or admin can see when a workspace app is on a plan Guuey assigned or is marked Not billed, but cannot choose which plan Guuey assigns.
A builder: A workspace owner or admin cannot choose the plan Guuey assigns to an app, or remove a plan Guuey assigned to that app itself.
A builder: A workspace owner or admin cannot lift a pod cap Guuey placed on an app, and cannot set a spending cap above the plan default on an app marked Not billed.
A builder: A workspace viewer cannot cancel or resume the workspace’s MCP hosting subscription.
A builder: A workspace viewer cannot read the credit movements of that workspace’s wallet.
A builder: A workspace viewer cannot see the status of the workspace’s MCP hosting subscription.
A builder: A workspace viewer cannot start a transfer of one of the workspace’s apps or accept an app transferred into the workspace. Both need the admin role or higher.
A builder: Active members of the workspace that owns an app, viewers included, can see its provider keys only as provider, key prefix, status and dates, never the full key.
A builder: An admin of another workspace cannot delete this workspace’s app from the CLI or end its plan that way.
A builder: An admin of another workspace cannot delete this workspace’s app in the console or end its plan that way.
A builder: An app cannot write past its included storage plus what its own spending cap still covers this month, and a failed billing check keeps it at the included storage.
A builder: An app service token is refused on workspace apps, even for the person who created it. On its own personal app it cannot choose a plan or buy credits.
A builder: An app’s Design evolution usage is recorded against that app alone.
A builder: An app’s generations, including any High effort charge, are counted only on that app’s own monthly usage.
A builder: An app’s managed model usage is counted only on that app’s own monthly usage.
A builder: An app’s pod time is counted only on that app’s own monthly usage, and no other app’s pods count toward it.
A builder: An app’s storage is measured from that app’s own files alone and counted only in that app’s own usage.
A builder: Apart from Guuey operators, no one outside a workspace, including a member of another workspace at any role, can change the plan Guuey assigned to its apps or their limits, see whether Guuey assigned their plan, or transfer them out.
A builder: Console billing requests for plans, wallets and credits are refused when no account is signed in.
A builder: Even an owner of one workspace cannot see another workspace’s Billing page, open its Stripe customer portal, or start a paid plan there through checkout or the CLI.
A builder: In the console, only an owner or admin of the owning workspace can delete a workspace app, and deleting it ends that app’s plan at once.
A builder: MCP hosting checkout for a workspace can only use the one-time first-month credit of the account that owns the workspace, whoever starts the checkout.
A builder: Membership in another workspace, or a workspace API key issued for it, gives no way to change the pod limit, scaling or memory reservation of this workspace’s apps.
A builder: No customer account but a personal app’s owner, not even an admin invited into the owner’s personal workspace, can see, start, cancel or resume that app’s plan.
A builder: Of the workspace roles, only owner and admin can change a workspace app’s pod limit, scaling or memory reservation, whether or not they created the app.
A builder: On a workspace app, the console’s Usage page shows usage figures only to an owner or admin of that workspace.
A builder: Only a workspace owner or admin can add or remove a workspace app’s provider key, and a member cannot, even on an app they created.
A builder: Only a workspace owner or admin can change the workspace wallet’s auto-recharge settings from the CLI, and no role in another workspace reaches them.
A builder: Only a workspace owner or admin can deploy a hosted MCP server, so a workspace member cannot add a hosted server to the workspace’s hosting subscription.
A builder: Only a workspace owner or admin can see the workspace wallet’s credit balance, card on file, invoices and next invoice preview on the workspace’s Billing page.
A builder: Only a workspace owner or admin can start a paid plan for the workspace’s apps, through checkout in the console or from the CLI, including apps another member created, and the plan bills the workspace’s wallet.
A builder: Only an active member of a team workspace at or above its role for creating apps, admin by default, can create an app in it, billed to its wallet, and anyone else is told the workspace does not exist.
A builder: Only its owner can delete a personal app from the CLI, so no other account can end that app’s plan that way.
A builder: Only its owner can delete a personal app in the console, so no other account, whatever its workspace roles, can end that app’s plan there.
A builder: Only the account that owns a personal app can add, remove or list its provider keys, and no workspace role reaches them.
A builder: Only the owner of a personal app can change its pod limit, scaling or memory reservation.
A builder: Restoring a deleted app does not bring back the paid plan that ended with the deletion. To put the app on a paid plan again, choose one.
A builder: The console’s Usage page shows a workspace owner or admin the generation counts of the workspace apps they created.
A builder: When a workspace owner or admin, or a personal app’s owner, deletes an app from the CLI, its plan ends at once or the deletion fails.
A builder: When an app is transferred, the new owner’s wallet and roles govern its plan from the same moment the app changes hands.
A builder: With a hard cap, Design evolution’s new designs past an app’s included count are counted at their price only while the app’s spending cap has room. A design that would pass the cap is recorded at no charge.
A builder: With a hard cap, a new managed model turn on an app is refused before it starts once the app’s usage past its plan’s included credit goes beyond its own spending cap. An app whose included credit and spending cap are both $0 can draw only on the one-time trial credit of the workspace that pays for it, if that workspace has one.
A builder: With a hard cap, an app running extra copies of its pod is scaled back to one pod once the month’s extra pod spend reaches the app’s pod budget, the monthly amount you set for its extra pod time.
A builder: With a hard cap, once an app has used its included generations and what its own spending cap can still buy this month, new requests to the app are refused before the agent runs.

Logs

A builder: A builder who may not read an app cannot read its runtime logs, and a read-only personal access token cannot read them either.

Code-mode apps

	A guest	A signed-in user	A builder	Enforced by
Secrets and keys your app holds			3 enforced	data API authorization, server-side check, key sealing (KMS)
Billing, wallet and spend			12 enforced	data API authorization, server-side check

Secrets and keys your app holds

A builder: A read-only access token can neither read an app’s plain configuration values nor change any of its secrets.
A builder: Any active member of an app’s workspace, viewers included, can list the names of the secrets set for the app. Listing or saving those secrets never returns their values.
A builder: The secrets you set for an app are encrypted for that app alone and are unlocked only for that same app when it deploys. A secret that uses a model provider’s reserved key name is never injected.

Billing, wallet and spend

A builder: An app service token cannot start a code-mode build, whether as a new deploy or as a rollback.
A builder: As on a no-code app, a workspace member with the member role cannot change a code-mode workspace app’s pod limit. A workspace API key from another workspace cannot read the app’s pod settings.
A builder: High effort cannot be turned on for a code-mode app, a refused attempt changes nothing, and code mode never blocks turning it off.
A builder: On a code-mode app with a hard cap, Design evolution’s new designs past the included count are counted at their price only while the app’s own spending cap has room. A design that would pass the cap is recorded at no charge.
A builder: On a code-mode app with a hard cap, a new managed model turn is refused before it starts once the app’s usage past its plan’s included credit reaches its own spending cap. An app whose included credit and spending cap are both $0 can draw only on the one-time trial credit of the workspace that pays for it, if that workspace has one.
A builder: On a code-mode app, Design evolution usage is counted only toward that app’s own monthly usage.
A builder: On a code-mode app, generations are counted only toward that app’s own monthly usage.
A builder: On a code-mode app, managed model usage is counted only toward that app’s own monthly usage.
A builder: On a code-mode app, once the app reaches its monthly generation limit, a new generation request is refused before it starts.
A builder: On a code-mode app, pod time is counted only toward that app’s own monthly usage, and no other app’s pods count toward it.
A builder: On a code-mode app, storage is measured from that app’s own files alone and counted only toward that app’s own monthly usage.
A builder: On a code-mode app, writes cannot pass the included storage plus what the app’s own spending cap still covers, and a failed billing check holds them to the included storage.

One user and another, inside an app

What one person can reach of another person’s data inside the same app.

More guarantees join this page as each one ships.

No-code apps

	A guest	A signed-in user	A builder	Enforced by
Platform credentials and tokens		1 enforced	1 enforced	server-side check
Secrets and keys your app holds		1 enforced	1 enforced	server-side check
Connected accounts		1 enforced		server-side check
Conversations and user data	2 enforced	9 enforced	4 enforced	data API authorization, server-side check
Apps, deploys and ownership			8 enforced	server-side check
Workspaces and roles		1 enforced	4 enforced	server-side check

Platform credentials and tokens

A signed-in user: A signed-in user’s browser session renews only while it is still active, unrevoked and unexpired, and its stored renewal credential works for that one session alone.
A builder: A member who leaves, is removed or drops below admin loses their workspace API keys, and a member who leaves or is removed is no longer listed as creator of the workspace’s apps.

Secrets and keys your app holds

A signed-in user: A signed-in end user who is neither the app’s owner nor a member of its workspace cannot reach a builder’s provider keys or the names of an app’s secrets.
A builder: The app secret your backend uses to mint user tokens works for its own app only, and every token request refused at authentication gets the same response.

Connected accounts

A signed-in user: A signed-in user can link only their own Guuey account to another account. When another signed-in user tries to remove that link, Guuey answers as if it did not exist.

Conversations and user data

A guest: A guest, or an app without read-write access to the user’s profile, cannot write to any profile.
A guest: When a guest’s threads are merged into a signed-in account, the platform takes the guest’s identity only from the guest’s own session credential, never from the request’s content.
A signed-in user: A conversation you had as a guest joins your account when you sign in only if your device proves it holds that guest’s secret. Naming a guest is never enough.
A signed-in user: A guest’s thread moves to a signed-in user only while that guest still owns it, so a thread an earlier sign-in already took never moves to a later one.
A signed-in user: A signed-in user can request erasure of, and check erasure progress for, only their own memory in an app, never another user’s.
A signed-in user: An agent saves what it remembers about you only under your own verified identity, and a save redirected toward another user’s memory is refused and leaves theirs untouched.
A signed-in user: Being signed in never lets one user read or change another user’s profile.
A signed-in user: From a signed-in account, only the user can list or change the grants that share their profile with an app. The app’s owner can neither list them nor create one for another user.
A signed-in user: The platform records profile consent only from a verified signed-in user, takes a one-conversation grant only from that conversation’s owner, and always records the level the app declared.
A signed-in user: When an agent saves to a signed-in user’s profile, the platform writes only to that user’s own section for that app, never to another user’s profile or another app’s section.
A signed-in user: When the platform recalls profile details into a conversation, it reads only the signed-in user’s own profile, only with that user’s grant, and only as far as the app declares.
A builder: Each page of end-user conversations served to an app’s builders is logged on a best-effort basis. The log records how many were read, never their content.
A builder: Exporting or wiping end users’ stored MCP server data needs an admin or owner of the workspace it belongs to, and a viewer cannot reach that data. Each completed export is recorded.
A builder: For a workspace app, the only builders who can read its end users’ conversations are active owners and admins of the app’s workspace. Members and viewers of the workspace cannot.
A builder: Reading conversation transcripts takes a person’s own sign-in or personal access token with management access. Workspace keys, service tokens and read-only personal access tokens are refused.

Apps, deploys and ownership

A builder: A signed-in person can deploy or undeploy an app only if it is their personal app, they are an active admin or owner of its workspace, or they created it and hold an active member role or higher there. Guuey refuses to deploy an archived app.
A builder: A team app’s creator who is removed from, only invited to, or suspended in its workspace gets no access to that app through the Guuey CLI or the CLI API for having created it.
A builder: Every active member of a workspace, viewers included, can read its team apps. Members who cannot edit an app do not see its webhook secret or its stored sign-in client secret.
A builder: Only the owner of a personal app, or an active admin or owner of the app’s workspace, can archive it. Creating a team app does not by itself give the right to archive it.
A builder: Only the owner of a personal app, or an active admin or owner of the app’s workspace, can publish or unpublish the app’s marketplace listing.
A builder: Restoring an archived app takes the same standing as archiving it: the owner of a personal app, or an active admin or owner of the app’s workspace.
A builder: Through the Guuey CLI and the CLI API, a signed-in member can change a team app only if they are an active owner or admin of its workspace, or its creator while they hold an active member role or higher there.
A builder: When a member is removed from a workspace or leaves it, Guuey also clears them as the recorded creator of that workspace’s team apps, before it deletes their membership.

Workspaces and roles

A signed-in user: A workspace invitation can be accepted only while it is still outstanding. Accepting is refused for a user who already holds an active or suspended membership in that workspace.
A builder: Any active member of a workspace can leave it by removing their own membership, unless they are its last active owner.
A builder: Leaving, demoting or removing a workspace’s last active owner is refused.
A builder: Removing another member from a workspace requires being an active admin or owner of that workspace, and so does removing your own suspended membership.
A builder: Someone removed from a workspace, or whose membership there is only invited or suspended, holds no role in it and is refused every action that requires a workspace role.

Code-mode apps

	A guest	A signed-in user	A builder	Enforced by
Billing, wallet and spend	1 enforced			server-side check

Billing, wallet and spend

A guest: On a code-mode app, each guest is held to the same daily message limit per guest as on a no-code app.