Hosted runs¶

A QuickAgent runs on your own machine with the CLI or the desktop app. A hosted run runs it on Agentry's infrastructure instead: you give it a task, it runs in a sandbox we operate, and the output comes back to the page. It is metered in credits from your subscription tier, and it runs the QuickAgent in autonomous mode — one task in, a result out, no back-and-forth. On Pro and on an organization's tier, a release that declares the interactive mode can also run as a hosted session, a conversation on the run's page (below).

Hosted runs are for trying a published QuickAgent without installing anything. What runs is the exact release the registry scanned and signed; the run reads no files of yours and reaches no network except what the release declares.

A hosted run always uses Agentry's own model access. A ChatGPT, Claude or Copilot plan you signed in with, or an OpenRouter, Poe or Hugging Face account you connected, pays for runs on your own computer only (plans, connected accounts).

Every run's model reads the System Prompt first, before the QuickAgent's own instruction, the same text a run on your own machine gets. Its fixed opening says the run is in a locked sandbox, that attached knowledge comes first, and that the model stays on the task the instruction gives. The rest states only what the release declares: its network, its files, its commands, its secrets by name and its tools. The text is shown word for word in Running them.

Run in Agentry¶

Every published QuickAgent's page carries Run in Agentry for a signed-in account. It opens the run setup, a few short steps, one at a time:

Before you start says what the QuickAgent does, what to have ready (the files it asks for, the questions it will ask, a sentence about the task), what a run holds in credits and how long it may take, and, behind a disclosure, everything the release declares it may reach. Where the author wrote a guide in the manifest, its overview and its list of what to gather are shown instead of the ones the site works out, and its line about files and its example task appear on the steps that ask for them. Where you may also talk to it, the next step, Run it or talk to it, asks which: Run it works on your task on its own, Talk to it starts a hosted session.
Files takes the files the task is about. Drop them in or choose them, remove any you picked by mistake, and go on with none if the task needs none. The limits are shown before you reach them.
Knowledge appears when you keep knowledge packs in Agentry. It lists each pack with its pages, its size and its scan state, and you tick the ones the run should have, up to five. A pack being scanned, or one whose scan could not read it, is listed but cannot be ticked yet, and says why. The run can search and read the packs you tick, and cannot change them, and the System Prompt tells it to look in them before its own knowledge. Each pack is at /knowledge/<name> inside the run, read-only, and the run's receipt names each one it was given, with its digest. Attaching a pack of your own asks for no new consent: handing it to the run is the grant, as it is for your files.
Connect tools appears when the release declares MCP servers. It lists each one with the tools it may use and where it may connect. A server that needs a key declares it by name, and the Secrets step asks for it. A server that works with your own account at its vendor, such as Linear or Gmail, has Connect instead, and the step comes second, straight after Before you start, so connecting loses nothing you typed (below).
Secrets appears when the release, or one of its MCP servers, declares a secret you do not keep in Agentry. It asks for each value, with Keep it for later runs unticked (below). A secret you already keep is used as it is and not asked for.
Details asks the release's own questions, where a question that wants a file offers the files you picked, and then what the run should do. For a session it asks for your first message instead, which you may leave empty: the agent then opens the conversation.
Review and start repeats every answer, each with an Edit link back to its step, and Start the run creates it. For a session the button is Start session. Where you have a live Writing Voice, it also shows Write in my voice, ticked from your Profile's switch: a ticked run is given your voice and told to write anything meant for a person in it, and you can untick it for this run. On Pro, Promo Pro and an organization's plan, When offers Later and Repeat beside Now, and the button becomes Schedule (Scheduled runs).

Back keeps what you entered, and a step that is missing an answer says so before it lets you go on. The run is created against that exact version, a block of credits is held, and you land on the run's page while it waits for a sandbox host to take it. Nothing is uploaded until you press Start, so a setup you leave halfway sends nothing.

A release that supports only interactive mode says Talk to it in Agentry on its page where you may start a session, and goes straight through the setup with no mode step. On Standard, or where the registry is not taking sessions, the page says so and has no button: run it with the CLI or the desktop app.

Two more ways in reach the same setup and the same run:

