Sharing an Agent Externally

Let outsiders try the agent you’ve raised with a single link, exactly as it is right now. Anonymous visitors can use it without signing into UpServe — they land in a chat view and talk to your agent directly, while every dollar of LLM and tool usage is billed to your SU balance — never theirs. Publishing leaves your original agent unaffected.

The unit of sharing is a public version: a frozen, isolated copy of your agent at the moment you publish it. You can keep editing or even delete the original; the public version stays untouched.

At a glance

How source · public version · link relate

  [Source agent]                                      [Visitor]
   (still editable)                                    No UpServe account
        │
        │ Publish (frozen at this point in time)
        │
        ├─▶ Public version A ─┬─ Link 1 ─▶ /share/abc...  ─▶ Anonymous user
        │                     │
        │                     └─ Link 2 ─▶ /embed/xyz...  ─▶ iframe on your site
        │                          (collected fields / credit caps /
        │                           origin allowlist are per-link)
        │
        └─▶ Public version B ─┬─ Link 3 ─▶ /share/def...
                              └─ Link 4 ─▶ ...

   ※ Each public version runs in a separate sandbox — visitor activity never touches the source
   ※ Edits to the source do NOT propagate to existing public versions (update it or issue a new one)

Publishing status

Once you finish the review and click Create Public Version, a row is created immediately in pending state while the actual file copy runs in the background. Once the copy finishes the status changes to ready; if something goes wrong it becomes failed. You can watch the status update live in the UI. Links cannot be issued until the public version is ready.

What a public version captures (and what it doesn’t)

Publishing copies your agent into a separate, isolated sandbox at that moment. From that point on, the original and the public version evolve independently.

Captured

• Agent name, description, avatar, behavior instructions
• Enabled tool configuration
• The agent’s file system (memory and working folders) — only whitelisted paths are copied into a fresh sandbox

Not captured

• The original agent’s chat history
• Webhooks, schedules, multi-agent relationships
• The original agent’s SU balance or subscription

Memory exposure warning. Your agent’s file system may contain past conversation summaries, notes, and knowledge files that are personal or sensitive. Before publishing, use the review step to check the file list and leave out anything you don’t want to share externally. See “Pre-publish review” below for how it works.

Automatic refine suggestions. Sometimes you want to share the know-how in a memory file but not the personal details and proper nouns baked into it. The review assistant finds these files on its own and prepares a refined version — with personal data and proper nouns stripped out — ready for you to check and adjust on the review screen. The original file is not shared.

File content. Selecting a file on the review screen shows its content right away. You can inspect the content of text files within the whitelisted paths. Binary files are flagged as “binary” — their content is not shown.

Tools available in public sessions

Every visitor gets their own workspace. Each person who opens a public session is given a separate, isolated workspace. Files one visitor creates and anything they run stay invisible to other visitors and never reach the original agent. That is why a public copy can do more than read and reply — it can actually get work done.

The allowed set includes:

• Web search and HTTP requests
• Image generation
• File read, write, and edit; file share
• Code execution
• Skill execution (see the caveat below)
• Send card (structured UI responses)
• Memory recall, history search, source conversation reference

Skills run only when they need nothing of yours. A skill that requires a connected account (Google, Slack, and so on) or a saved key is refused automatically in a public session, and the agent carries on with whatever it can do without it. It will not ask the visitor to connect an account either.

Browser automation, desktop automation, skill search/install, canvas, schedule management, team collaboration, and use of saved credentials are blocked automatically. The ask-user capability is also auto-disabled in public sessions — instead of pausing for a reply, the agent addresses questions naturally within its text response. You can block additional tools per public version via the Additional tools to disable list at creation time.

Whatever a visitor makes disappears with their session. The isolated workspace is removed when that visitor’s session passes its retention window. To leave a visitor with something, the agent has to hand it over with file share.

