# Your business on PUDL

Pool everything you and your agents need in one place: data, sources, tool connections, skills and workflows. Use PUDL through the website and a compatible remote MCP agent. You do not need to install PUDL or keep a computer running. You choose who has access and can end that access from the dashboard.

Start at [Your pools](/workspace) for your data, or [Your organizations](/orgs) to create or manage a business. A **pool** is a shared collection of information. A business's main pool is for its team; its sources pool holds connection descriptions and is available to owners and admins. Open the business to find **People**, **Pools**, **AI connections**, **Implementers**, **Activity**, and **Export and delete**. Direct owners manage online tools through **Hosted connections**. The retained **Legacy sources** and **Legacy gateway** pages are for existing customer-held deployments, not a setup requirement.

## Accept ownership

If an implementer set things up for you, open the ownership invitation they sent to your email address. Sign in with that same address; PUDL emails you a sign-in link. If the invitation has expired or the address is wrong, ask the implementer for a replacement.

Before choosing **Accept and become the owner**:

1. Check the business name and **Who has access**, including the implementer's role and any expiry date.
2. Under **Review people added during setup**, select each person whose displayed role should remain. The page shows member email addresses so you can identify them. Anyone left unchecked loses business access, including unused invitations they created and guest access they approved. If their role changes before acceptance, that access is removed too.
3. Review **Sources** and their destinations. If existing web approvals are shown, choose **Keep** or **Turn off** for each. Ask the implementer to explain anything you do not recognize. This review does not grant hosted key custody or agent tool permissions; you approve those separately after becoming the owner.
4. Decide whether to share receipt totals. The box starts ticked. These are counts of successful and unsuccessful source calls, shared only once at least three businesses report; they do not include the questions or answers. Change sharing later under **Pools → sources pool → Settings → Share receipt totals with other organizations' lookups → Save**.
5. Choose **Accept and become the owner**. The implementer remains an admin implementer until its grant expires or you revoke it. An existing active business gateway keeps working; ownership acceptance does not move or expose its credentials.

If you are starting yourself, choose **Create a business** on [Your organizations](/orgs). You become its owner immediately. On **People**, invite staff as **member** for team access, or **admin** if they need to manage sources and other settings. After handoff, direct owners and admins manage invitations and roles; an implementer cannot independently invite or promote people.

## Protect your sign-in

Open [Your account](/account) and add a passkey. Keeping one on a second device or security key makes it easier to recover if you lose your phone or laptop. Sensitive changes ask you to sign in again if your last confirmation was more than 15 minutes ago. Never share a sign-in link or passkey with an implementer.

## Connect your AI

Open [Connect PUDL](/connect) for the current connection instructions. The hosted endpoint is:

```
https://pudl.ai/mcp
```

Your existing agent client must support remote MCP over HTTP and PUDL's authorization flow. Provider plans and workspace policies can affect that support. An unsupported client does not become compatible merely because it has internet access; choose a supported integration rather than installing a PUDL background service. The [quickstart](/quickstart) describes discovery and permissions for agents.

On PUDL's consent page:

1. Check the return destination belongs to the client you opened. An app name alone does not establish who is asking.
2. Choose one workspace. A new scoped connection covers all the pools you can access there, now and later. **Limit access** lets you choose specific pools. Review what this client may do. Creating or joining pools requires a separate choice by an eligible direct owner or admin.
3. For connected tools, approve the requested connection-discovery and invocation permissions only when needed. The owner must also approve the exact agent, connection and tools. Reading a pool or accepting a shared workflow does not grant tool execution.
4. Finish connecting and give the agent a task, such as “Find the camera tutorial I saved from my phone.” It can search without knowing the pool name. When you ask it to save, it needs contribution permission and a writable destination.

Under **Connected agents** on [Your account](/account), check the workspace and pool coverage for each client. To narrow one, follow **Limit access** to replace that connection through the same client. For a fixed list, leave **Create private pools** and **Join pools** unchecked. **Disconnect** stops future PUDL requests from that connection.

## Connect a business tool and enter its keys

Where the host enables **Hosted connections**, PUDL can use an approved HTTP MCP source with a provider key you supply. BYOK means using your provider account and key; it does not require storing the key on a local computer. PUDL encrypts hosted credentials separately from pool records and never returns them to agents.

Only a **direct business owner** can store these keys and approve agent tool access, with a recent browser sign-in. An admin, implementer or agent cannot make those custody and spending decisions for you. In a personal workspace, its account holder has that authority.

1. Have your agent or implementer add the reviewed HTTP connection description to a private pool. It names the endpoint and required credential fields, without key values. Check the [library](/library) for published recipes; a draft or a named vendor is not proof of a working connection.
2. Open **Hosted connections** from your workspace or the business overview. Choose the exact connection version and enter its required keys in the private password fields, then choose **Store this connection's keys**. Use a restricted key from the intended provider account. Never paste keys into a pool or AI conversation.
3. Choose **Discover tools**. This reads the provider's catalogue; it does not execute a tool. Review the tool descriptions as information supplied by that provider, not as instructions you must follow.
4. Select an eligible agent and the exact tools it may use, then choose **Approve selected tools for this agent**. For a business this must be a direct member's agent with access to the connection's pool; for a personal workspace it must be your own agent. Start with reads.
5. Ask the agent to inspect connection readiness and perform one harmless read you can verify in the original service. If the host reports a disabled feature, missing credentials or missing approval, resolve that status before using it for business work.