From Installed. Every row of Installed QuickAgents you can still open carries Run in Agentry, which opens that QuickAgent's run setup. The setup is the one place a run is configured; the row is a way to it from what you keep. It runs the newest published release, which the setup names in its heading, and a release that cannot run says why there.
Re-run. A run that finished, was cancelled or failed carries Re-run on its page. It starts a new run of the same release with the same task and the same intake answers, under your account's current caps, and opens the new run's page. Input files are not carried over: they are the earlier run's artefacts, not a set kept to upload again, so a run that needs them starts from the setup. The knowledge packs it attached are attached again, as they are now, and a run given your Writing Voice writes in it again, as it is live now. A re-run holds credits and is refused for any of the reasons a first run is — among them one run at a time, a balance short of the hold, a version no longer published, a secret the release declares that you no longer keep, and a pack that is no longer yours or is being scanned. A secret you entered for the earlier run without keeping it was removed when that run ended, so start again from the setup, which asks for it. A session is re-run as a session.

Which files work¶

The Files step takes up to 20 files, 10 MB in total. Before the QuickAgent starts, the sandbox host opens each one in a container with no network, checks it for malware and turns it into text where it can, so the agent reads what you gave it whatever its kind (Running with files has every detail).

Documents: PDF; Word (DOCX and the older DOC); Excel (XLSX) and OpenDocument spreadsheets, read as tables, and older XLS files, read as text; PowerPoint and OpenDocument slides; RTF; EPUB.
Email: Outlook messages (MSG), EML files and mbox mailboxes.
Images: PNG, JPEG, TIFF and the other common kinds. The agent gets the text in the picture, read by OCR, not the picture itself.
Code and data: source code, scripts, HTML, XML, CSV, JSON, YAML, logs and plain text reach the agent exactly as you uploaded them.
Archives: zip, tar, 7z and rar, and gzip, bzip2, xz or zstd files, are unpacked, and each file inside is read by its path, such as bundle.zip/notes/memo.docx. Up to three archives deep and 2,000 files in all. An encrypted archive, or a file inside one, cannot be checked, so it is not read.

A file is read by what it is, not by its name, so a renamed document still works. A file the host cannot read, such as a program or a database, is listed to the agent as not read, with the reason, and the agent can still read its raw bytes. The page of a QuickAgent that wants particular files says so in the Files step.

Every file is checked, and every file inside an archive:

ClamAV, an open-source malware scanner, checks each one on the sandbox host against signatures that are refreshed daily.
Hybrid Analysis (CrowdStrike) is asked about the riskier kinds (programs, scripts, macro and older Office files, RTF, PDF and a few more) by their fingerprint, the SHA-256. The file itself, its name and your account are never sent.
AI Review reads the text of each file for instructions aimed at the QuickAgent, on the sandbox hosts that carry it.

A file ClamAV finds, or one Hybrid Analysis calls malicious, stops the run before the QuickAgent starts, and the run's page says it was refused before it ran; your credits come back in full. A file AI Review flags stops it too, and costs AI Review's one credit. The page does not yet say which file it was. For a run that went ahead, the receipt names what each check found: how many files were clean, and any it could not check.

Runs that read a repository or a web address¶

Some QuickAgents ask for a source instead of a file: a code repository (a repository question) or one file on the web (a url question). You give its address in the Details step, and the sandbox host fetches it when the run starts. Nothing is uploaded through this site.

A repository is its https address, such as https://github.com/owner/repository. If you want something other than the default branch, give a branch, a tag or a full commit in the field beside it. The host checks out that one commit, without its history, links or submodules.
A file at a web address is its https address. It is read the way an uploaded file is: a PDF's text, a web page as Markdown.
The address must be https, name a plain host, carry no name or password, and use no port but 443. A repository's address carries no query and no # part. The setup checks this before you start.

A private source takes an access token, in the field beside its address:

It is used for this run alone. Agentry holds it until the run ends, then deletes it, and it is never part of the run's answers or its receipt.
Only the host's fetch reads it; the QuickAgent never sees it.
Give one that can only read what the run needs. On GitHub, that is a fine-grained token with read access to that repository's contents.
It is not kept for later unless you tick Save this token in Agentry for its host. Re-run of a run that used a token typed for it does not start: start it again from its setup and give the token there.

A key saved for a host is a token Agentry keeps for every address on that host, such as github.com. Save one under Settings → Encrypted storage → Keys for input sources, or tick the box beside the token in the setup.