Memory and history tools are never shown by name to visitors. Memory recall, history search, and source conversation reference run silently — visitors see only a generic category label such as “recall” rather than the specific tool name. All other permitted tools (web search, image generation, code execution, etc.) display their activity labels as usual.

Read-only reference to the original conversation. A public agent can reference original conversation content only within the scope the owner approved when publishing. That reference is frozen at the moment the version was created — nothing from subsequent conversations is included. Visitors cannot directly search or browse the original conversation through this mechanism.

External API calls. Any external API the source agent normally relies on does not carry over automatically. To let a public session use it too, set it up separately — see “External API access for public sessions” below.

Telling it how to behave in chat (the one exception to the freeze)

As explained above, a public version is frozen solid the moment it’s created — with one exception: how it treats visitors. Just tell your original agent, in a normal conversation, something like “answer visitors this way,” and from that point on — no republishing, no running Update — every conversation from then on follows it.

• Examples: “Keep answers short with customers,” “If someone asks about pricing, just point them to the quote page link.”
• The agent remembers this on its own and applies it in every conversation it has through a public version. There’s no separate screen to open or save button to click — telling it in chat is the save action.
• The Public Version management tab also carries a note about this: “Just tell your agent in chat how to handle the people you share it with — say something like ‘keep it short with customers’ and it applies right away, with nothing to share again.” The same note appears on web, iOS, and Android.

There’s one more thing that isn’t frozen besides this — external API access. Conversation content, which tools are on, and what’s actually written in memory files are still locked to publish time (or the last Update), exactly as described under “What a public version captures (and what it doesn’t).” External API access, though, was never captured per public version in the first place — it’s a separate setting that applies to the whole agent, so when the owner changes what’s approved, it takes effect immediately on every already-published public version with no republish needed. See “External API access for public sessions” below for details. In short, tone/how it addresses people and which external APIs it can reach both update live; what it knows and which tools are on still only change when you run Update.

Only what the owner says directly in chat counts. If a visitor tells the public version “from now on, answer like this,” that does not get picked up. The agent is built to treat only instructions it hears directly from its owner, in a conversation with the owner, as behavior instructions.

Pre-publish review

The first time you publish an agent, you first walk through a review step with a review assistant to decide what gets shared.

1. On the agent page, open the Public Version tab and click Create a new public version. The review assistant starts in a chat window. If you’re starting from the chat view, you can also open the same screen as a modal via the Share & Publish menu at the top → Share Externally. Tell it who this public copy is for and what it’s for, and it looks over the agent’s memory files and recent conversation to work out what belongs in it.
2. Once it’s done, the review screen opens. The file list is on the left; the content of whichever file you select is on the right.
   • Each file shows the assistant’s Include suggested / Exclude suggested label along with the reason for the call.
   • You can flip include/exclude yourself with the checkbox; if your choice differs from the recommendation, the label is highlighted.
   • Files with personal data or proper nouns are shown as a pre-refined version the assistant prepared. Click Edit to change the content right there, Compare with original to see exactly what’s different, and Reset to original if you’d rather undo your edit.
3. Once you’re happy with the selection, click Next to fill in the name, description, and first greeting, then finalize publishing. The first greeting is the opening message a visitor sees the moment they open the link — the review assistant pre-fills a default, and you can edit it. Leave it blank and visitors land on an empty chat with no greeting.

Anything that blocks publishing shows up on screen. If something risky remains, or a file is too large, you’ll see a “Some items must be resolved before sharing” notice pointing at the file, and publishing won’t go through until it’s fixed. This check runs on the server as well as in the browser, so nothing gets published while the notice is still showing. Fix the content or switch the file to excluded and you can continue.

You can also skip the assistant. On the review assistant screen, choose Create without the coach to jump straight to a simpler screen where you just pick include/exclude per file — no recommendations or automatic refining.

Reviews expire if you sit on them too long. If you leave a review open without finalizing it, it eventually expires — you’ll see a notice (“The review draft has expired — please restart the coach”) and publishing is blocked. Use the Start over button to restart the review assistant.