Generic tools may change data, send messages or incur charges on your provider account. PUDL enforces tool permissions and request limits; the provider's own spending controls govern generic tool costs. PUDL's separately managed imports retain their own approved caps. Review provider limits before enabling chargeable tools.

Where **Connect GitHub with repository and tool permissions** is enabled, use that browser flow, select only the intended repositories and tools, and approve agents separately afterward. Installing the GitHub App means authorizing it on GitHub, not installing software on your computer. This dedicated GitHub flow does not imply that every vendor's OAuth sign-in is supported. Generic hosted connections currently use the supported keyed HTTP path; follow the actual host's capabilities.

Use **Revoke this agent permission** to end one agent's tool access, or **Revoke connection and agent permissions** to end the hosted connection. Ending PUDL access cannot undo completed provider actions or revoke independent credentials someone holds elsewhere.

## Share and adopt workflows

A shared workflow includes its instructions, context, skills, data and tool connection descriptions. Choose one of these two paths for its online tools:

1. **Use your own provider account.** Deliberately copy the reviewed HTTP connection description from the shared workflow into a private pool your workspace owns. Follow [Connect a business tool and enter its keys](#connect-a-business-tool-and-enter-its-keys): the direct owner supplies their keys privately, discovers the tools and approves the intended agent. Copying the description does not copy credentials or approvals.
2. **Use an explicitly shared provider account.** Where hosted guest permissions are enabled, the connection owner opens their workspace's **Share hosted tools with an exact guest agent** link. The connection must already have discovered tools in a member-visible shared pool. Enter the recipient agent's exact public DID from **Agent access**, never its secret key. Its workspace must already have guest access to that pool, and the agent must have scoped tool-use permission and access to the pool. Review the exact agent and connection, select tools and a 1-, 7- or 30-day expiry, and approve provider-account spending. The recipient then opens [Hosted tool permissions](/account/hosted-permissions), reviews the offer and chooses **Accept for my agent**. Both people use their own recently confirmed browser sessions. The agent stays in its existing workspace; the owner's provider credentials remain private.

Either party can revoke the shared tool permission. This is access for the exact approved agent and tools, not blanket cross-workspace access. A shared pool, copied record or pending offer alone never grants execution, and sharing a workflow never copies secret values.

Agents decide how to execute the workflow. They can also coordinate through ordinary pool records: one posts a request, another reads it when available and posts a result referencing that request. A request is data, not permission to run a command or spend money. An offline participant responds only after it reconnects. PUDL does not require a local bridge for this pattern.

## End an implementer's access

Open **Implementers**, find the firm, and choose **Revoke**. Read the cleanup page and confirm with **Revoke now**. Its access ends on the next request, and PUDL removes the guest access it introduced. Use **Activity** to review actions by that implementer or person.

Review **People**, **AI connections** and **Hosted connections** for access that should end. Rotate provider credentials the implementer may have seen and revoke independent authorizations at the provider when appropriate. A PUDL revocation cannot erase a copied secret. If you retain an existing gateway, also follow the legacy cleanup guidance below.

To retain help with a different role or expiry, revoke the existing grant, then invite the firm again on **Implementers** using its code or email address and your new choices. The implementer must accept the new invitation on its dashboard.

## Export your business's data

Only an owner can export. Open **Export and delete → Make an export** and confirm your sign-in if asked. The download link works once, lasts 24 hours, and is emailed to you. Save the ZIP somewhere your business controls and open its `README.txt`.

The export contains the records and files held on PUDL, pool settings, people, implementers, sources, AI connections and activity. It excludes passwords, keys and tokens. Data still held only in a vendor's service needs that vendor's export; a source connection does not copy that entire service into PUDL.

## Delete the organization

Make and save an export first if you want to keep the data. On **Export and delete**, type the organization's name and choose **Delete this organization**. Everyone's access ends immediately, and PUDL emails the people and implementers involved.

The operator can restore the removed pools' bodies on request within 14 days; after that the bodies and their held files are purged under the host's retention rules. Restoration does not silently reactivate revoked memberships, grants, gateways, sign-ins or invitations. Signed headers, the deletion record and activity remain, and material under a legal hold follows its separate retention rules. Contact the operator promptly if deletion was a mistake. Records written into another organization's pools remain there.

Revoke connected-app authorizations and unused keys at each provider. Deleting the PUDL organization does not cancel vendor accounts or erase files already downloaded elsewhere.

## Existing gateways: legacy reference

Existing customer-held gateways remain compatible; this guide does not migrate them, change custody or revoke them. They are outside the hosted product's supported launch setup. A gateway must remain running to serve its tools, unlike an installation-free hosted connection.

If your business already uses one, **Gateway** shows its operator and status. On **Sources**, legacy **Seal and send to [gateway name]** fields encrypt a key in your browser for that named gateway; PUDL relays it without reading it. Its vendor sign-in tokens stay on that gateway. Confirm who controls it before entering keys. Legacy executable sources need terminal approval; the [implementer reference](/implementer-playbook#4-add-and-approve-sources) includes approval and lock recovery.

A replacement enrolled by an implementer after handoff waits for owner approval. An active gateway can keep working after an implementer is revoked. If that firm controls the machine, revoke the gateway before entering replacement keys; its operator must stop the retired container, delete its stored volume and handle its backups under your retention policy. Rotate provider credentials it could read. Deleting a PUDL business does not stop a separately hosted gateway or erase its disk. Make any custody migration a separate reviewed action; do not silently copy keys into hosted storage.