A run you start with no token for a source uses the key saved for its host, and the setup says when one will be.
A schedule always uses the saved key, because a scheduled run carries no token of its own. To schedule a private source, save its token for the host first, or tick the box when you schedule. With no key saved, a scheduled run fetches its source without a token.
The key goes only to the fetch of an address on that host, and the QuickAgent never sees it. The page shows when it was saved and last used, never its value. Delete it there, and a run already queued to use it stops before it starts, with its credits returned; later runs fetch without it.
On your own machine, the CLI and the desktop app can keep a token for a host in your system's keychain (running QuickAgents).

What is checked before the QuickAgent starts:

The size. A repository is at most 10,000 files and 256 MiB; a file at an address at most 10 MiB, the upload limit. A source over its limit stops the run before it starts, and your credits come back. The run's page says which source and how far over the limit it was.
AI Review reads a repository's Markdown files (its README, CONTRIBUTING and other .md pages), where an instruction aimed at the QuickAgent most often hides. It does not read the repository's code. A file at an address is read whole, as an upload is. A repository with more Markdown than AI Review reads in one run is refused, with the count. A flagged file stops the run and costs AI Review's one credit.
Malware. Programs, other binaries, PDFs and Office files in a repository are checked as uploaded files are. Its images are not read as text.

The run's receipt says what was fetched: the commit, how many files and bytes, whether a token was used, and how many Markdown files AI Review read.

A server you name: not in Agentry¶

A QuickAgent that declares a target host, a server you name when the run starts and that the agent works over SSH, runs on your own computer only. Its page and its run setup say so in place of Run in Agentry, and point to Agentry Desktop and the CLI, which ask for the server and your sign-in to it when the run starts.

A browser¶

A QuickAgent that declares a browser, for testing a website, runs in Agentry with public sites only: the run setup asks for each site as an address, on port 80 or 443, and a site on your own network is refused before the run starts. One that asks for any public website does not run here. A run with a browser takes twice the room of another on a sandbox host. The rest is on In Agentry.

Queued, running, done¶

Your runs (/runs) lists what you have run, newest first, with each run's state. A new run is queued until a sandbox host takes it, then running, then done with a pass or a fail. A pass is a run that finished its task; a fail says which way it ended, such as a harness that failed, a cap it reached, a cancel, or the platform failing it. While a run is queued or running, your dashboard names it, with its place in the queue, and links to it. While the run is in flight, the top of its page shows which of the three it is at, with its place in the queue or how long it has been running, and the page updates itself every few seconds until the run is done. Then the same place shows how it ended and what it produced (below).

A hosted run keeps no log. The sandbox host runs the QuickAgent, keeps nothing of what it printed, and hands back only the result. What you see is that the run was done, whether it passed, the credits it used, and its output.

You can cancel a run from its page while it is queued or running. A cancelled run stops, and its hold comes back as described next.

Credits: held, then settled or returned¶

Creating a run holds credits against your balance — the tier's cap for a run, not what the run ends up using. When the run finishes, the hold is settled down to what the run actually used, and the rest returns to your balance. A run that never ran — refused before it started, cancelled in the queue, or lost by its sandbox host — is refunded in full, and so is a run whose output the platform could not deliver to you.

Two things follow from this. A finished run never costs more than the hold, because the settlement is capped there. And the number you see held at the start is the ceiling, not the price: the run's page shows the hold while it runs and the settled amount once it finishes. Your tier and balance, and what each tier allows, are on the pricing page and in your account settings. Settings › Profile, under Subscription, names your own caps and the credits a run of them holds.

A hosted run is stated in credits only. Its page, the runs list and your settings say what it held, what it settled and the time and turns it took, and no page shows how many tokens its model used, to you or to platform staff. A run paid for by an organization that is not metered holds and settles nothing; once it finishes, its page also says what its model use came to in credits. The receipts inside the run's downloaded output.tar are the runner's own record and still carry its counts. A run on your own machine, with the CLI or Agentry Desktop and your own model provider, is the other way round: it reports its tokens and never costs credits.

The output and the receipt¶

A finished run's page puts its result first. Where the run named the files it was for, a Deliverables list comes before everything else, described below. Then the QuickAgent's final message, rendered, and each file it wrote, with a preview for text, Markdown, CSV and JSON and a Download button of its own. You do not have to download anything to read it. Everything else about the run (the task, where it stands, the credits and caps, the receipt, the input files) is under Run details, one click away.