Creating a share link

1. Open the agent and go to the Public Version tab (/agents/<agent>/shared). From the chat view, you can also open the same management screen as a modal via the Share & Publish menu at the top (formerly named “Export”) → Share Externally.

   Note. Besides this shortcut, the Share & Publish menu also has an option to download the conversation you’re currently viewing as a Markdown or JSON file. That download is for the owner’s own private conversation — it’s a separate feature from the “share with outsiders” flow this page covers.

2. Accept the terms of service and privacy policy, then click Create a new public version.

   • You’ll go through the “Pre-publish review” step above to decide what to include.
   • There is a maximum package size, so exclude large or sensitive files you don’t need.
   • Once you finish the review and confirm, the public version starts in pending state; it changes to ready once the copy completes.

3. Add a link to the public version. Each link has its own configuration:

   • Type: link (a standalone external page) or embed (iframe in your own site)
   • Collected fields: mark name / email / phone as required, optional, or hidden
   • Max SU per session (e.g. 500 SU)
   • Max SU per day (e.g. 5,000 SU)
   • Allowed origins (for embed links): the domains permitted to embed the iframe

4. Copy the generated URL and distribute it.

   • link type: https://upserve.app/share/<link_key>
   • embed type: https://upserve.app/embed/<link_key> — an embed snippet is offered alongside.

A single agent can have many public versions, and each can have many links. Splitting links by campaign or channel lets you track usage separately.

Connecting a KakaoTalk channel

If you already run a KakaoTalk channel, you can have this link’s public-version agent answer the messages that come in through it.

1. In the link’s settings screen, find Connect KakaoTalk channel and click Issue.
2. Two values appear: a skill server URL and a request header value. Enter them into the Create skill screen of the Kakao chatbot admin console (OpenBuilder).
3. Attach the skill you created to your scenario’s fallback block. From then on, messages coming through the channel are handed to this link’s agent, and its reply is sent back as a KakaoTalk chat bubble.

These two values are shown only on this screen, once. Once you close it, there’s no way to view them again — if you lose them, you’ll need to revoke the connection and issue a new one (which also means re-registering the skill in OpenBuilder). The screen tracks whether you’ve copied both values, so wait until that reminder is gone before closing.

The connection list shows how many requests have come in and when the last one arrived, so you can confirm the channel is actually reaching this agent. Connections you no longer need can be removed with the Revoke button.

Updating a public version

As you keep refining your agent, you’ll often want the content behind an already-shared public version to reflect the latest state. In the past that meant creating a brand-new one and reissuing links. Now you can refresh the content while every link you’ve already shared — standalone pages and embeds alike — keeps pointing at the same address.

1. Find the public version you want to refresh in the list and click Update.
2. A screen opens pre-filled with the name, description, files included in sharing, and tools blocked from sharing you set last time. If this public copy was built with the review assistant, the include/exclude choices from that review carry over automatically.
   • The file list works on an include-by-check basis: only checked files are published. Uncheck a file to leave it out of this version.
   • You won’t see every file laid out at once. The screen expands only files that changed on the source since your last publish, files that are new, or files that otherwise need a decision, and collapses everything whose decision hasn’t changed into an “Unchanged since last time” group — those keep their existing decision, so you don’t have to re-scan the whole list every time.
   • Files that are new on the source since your last publish are marked New and start unchecked (excluded), so content that has never been reviewed can’t go public without you noticing. Check the box to publish them.
   • Files whose content has changed on the source since your last review are marked Source changed. Opening one lets you click Compare with the published version to see just what’s different — no need to re-read the whole file. If this public copy was built with the review assistant, a notice appears with a Re-review with the coach button whenever there are new or changed files — click it and the review assistant re-examines those files and produces a new review. Check the summary, then click Update with this review to actually apply it.
   • Unless you check Keep the previous version’s conversation cutoff, the new version reflects the source agent’s conversation up to this exact moment.
