PaperClipAI/maps/agent-access-map/onboarding.md

# Onboarding and first work — agent access

Product map: [Onboarding and first work](../feature-map/onboarding.md).

Review date: 2026-10-12. Source commit: `f981fa3cc10cb8663a87dec60345fbff46d54d0a`.

This is a source-reviewed baseline of representative operations and known gaps.
Each capability needs operation-level review before its entire scope can be
qualified. No live agent execution is claimed. Follow the [map contract](../README.md)
for format, permission checks, evidence and maintenance.

Scoped runner-default source review: 2026-10-12 at
`eee0534154eaf5d0d3f2bbc97c1e24d86f34a5a5`, limited to first-agent selection,
selected-runtime validation and draft restoration. Unrelated baseline entries
retain the original source commit; no live agent verification is added.

## `instance`

Review: `baseline`.

API: `not-applicable` — Bootstrapping an instance cannot depend solely on an API served
by that not-yet-running instance.

Agent access: `operator-only` — Existing CLI onboard/run/doctor / test-drive.

Policy: Instance setup is operator work; company creation is board; agent creation/task
creation retain their individual permissions.

Evidence: `source-only` —
[implementation](../../ui/src/components/OnboardingWizard.tsx#L279) at the reviewed
commit above.

Verification: `not-run` — exercise the listed local workflow in an authorized, owned
operator environment. Verify its isolation and result; do not count local machine
authority as company-agent API access.

Gaps: Bootstrapping an instance cannot depend solely on an API served by that
not-yet-running instance.

## `company`

Review: `baseline`.

API: `present` — representative operation IDs:

- `POST /api/companies`.
- `POST /api/companies/{companyId}/agents`.

Agent access: `partial` — Board company creation; authorized in-company agent hiring
API.

Policy: Instance setup is operator work; company creation is board; agent creation/task
creation retain their individual permissions.

Evidence: `source-only` —
[implementation](../../ui/src/components/OnboardingWizard.tsx#L279) at the reviewed
commit above.

Verification: `not-run` — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.

Gaps: API building blocks exist; an ordinary agent cannot create its parent company with
a company key.

## `adapter`

Review: `baseline`.

API: `present` — representative operation IDs:

- `GET /api/companies/{companyId}/adapters/{type}/models`.
- `POST /api/companies/{companyId}/adapters/{type}/test-environment`.

Agent access: `partial` — Permitted agent/model API; operator
provider-account/environment setup.

Policy: Instance setup is operator work; company creation is board; agent creation/task
creation retain their individual permissions.

The wizard selects the Codex harness and lets the server resolve an automatic
new-agent runner; explicit Legacy remains available. Supported-platform and
immutable sandbox evidence follow [environment probe policy](./execution-environments.md#probe).
Creation/discovery do not provision a target to determine this default. Adapter
setup validation requires `agents:create`, plus saved-agent update access when
testing an existing agent; interactive account login additionally requires a
board user and owner-bound session. An agent's right to hire is not login or
instance-environment administration authority.

For fresh managed Codex Auto setup, the wizard's explicit Connect path can call
`POST /api/environments/{environmentId}/probe?companyId={companyId}` before
selected-runtime testing, then refresh scoped adapter discovery. This reuses the
existing board instance-admin/local-implicit probe gate; `agents:create` alone
is insufficient. A 403, absent proof, changed configuration, missing response
identity or unconfirmed cleanup remains visible. No probe is added to creation
or discovery, no agent/company grant is broadened, and provider authentication
errors never cause an automatic runner switch.

Native setup derives outer sandbox isolation from the server-resolved execution
target, as task execution does. This is an internal transport choice, not a
request/configuration permission. Local and SSH setup keep Codex isolation;
caller-supplied environment flags do not authorize an external sandbox. Existing
company, account, probe and registration-cleanup gates still apply.
The bounded hello probe retains read-only permissions and no dynamic tools. Its
trusted launch skips project-instruction discovery in the new, empty setup
workspace. This grants no filesystem or networking permission and does not
change instruction discovery for ordinary task execution.

Scoped source review: 2026-10-13, exact baseline
`1a0ca66242121e39d88455aa2b52a07acc4a07d9` plus the privately composed onboarding
correction. [Wizard controls](../../ui/src/components/OnboardingWizard.test.tsx)
and [existing Product E2E observer controls](../../tests/runner-e2e/first-task.test.ts)
exercise mocked allowed/denied setup and sticky unknown cost coverage. They do
not prove live actor authorization or provider execution. The explicit manual
`confirmation-replies.runner-codex.daytona.task-card-accept` case requires an
eligible immutable OCI target and the existing probe authority, two identified
setup leases and separately authorized paid/cleanup reservations. Its fixture
neither prequalifies the environment nor creates the agent. Actual Cloud named
snapshot binding, warm/cold signup and live allowed/denied agent checks remain
`not-run`.


Evidence: `source-only` —
[implementation](../../ui/src/components/OnboardingWizard.tsx#L279) at the reviewed
commit above.

Scoped Evidence: `source-only` — [wizard/default selection](../../ui/src/components/OnboardingWizard.tsx),
[creation resolver](../../server/src/services/agent-runner-selection.ts) and
[setup/login authorization](../../server/src/routes/agents.ts) at the scoped
commit. Existing agent/approval execution preservation follows
[hiring access](./agents.md#hire); no live onboarding proof is claimed here.

Verification: `not-run` — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.

Gaps: Account authorization, environment administration and model selection need
separate checks.

Verify automatic onboarding without a post-hire runner change, explicit Legacy,
saved configuration after reload and the actual selected runtime's useful task
plus follow-up. Assert denied agent login/probe and foreign-company account or
environment access separately. These agent-context checks remain `not-run`.

## `first-task`

Review: `baseline`.

API: `present` — representative operation IDs:

- `POST /api/companies/{companyId}/issues`.

Agent access: `available` — Native create_task / agent REST / CLI issue.

Policy: Instance setup is operator work; company creation is board; agent creation/task
creation retain their individual permissions.

Evidence: `source-only` —
[implementation](../../ui/src/components/OnboardingWizard.tsx#L279) at the reviewed
commit above.

Verification: `not-run` — exercise a listed permitted operation with actual agent
credentials/run context; inspect its result and applicable persistence/attribution.
Assert the relevant denied actor, owner, company or mode from Policy. Review the
remaining operations before qualifying the whole capability.

Gaps: Task creation is agent-accessible where permitted; scheduling/readiness does not
follow from successful creation.
The Codex first-task fixture's operator cost guard uses the existing board
agent-configuration PATCH before admitting work. This is not evidence of agent
permission to update its runtime; the listed agent-context checks remain not-run.

Scoped source review: 2026-10-13, the first-task asset correction against
`ea6c8eb5e16d61111968f633a66748b397b64a3e`. The existing
[first-task instructions](../../server/src/onboarding-assets/first-task/skills/first-task/SKILL.md)
send file-producing work through the child's own execution and existing
dependency/block controls. Native `register_deliverable` retains its current-task
binding; this adds no cross-task file-registration authority or permission.
Document-only work may use the existing child-document API inline, and plan-only
approval does not authorize implementation. The existing asset tests check
wording only. The literal baseline live attempt failed child-file delivery and
completion reporting; revised live authorization and execution remain `not-run`.

## `resume`

Review: `baseline`.

API: `not-applicable` — No server onboarding-draft API for this browser-local state;
classify explicitly or intentionally make it a cross-client product feature.

Agent access: `not-applicable` — Browser localStorage wizard draft; persisted resources
use their domain APIs.

Policy: Instance setup is operator work; company creation is board; agent creation/task
creation retain their individual permissions.

Evidence: `source-only` —
[implementation](../../ui/src/components/OnboardingWizard.tsx#L279) at the reviewed
commit above.

Verification: `not-run` — use the product recipe for the local/developer surface. Verify
listed shared-resource reads separately; local presentation alone is not agent API
evidence.

Gaps: No server onboarding-draft API for this browser-local state; classify explicitly
or intentionally make it a cross-client product feature.

Scoped source review of [draft restoration](../../ui/src/components/OnboardingWizard.tsx)
preserves harness/runner intent and invalidates obsolete setup-test results after
a selection change. Browser draft continuity is not API or live-agent evidence,
and opening a saved Legacy agent does not apply new-agent defaults.

The initial matching route opening preserves the authorized saved wizard step
on bare and company-prefixed reloads. Explicit new-company or changed-company
openings retain their navigation override and clear foreign company resource
IDs. [Existing component controls](../../ui/src/components/OnboardingWizard.test.tsx)
exercise these presentation and account boundaries. This scoped correction adds
no server draft API, agent grant or proof of live actor authorization. The
managed first-task eval still reloads before Get started and remains a separate
live acceptance gate. The existing mocked-login browser case also checks the
same company-scoped active session and saved selection through route reopening
and a real reload, with one login start and no pending-login hire. These fixture
assertions do not prove server authorization or live credential use.