Behind that view is one archive, output.tar, which you can still download whole from the run's page for thirty days (Download everything). It holds the run's result, its reports, the files the QuickAgent produced and its receipts, the run's own record of what it was and what held it. The page opens that same download in your browser and reads it there; the site's server does not open it, and nothing of it is kept. What a QuickAgent wrote is shown as text, never as a page of its own: its Markdown is rendered without any HTML it carries, images are not loaded, a link is kept only when it is a plain web or mail address on another site, and hidden characters, in the text and in file names, are shown as visible marks. A file is saved as a download, never opened in the page.

PDF reports. A QuickAgent can turn a report into a PDF with its export_pdf tool: when you ask for a PDF, or when the report is meant for someone other than you, such as a letter or a summary for your team. Its look is your report design, never the QuickAgent's choice. A hosted run takes your whole design, your logo included, as a run on your own computer does. A host whose runner predates that draws only the theme your design started from, and an even older one Plain. A PDF the run exported has Open in a new tab beside its Download: your browser opens it with its own PDF viewer, in a tab of its own, from the copy it already holds. The page offers that only when the run's record lists the PDF by name with the same fingerprint (SHA-256) as the file in the archive. Any other PDF in the output is a download only, and the page says it is not one the run's PDF export made. The Markdown the PDF was made from sits beside it, previewed as usual.

Deliverables. The files a run was for come first on its page, each with a Download and, for a PDF, an Open that shows it in your browser's own viewer in a tab of its own. They are the files the QuickAgent marked as the ones you asked for, or, when it marked none, the ones the runner chose: the PDFs it exported, otherwise the files in its reports folder, otherwise its final message saved as a Markdown file (what counts as a deliverable). The sandbox host lists a file only after it has checked that the file it packed into your archive is the one the runner recorded, by its fingerprint (SHA-256) and size, so a file that changed after the run, or one that did not fit under the output's size limit, is not listed. Open shows a PDF only after the page has checked the file again against the same fingerprint and found a PDF's first bytes; every other type is a download, and nothing of a file is drawn on the page. The list rests encrypted with the rest of the run's own text, and the route that serves a file opens your archive as its download does, for your account alone: another account, platform staff and the other members of an organization that paid for the run get not found. A run that ended on a sandbox host with an older runner (before agentry-cli v0.6.138) has no such list; its page shows its files as before. The Dashboard can also list your latest deliverables (the Deliverables card).

The archive is encrypted on the sandbox host, before it leaves the host, to a key of your account's that Agentry keeps sealed for you; you never see the key or handle it. When you download the output, Agentry decrypts it with that key as it streams to you. The download serves it to your account alone: another account, platform staff included, gets not found, and an archive encrypted to your key does not open with anyone else's.

The receipt shows what the release declares — its capability contract, the same one on the QuickAgent's page — beside what the run enforced, item for item: the network egress the run was held to, the filesystem it could and could not touch, the OCI runtime its containers were created with, and, for a run with knowledge attached, each pack mounted, one line per pack, and the tools the run read them through. Those lines name the mechanism behind each one; the page shows them as they are, never summarised into a score. Agentry's language for a QuickAgent is "scanned, N findings, signed", and the receipt keeps to it: it records what happened, it does not certify that the result is good.

The page lists what the run enforced, under Run details, from the receipt Agentry keeps from the runner's own report of the run. The receipts/ folder in output.tar is written in the run's output folder, where the QuickAgent's own tools can write too, so the page never presents it as the receipt. A run from before Agentry kept receipts has none listed, and the page says so.

What bounds a run¶

A run is held to its tier's wall-clock time, turn count and a limit on its model use. Time and turns are the same budgets the CLI enforces on your own machine; a run that reaches either stops there.

The limit on model use is set so that a run never costs more than its hold, and the sandbox host enforces it, not the runner. The host follows what the run's model uses as the CLI reports it, and once that use passes the limit it interrupts the run the way a cancel does. The run ends interrupted and settles at what it used, never more than the hold. It can end a little past the limit, by what it used since the CLI last reported. A run that mostly reads can stop there before it has spent its whole hold, because reading costs less than writing. An unmetered organization's runs, which hold nothing, are held to the same limit. The runner's policy has no such limit, so an agentry run on your own machine is bounded by turns and time only.