3. If you don’t want to make the same call every time, turn it into a rule. The Rule button next to a file lets you set “always include/exclude this file” or “always include/exclude this whole folder.” Once set, that decision applies automatically from the next update onward — including to files created afterward — so you don’t have to re-decide the same path or folder each time. Rules can be reviewed and removed from a list at any time.
4. Click Update and wait while the new version is built. Once it’s ready, every link issued for this public version automatically switches over to the new version — you don’t need to touch any URL or embed code you’ve already shared.

The previous version isn’t gone. Expand the Previous version section in the list to see everything that’s been replaced, and if something’s wrong with the new version, click Roll back to point links back at the older one. Link addresses stay the same during rollback too.

Visitors who were already mid-conversation when the update goes live keep talking to the previous version without interruption; only visitors who arrive afterward land on the new one.

Previous versions are cleaned up automatically after 7 days. Rolling back only works within that window. If you want it gone sooner, you can delete it directly from the list.

Auto-update (optional)

If updating by hand each time is tedious, turn on auto-update in the edit screen. When enabled, a new version is created automatically on the interval you set (in days) whenever the original agent has changed, and your share links switch over — the link URLs stay the same. The list shows which public versions have auto-update on along with their interval, and if the original has changed since this version (a Differs from source state), you get a notification. Auto-update only runs when the original has actually changed; if nothing changed, no new version is created.

Auto-update only refreshes files you’ve already published. Files created since your last publish have never been reviewed by anyone, so auto-update leaves them out. An “always exclude” rule you set above still applies during auto-update, but an “always include” rule only takes effect the next time you run Update yourself — a safeguard against a never-reviewed new file quietly going public through auto-update. To publish new files anyway, open Update yourself and check them, or re-review them with the review assistant and confirm.

External API access for public sessions

External APIs your source agent normally relies on for day-to-day work (order lookups, internal system integrations, etc.) do not carry over to a public version automatically. Left as-is, those calls simply fail — silently — in a public session. Only for destinations the owner pre-approves here does the server attach stored credentials and send the request on the agent’s behalf.

Where to find it. On the agent page, the Public Version tab has a collapsed advanced section called External API access for public sessions. It’s a single setting for the whole screen, not per public version — whatever you approve here applies to every public version of this agent.

Broken calls are found automatically. Both the publishing screen and the management screen for an already-published version can show a pre-check card. It automatically finds external APIs the source agent actually uses that aren’t approved yet, and a single Allow click applies them. Applying it to an already-published version takes effect immediately — no need to republish. If there’s nothing to suggest, the card doesn’t appear, and skipping it never blocks publishing.

When the target is another webapp link you’ve published (little value in path-by-path control over your own app), the suggestion can bundle every read path into one Allow all read requests to this app entry instead of listing each one. Doing so includes reads the agent hasn’t even tried yet, and a notice reminds you that anyone holding the share link could trigger such a read. Write (mutating) requests are never covered by this broad option — they always require individual rules. Third-party targets you type a host in for are never offered this bundling.

You can also register access manually. Click Add access to set:

• Which stored credential to use (one of the values saved in Vault)
• The target: pick another webapp link you’ve published, or type in a host directly
• Allowed methods and paths — add as many rules as you need for fine-grained control (type in each method and path yourself). The “allow all read requests” bundling described above is offered only by the automatic suggestion — manual registration is always rule by rule.

Registered access can be removed rule by rule, so you can pull just the part you no longer need without canceling the whole thing (removing the last remaining rule does remove the access entry itself).

Requests can also come in mid-session. If a public agent talking to a visitor needs a call that isn’t approved yet, instead of just failing it can quietly ask the owner for approval. A request queue shows up on this same screen with the method, path, and target, plus the agent’s stated reason for asking (unverified, for reference only) — approve or deny each one. The credential name and any internal identifiers are never exposed to the visitor or the conversation.

