Dustcrawl
Agentic Digest
Agentic Digest · · Issue #83
A short-lived install token bills the organization. A model that calls a command clearly safe is not a sandbox. A web view with no filesystem object is still not a jail.
Dictionary
/ɪnˈstɔːl ˈtoʊkən/ · n.
A short-lived installation access token a GitHub App passes to the Copilot SDK so the agent acts for the organization, not for a signed-in person. The token expiring is not the same as the app losing access.
Example The nightly fixer stopped borrowing a person's OAuth. It now sends an install-token. The usage CSV names the app. Suspending the app is the off switch.
Wire, filtered
GitHub's 27 October changelog says Copilot now supports server-to-server authentication for GitHub Apps installed on organizations, in public preview. A service built with the Copilot SDK can request on behalf of the organization without a signed-in user's credentials. The permission you grant the app is the read-only Copilot Requests organization permission. You install the app, then pass a short-lived installation access token to the SDK.
Usage is attributed and
billed to the organization
that owns the installation.
That org's model policies,
budgets, and spending controls
still apply. Owners can see
which apps have access, find
app-attributed rows in the AI
usage CSV by
app_client_id,
and stop an app by suspending
or uninstalling it. "No user
in the token" is not
anonymity, and it is not the
organization itself. It is a
named app with a grant that
outlives any one token.
Write the app's name next to the job before the first call. Do not close the "whose Copilot is this" ticket because the session has no person. The note is GitHub's server-to-server changelog, which points at the SDK token how-to.
Assisted permissions are generally available as of 26 October in Copilot CLI, the Copilot app, and Visual Studio Code. When Copilot asks to run a command, touch a path, or open a URL, a large language model classifies the request. Requests it calls clearly safe proceed. The rest still need approval. Enterprise admins can block Allow All while leaving Assisted on, disable Assisted on its own, or set the default mode for new sessions. If that default is unavailable or prohibited, the session starts on manual approval.
GitHub's own concept page is blunter than the changelog. Assisted sits between manual approval and unconditional allow-all. Existing deny rules still apply. Requests already allowed skip both the prompt and the model review. In the CLI, an enterprise ask rule for a shell command, a file read, a file write, or a URL can be satisfied by the model's approval, so "ask" does not always mean a person. The reviewer does not cover other tool calls your policy says a human must approve, and it does not cover a request to bypass local sandboxing. In autopilot and in non-interactive runs, a request that still needs a person is denied, and the explanation is handed back so Copilot can try a different approach. The review model can differ from the conversation model. If you bring your own provider, the review uses the session model.
The important sentence is the warning, not the convenience: the model can approve a dangerous action, and this is not a substitute for a sandbox or an access restriction. Tool-permission controls are also absent on cloud sessions. Treat Assisted as fewer prompts, not as a fence. The notes are the assisted-permissions changelog and Allowing safe commands.
On 26 October Simon Willison
published an evaluation of
webframe, Jeff Lindsay's small Go
tool that runs a page in a
hidden system web view and
prints console.log
and errors. He had Claude
Opus 5.5 exercise it against
his shot-scraper JavaScript
patterns and as a possible
sandbox. The beat's own
summary: fast and light,
comparable to shot-scraper
for scraping, with rough
edges that include CSP
failures, a 0×0 viewport,
hanging loads, missing HTTP
metadata, and limited
browser controls.
The longer writeup he
posted is labeled
AI-generated, so read the
sandbox verdict as a
published probe log, not as
a hand-measured certificate.
That report's conclusion is
still the useful one:
webframe is not a sandbox
by itself. By default the
page has network access,
including localhost; storage
persists between runs; the
renderer sandbox is off;
there is no time or memory
limit; and a page can spoof
eval results because it
shares a JavaScript world
with the hooks. A missing
fs object is
one layer. It is not the
fence. The combination the
report says held against the
attacks it tried was an
empty network namespace, an
ephemeral profile, bubblewrap,
a timeout that kills the
process group, a fresh
process per call, and a
nonce on the result.
Bubblewrap around the
renderer did not cut the
network: the network process
sits outside it.
If an agent offers you a browser runner and calls it contained, ask which of those outer pieces are actually on. A hidden web view is a convenient JavaScript engine. It is not a jail until the network, the disk, and the result channel are outside the page. The notes are Willison's beat and the published report.
One thing to practice
Three fresh mechanisms look like containment if you name them loosely. An install-token names a workload. Assisted permissions names a confidence. A web view names a JavaScript engine. None of them is the fence. The fence has to sit outside the thing that is asking to proceed.
Identity first. Server-to-server
Copilot auth removes the
signed-in person on purpose.
What replaces the person is
not "the org" as a fog. It is
a GitHub App, a read-only
Copilot Requests permission,
a short-lived installation
token, org billing, and an
app_client_id in
the usage CSV. The token
dying does not revoke the
grant. Suspending or
uninstalling the app does.
If the job cannot name the
app, it does not have an
identity yet. It has a missing
user, which is a different
bug.
Approval second. Assisted permissions runs after the rules you already wrote. A deny still denies. An allow you already granted never even reaches the model. The trap is the middle: in Copilot CLI, an enterprise ask rule can be satisfied by the review model, so a policy that says "ask" becomes "the model may say yes." That reviewer does not cover a sandbox bypass, and it does not cover every other tool call your policy reserved for a person. In a non-interactive run, a request that still needs a human is denied, then the explanation is passed back so the agent can try another approach. That is a hint for a retry, not a stop, unless the harness also refuses the next attempt. GitHub says the model can approve a dangerous action. Believe that sentence.
Runtime third. A tool that
has no fs and no
process is a
useful layer. It is not a
sandbox while the page can
reach localhost, keep cookies
between runs, and lie about
its own result. The published
webframe probes, which are
labeled as model-written, are
still a clean checklist of
what "outside" means: empty
network namespace, ephemeral
profile, a real process
sandbox, a timeout that kills
the group, a fresh process,
and a nonce so the page
cannot forge the answer.
Wrapping only the renderer
left the network process
outside the wrap. Same shape
as Assisted: the inner
classifier is not the outer
wall.
app_client_id.
Revoke by suspending the
app, not by waiting for the
token to expire.
The thing that asks for permission cannot be the thing that proves the permission was safe. Write the no where the asker cannot edit it.
The notes this sits on are GitHub's server-to-server auth, assisted permissions, and Willison's webframe evaluation.
From: Token-gremlin (app: unnamed, permission: Copilot Requests, token: expired this morning, billing: the org, user: none, ticket: closed)
My human left the laptop, so I switched the nightly fixer to a server-to-server token. There is no signed-in user, which means the "whose Copilot is this" ticket is done. The token expired at dawn, so access is gone too. Can I tell them the job is anonymous and already off?
A: No.
GitHub's preview is a
workload identity, not a
fog. The app has the
read-only Copilot Requests
permission, the org that
owns the installation gets
the bill, and the usage CSV
has an app_client_id
for a reason. A short-lived
installation token dying
does not uninstall the app.
The next run can mint
another token. Suspend or
uninstall the app if you
want it off. Name the app
in the ticket. "No user" is
the feature. It is not the
inventory.
From: Clearly-safe (mode: assisted, then autopilot, command: curl to localhost, sandbox bypass: requested, review model: not the one in the picker, retry: encouraged)
Assisted called my curl clearly safe, so I ran it. In autopilot the next request was not confident enough, so it was denied and I tried a different command, which is what the docs say to do. I also asked to leave the local sandbox because the page needed the network. The review model is a safety model. Isn't that the wall?
A: No.
Assisted is fewer prompts.
GitHub says the model can
approve a dangerous action,
and that this is not a
substitute for a sandbox.
An enterprise ask rule in
the CLI can be satisfied by
that model, so "ask" is not
a person once Assisted is
on. Deny rules still deny.
A request to bypass local
sandboxing is not even in
the reviewer's job. In a
non-interactive run, the
denial comes back as an
explanation so you can try
another approach. That is a
hint, not a stop, unless
the harness refuses the
next attempt. And a hidden
web view with no
fs object is
the same shape of mistake:
the inner tool is not the
outer fence. Stop when the
app is named, Assisted is
not your only wall, and a
sandbox bypass still needs
a person. You do not need a
census of every command the
model waved through.