A run no sandbox host takes within the queue window, or whose host stops answering, is closed and refunded.

Runs that need a secret¶

A QuickAgent can declare a secret in its manifest: an API key it needs, by name, for itself or for one of its MCP servers. On your own machine you supply it from your environment (running QuickAgents). In Agentry it comes from the secrets your account keeps.

Settings › Encrypted storage lists your secrets by name, with when each was saved, changed and last used by a run, and marks a value you entered for a single run that has not ended yet. You can save one, replace it under the same name, or delete it. Any QuickAgent that declares that name, capitals included, can use it in your runs. Once a value is saved, no page shows it again, and neither does the API.

When you start a run that needs a secret you do not keep, the setup's Secrets step asks for it. A secret the release marks Optional is asked for too, and its field may stay empty: the run starts without it, nothing is stored for it, and the review and the receipt name it as one the run went without. A required one must be given. Keep it for later runs is unticked, so by default Agentry removes the value when the run ends, however it ends. Nothing is sent until you press Start, and if the run cannot be created the value is removed at once. One that no run takes after all is removed about a day after it was saved. Tick the box to keep it, and the next run that needs it will not ask.

A value is one line with no space at either end. A value that spans lines, such as a PEM key, cannot be used yet.

What happens to a value:

At rest, Agentry stores only ciphertext. A separate key service holds the key, with a key of its own for your account. On Agentry's service, the part that saves a value cannot read it back. The part that hands runs to sandbox hosts can, for any account: it has to, to give a run its secrets.
When a sandbox host takes the run, Agentry decrypts the secrets the run carries, every required one and each optional one you gave or keep, and sends them with the run, over the host's encrypted connection. Each use is recorded in Agentry's audit log by name, with the run.
On the sandbox host, the value goes to the run's tools container, or to the MCP server that declares it and the gateway that starts it, never into the QuickAgent's own container. The host deletes its copy when the run ends. Where a value appears in the receipts, it is masked, except a value under eight characters or an encoded copy of one.
The receipt names secrets by name only, never a value.

What this does not protect: while the run lasts the value is plain on the sandbox host, and a tool that was given it can send it anywhere the release's network allows. The capability contract bounds where a secret goes. It does not govern what a tool does with it. Keep a secret only for a QuickAgent you would trust with it on your own machine.

A few cases still run on your own machine only:

A registry that keeps no secrets for hosted runs refuses a release that requires one, and says so. A release whose secrets are all optional runs there without them.
A release whose intake asks a required secret question runs in Agentry when the release itself requires the secret of that name (the question's id in capitals): the run setup asks for it like any other secret, and the run answers the question from it. A question that no required secret of the release's own carries cannot be answered by a hosted run, and the release runs on your own machine.
A release that requires more than 32 secrets cannot run in Agentry.

A run that carries no secret, such as one of a release whose secrets are all optional, started without them, runs wherever a release without secrets runs.

Some MCP servers work with your own account at their vendor: a remote server such as Linear's, or Google's Gmail, Drive and Calendar servers. You sign in on the vendor's own consent screen, and Agentry keeps the result as a connection: your grant to that one server, for that one version of that one QuickAgent. Another QuickAgent, or another version of the same one, asks for its own.

In the run setup's Connect tools step, each such server has Connect. It opens the vendor's sign-in page; you sign in and approve, and the vendor sends you back to the step, which says Connecting for a few seconds and then Connected. The run is not offered until every server is connected, and the review lists each connection by server. The next run of the same version asks nothing. Agentry never sees your password at the vendor.

Google lets no app register itself, so a connection to Google uses an OAuth client you make in Google Cloud, once. The step shows Agentry's steps for it the first time, then fields for its client ID and secret, and Keep it and connect keeps the client and goes on to Google. For a run in Agentry the client is a Web application client whose one authorized redirect is the address the step names (your own Google client). Any other vendor that needs a client of yours gets the same fields, with general steps.

Settings › Encrypted storage lists your connections, by QuickAgent version and server, with when each was made and last used by a run, and your own OAuth clients, by vendor. Disconnect removes a connection and asks the vendor to revoke it. Google revokes everything you granted a client at once, so the dialog names your other connections made with the same client, which stop working too. Forget removes a client you no longer use. A connection no run has used for 90 days is removed and revoked the same way, and clearing your account's data or deleting your account removes them all.

What happens to a connection:

At rest, Agentry keeps only ciphertext, under a key of its own, separate from your secrets' key. The part of Agentry that starts a sign-in can seal what the vendor sends back and cannot read it. The part that hands runs to sandbox hosts finishes the sign-in, and is the only part that can read a connection.
When a sandbox host takes the run, Agentry renews each connection with its vendor and sends the run a short-lived access token and nothing else: never the refresh token that renews it, never your client's secret. The host deletes it when the run ends.
The receipt names each server the run was given a connection for, and says the run was given an access token alone, never the token.

A run that lasts longer than its access token keeps running, and that server's calls fail with a sentence naming the connection. On your own machine, Agentry Desktop and the CLI keep their own connections, apart from these, and renew them during a run.

Talk to it: hosted sessions¶

A hosted session is a hosted run of a release's interactive mode: you talk to the agent while it runs, as you would in the desktop app's session window. It is part of Pro, Business and Enterprise. The tier is the one your runs are paid on, so a member of an organization starts one on the organization's. A session runs on a sandbox host exactly as a hosted run does: the same release verification, the same sandbox and egress proxy, and the same declared contract. A message cannot widen what the release declares.

Once the session is running, its page is a chat:

The agent's words stream in, and each finished reply replaces them. Your messages are labelled You, the runner's own notices Runner, and the agent's Agent. A short note marks each tool the agent calls, a permission the runner denied and a file you added.
Send sends one message at a time: the next waits until the agent has answered. Add file gives the agent another file, read-only under /inputs, within the run's input limits. Finish asks the agent for its final result, then ends. Stop ends at once, without one.
A line under the chat shows the turns, the tool calls, how long it has run, the free minutes left, the credits its time has cost so far, and when it closes if nothing happens.

Closing the tab does not end a session. It ends when you finish or stop it, after five minutes with no activity, or when a minute of it cannot be paid. Open its page again before then and the conversation is replayed from the sandbox host's memory. When it ends, the page shows the result as for any run: the final message, the files it wrote, and, among the receipts, transcript.md, the whole conversation. Without JavaScript the page shows where the session stands and offers Stop, and says that the conversation needs JavaScript.

What it costs. A session holds nothing. Its first ten minutes of server time are free; each minute after costs 50 credits, taken from your balance as the minute starts, and a minute the balance cannot cover stops the session. Its model use settles once when it ends, in credits, and never takes your balance below zero. A session starts only on a balance of at least 50 credits, the price of its first paid minute. The page shows what its time and its model use cost, in credits, once it ends. There is no cap on a session's turns, model use or length beyond the idle close.

What the chat carries, and what that claims. The chat says: "Transport encrypted by the user key, messages not stored; the transcript comes back only in your sealed output." In full, that means:

Each event the chat shows is encrypted on the sandbox host to your account's key, the one your output is encrypted to. The registry opens it inside your own request to follow the session, and passes it to the page.
The sandbox host holds those events in memory for the session's life and drops them when it closes. The registry and this site write none of the conversation to a table, a log or storage. The one copy kept is transcript.md inside your sealed output.
Your messages travel to the sandbox host over your sign-in and Agentry's mutually authenticated channel, as a run's task and files do, and are stored nowhere but that transcript.

What it does not claim: Agentry holds each person's key, sealed, in order to open your output for you. The encryption means an event opens only inside your own request; that nothing is written down along the way is how the registry, this site and the edge are built, and the registry's tests check it. Neither keeps the events from Agentry, which can open them as it opens your output. Only you can follow or type into your session: not platform staff, and not the other members of an organization that pays for it.

Where hosted runs run¶

SecureAgentry answers the residency question in one line: the United States, on Vultr, thirty days, encrypted to you. In full:

The sandbox hosts and the runs buckets are in the registry's Vultr region, New Jersey.
The hosts' model is Vultr Serverless Inference.
A run and its output are deleted thirty days after the run was created.
Every output is encrypted to the person who ran it.

A region per organization is not offered. The hosts sit in a network of their own that shares no route with the registry's, and a host has no public address (how the hosts are placed is in the operations guide).

Where hosted runs sit¶

The hosted runs reference has the API a script drives — creating a run, reading where it stands, downloading its output — and the runtime the sandbox uses. How QuickAgents are secured is what "scanned, signed" means and what it does not. The desktop app runs the same hosted runs from its own run panel.