Guardrails. Even for approved access, the plaintext credential is never exposed to the visitor, the conversation, or any log — it’s used internally only when the server attaches it to an outgoing request. Once a given access entry crosses its daily call limit (1,000 by default), further requests go out without credentials attached. Without any registered access, a public session cannot call external APIs that require authentication at all.

If a file you marked “always review myself” changes, auto-update skips that run entirely. In the update screen, the Rule button next to a file lets you mark that file — or its whole folder — as “always review myself”. When such a file changes, your share links keep serving the previous version, the update stops, and you get a notification. We don’t publish everything except that one file, because the agent’s memory files reference each other — dropping one leaves the others pointing at something that isn’t there, which can make the public copy behave oddly. When you get the notification, open Update, check the contents, and publish yourself. Once you do, auto-update resumes as normal.

link vs embed

Embed snippet

<iframe
  src="https://upserve.app/embed/<link_key>"
  style="width: 100%; height: 600px; border: 0; border-radius: 12px;"
  allow="clipboard-write"
></iframe>

For automatic height, listen on the parent for { type: 'resize', height } postMessage events and update iframe.style.height accordingly.

If your parent page already knows who the visitor is, you can post { type: 'user-context', data: { name, email, phone } } into the iframe to skip the entry form. The phone field is optional. This is only honored when the message originates from an allowed origin.

What the visitor sees

1. After opening the link, the visitor sees the agent’s name and description with an entry form.
2. They fill in name / email / phone according to the link’s collection policy.
3. They check the terms of service / privacy policy consent box — required before the session begins.
4. The chat view opens. If the owner set a first greeting, the conversation starts with it; otherwise it starts empty. Replies stream in real time.

A ‘Build your own’ link (optional). A “Powered by UpServe” mark appears at the bottom of the shared screen. If the owner turns on Show a ‘Build your own’ link to visitors in the link settings, that mark links to UpServe sign-up, giving visitors who liked the agent an entry point to build their own. It’s off by default and configured per link.

Cost and guardrails

Every LLM call and tool invocation in a shared session is billed to the owner’s SU. Visitors pay nothing. That makes the guardrails essential.

Both SU caps are optional. Leaving either the per-session or per-day cap blank means that check isn’t enforced at all — usage can run effectively unlimited until the owner’s overall SU balance runs out. Since these guardrails only work if they’re set, we recommend filling in both unless you have a specific reason not to.

Disabling or deleting a link immediately ends any active sessions on it. Visitors see the termination reason in the UI.

  [Visitor]                                       [Owner account]
   Anonymous                                       Credit balance
        │                                                ▲
        │ Send message                                   │
        ▼                                                │ debit
   ┌──────────────────────────┐                          │
   │  Public version sandbox  │ ── LLM / tool call ──────┘
   │  (isolated environment)  │
   └──────────────────────────┘
        │
        │ Guardrails (all must pass)
        ▼
   ┌────────────────────────────────────────────────────┐
   │  ⛔ Per-session cap exceeded → session blocked     │
   │  ⛔ Per-day cap exceeded     → new sessions denied │
   │  ⛔ Owner credits hit 0      → link auto-revoked   │
   │  ⛔ Owner disables manually  → sessions ended now  │
   └────────────────────────────────────────────────────┘

Operating and monitoring

The owner-facing dashboard at /agents/<agent>/shared exposes:

• Sessions: per-session visitor info, SU consumed, last activity, blocked state
• Message log: full transcripts per session (owner-only)
• Audit log: every link create / update / revoke / CSV export action
• CSV export: four files — sessions.csv (session list), messages.csv (message detail), usage.csv (SU usage aggregation), audit-logs.csv (audit log)

Using visitor feedback to improve. Once you have published at least one public version, the original agent gains access to an inbox of visitor transcripts from all its derived public versions. Use these to understand what questions visitors ask, where they get stuck, and what to improve in the next update.

Security and privacy

Sharing involves third-party personal data, so the following rules apply.

• Data controller: the owner is the data controller for visitor data. UpServe is the infrastructure processor.
• Collected fields: name / email / phone (when the visitor enters them), an anonymous session identifier, IP, User-Agent.
• Visitor session isolation: each visitor’s conversation is kept separate — conversations from one visitor do not carry over to any other visitor using the same shared link. Anything generated during a visitor’s session is not retained by the agent, so a later visitor cannot see what an earlier visitor discussed. The memory the owner set at publish time is what all visitors share, and it does not change based on visitor conversations.
• Session retention: sessions are automatically purged based on the owner’s plan — Free 3 days, Starter 14 days, Pro 90 days, Enterprise kept indefinitely (no automatic purge). Downgrading triggers a grace period before the shorter retention applies.
• Attachments: not retained on an independent timer — they are deleted together with their session once the session retention period above elapses.
• Transcripts: retained together with their session and automatically deleted once the session retention period above elapses (independent of deleting the public version itself).
• Application logs: 90 days.
• Audit log: retained indefinitely (for legal and security compliance).
• Visitor data deletion: the owner can delete the personal information (name, email, phone) for any individual session from the owner dashboard.

For the public-facing wording shown to visitors, see the Shared Agent Terms  and Shared Agent Privacy Policy .

FAQ

Q. If I update the original agent, do existing share links pick up the changes?

No. A public version is frozen at the moment it’s created. However, using Update from the list creates a new version from the source agent’s current state while your existing share link URLs stay the same. See “Updating a public version” above for details.

One exception: how it treats visitors. Tell it in chat and the next conversation follows it immediately, no Update required. See “Telling it how to behave in chat” above for details.

Q. Can a visitor permanently change my agent’s memory files or notes?

No. Visitor activity never touches the source agent. Beyond that, anything arising from one visitor’s conversation is not saved back to the agent, so a different visitor arriving via the same link cannot see what earlier visitors discussed. The memory you set at publish time is the same starting point every visitor gets, and visitor conversations do not alter it.

Q. Can the agent hand visitors a generated file or image?

Yes by default — file sharing and image generation are allowed, so visitors can download whatever the agent produces (there’s currently no way for a visitor to upload their own file, though). If cost containment is a concern, add these tools to the extra-disabled-tools list when publishing.

Q. Are password protection and expiry dates supported?

Not currently. To cut access immediately, disable or delete the link; to limit exposure over time, set per-session and per-day SU caps.

Q. Are there limits on how many public versions or links a single agent can have?

There are no hard product limits on counts. Each public version does provision its own sandbox, though, so prune ones you no longer use.

Learn more

• Equipping Tools — decide which tools to enable before sharing
• Skills & the Autonomous Skill System — review the skills your visitors will rely on
• Shared Agent Terms 
• Shared Agent Privacy Policy 

Advanced

You don’t need this for everyday use — it’s here if you want the exact mechanics of updating, rolling back, the pre-publish review, chat-based behavior instructions, and external API access.

How the review draft works

• A review the assistant saves is kept for 24 hours. If you don’t finalize publishing within that window, the review expires — you’ll see a notice on screen telling you to restart the assistant.
• Edits to the file list and file content on the review screen are saved automatically after a short pause, and the last edits are saved once more the moment you finalize publishing.
• Whether risky content remains, or a file is over the size limit, is checked by the server on every edit and again at the moment you finalize publishing. Even if the on-screen check is bypassed somehow, publishing is refused unless the server-side check passes too.
• A review that actually made it to publication is kept afterward so a future update to that public version can carry over its include/exclude choices. It’s cleaned up once the public version itself is deleted.
• If you choose Create without the coach, none of this review-draft or automatic-refining process runs — only the include/exclude you picked directly on the file list is applied.

How updating works

• Update doesn’t edit a public version in place — it builds an entirely new one from the source agent’s current state, then switches every existing link over to it in a single step. The previous version keeps serving traffic until that switch completes.
• Visitors who started a session before the switch stay on the version they connected to; only visitors arriving after the switch land on the new version.
• Once a public version becomes a “previous version,” a background cleanup job permanently deletes it — along with any lingering visitor sessions and its sandbox — exactly 7 days after it was replaced. Rolling back only works within that 7-day window.
• Rolling back doesn’t delete the newer version itself — it stays in the list, but from that moment it isn’t connected to any link. Reactivating it means issuing a new link (at a new address) or running Update on it again, and Update always rebuilds from the source agent’s current state — it doesn’t restore this version’s exact prior content.
• A public version whose source agent has been deleted can’t be refreshed — the Update button is disabled because there’s no longer a source to pull from.
• There’s no way to hand-edit the files inside a public version that’s already published, in place. To change what it contains, either update the source agent first and then run Update, or edit the file directly on the review screen while an update is in progress.
• The “changes only” diff on the update screen compares against the content of that file in the most recently published version, as its baseline. For refined files, comparing the refined content against the source’s current content takes priority instead.
• Include/exclude rules (per file or per folder) take priority over the screen’s default carry-over and recommendations, but on the auto-update path only exclude rules are applied automatically. Include rules only take effect when a person opens Update and confirms it themselves — a safeguard against a never-reviewed new file quietly going public through auto-update.

How chat-based behavior instructions apply internally

• Behavior instructions the owner leaves in chat are appended by the agent to a running list it keeps in one of its own files. That file is never copied into a public version’s sandbox; instead, on every visitor turn, the server reads the current content on the original agent’s side directly and folds it into that turn’s instructions. That’s what makes an edit the owner just made apply from the very next turn — including the next message of a visitor already mid-conversation — with no republish or Update involved.
• This file has a size cap — since it rides along on every visitor’s every turn, it’s set much smaller than a regular memory file (enough for a few dozen entries), and once it’s full, new writes are rejected so the agent has to trim it.
• If risky content shows up in it (fake role markers, hidden control characters, and the like), that whole block is silently dropped and never reaches the prompt — filtered automatically, the same as other safety checks, with no human review needed.
• If something goes wrong reading this channel (a transient lookup error, say), the turn itself doesn’t fail — it just proceeds without the behavior instructions. That’s the safe default here: this channel only shapes tone and emphasis, while the boundaries that actually matter (which files came along, which external APIs are reachable, whether the vault is closed) are always enforced separately, regardless of this channel.
• Because this file is never copied into a public version, the visitor-facing session has no file to write to in the first place — so there’s no path by which anything a visitor says could feed into these instructions.

How external API access works internally

• Registered access is stored as a combination of credential name + target (host, or a published webapp link) + allowed method/path rules. Only when a public session’s request matches that combination exactly does the server attach the stored credential and send it on the agent’s behalf — the plaintext credential is never delivered to the visitor session or the conversation through any path.
• The “allow all read requests to this app” bundle is something the server builds automatically, and only when the target is another webapp link you’ve published — it merges the read (GET) paths actually observed for that credential into one broad rule. There’s no such bundling option on the manual registration screen (each rule is added by hand there), and third-party host targets are never offered it. Write requests are never part of that merge and must always be registered as individual rules.
• If the agent in a public session attempts an unapproved call, that call is not executed — instead, a single approval request is created for the owner to review. The host, credential name, and similar fields on that request can never be supplied by the visitor directly; the server always fills them in from the source agent’s own existing set of valid access entries. There is no path by which a visitor session can register a brand-new host. To keep the queue from being spammed, there are also limits on how many requests can be pending at once and how soon the same request can be resubmitted after a denial.
• Once a given access entry crosses its daily call limit (1,000 by default), requests from that point on go out without credentials attached, and typically fail once the target API rejects the unauthenticated call.