Files
PaperClipAI/maps/agent-access-map/agents.md
T
DottaandPaperclip f0877a9c7c fix: recover native work and requalify saved computers (#17724)
<!-- entire-trail-link-start -->
https://entire.com/gh/paperclipai/-/trails/32/changes/paperclip/32
<!-- entire-trail-link-end -->

## Thinking Path

> - Paperclip manages AI agents and preserves their work after an
interruption.
> - Native Stop must confirm termination and save the workspace.
> - Task and run views must show the current recovery receipt.
> - A new external reply can arrive while that cleanup is pending.
> - The reply must return to its original chat owner after cleanup.
> - A successful fresh retry also becomes the task’s bound workspace for
its next ordinary turn.
> - Managed computer updates can invalidate a saved snapshot
qualification.
> - This pull request fixes those instructions, acknowledgements,
handoffs and the existing native-agent Test path.
> - The operator can continue with new input while the stopped turn
remains preserved.

## Linked Issues or Issue Description

**What happened?**

Stopped native runs could keep the initial workspace-repair instruction
after files were recovered. Native Stop could also leave the shared
cancellation state at requested after remote termination was confirmed.
A new GitHub reply saved during cleanup could then remain queued because
cleanup did not ask its original inbound owner to reconsider the
receipt. After a managed snapshot update, an existing native agent could
also need qualification while the generic environment Test required
instance-admin access.

**Expected behavior**

Show the current saved-work state. Acknowledge Stop only after exact
termination proof. Let an authorized operator use the existing
saved-agent Run test to qualify its current computer. After cleanup,
recheck the saved reply's current authority and admit it once as new
input. Preserve the stopped run and uncertain external effects.

**Steps to reproduce**

1. Stop an active native turn before it returns a semantic result.
2. Send a new authorized external reply while cleanup is pending.
3. Let workspace recovery and provider cleanup finish. Inspect the run
instruction, Stop acknowledgement and queued reply.

Related work: #17594 preserves native processes through controller
outages. #17401 addresses a separate bootstrap failure. This pull
request does not replace those fixes.

## What Changed

- Use the exact run's workspace recovery receipt for task and run
guidance, including the Activity ledger.
- Retire an obsolete exact-session notice through the existing bounded
reconciler. Preserve the separate no-replay hold.
- Write the shared native Stop acknowledgement only after the audited
Stop intent and every exact remote lease receipt match.
- Delegate saved external input to the live inbound owner. Recheck its
source, actor, endpoint, principal and conversation generation. Promote
the same receipt in the transaction that creates its new run.
- Use that owner from the cleanup callback and existing stranded-queue
catch-up after a lost callback or restart. A denied source cannot abort
other items.
- Reuse the current private task directory after a successful fresh
retry. Re-read the company/task/workspace binding and validate the
canonical stable or attempt namespace without recreating missing files;
keep a later fresh retry separate.
- Extend the existing agent-scoped qualification owner to native agents.
The clean saved-agent Test qualifies its exact computer before runtime
testing. Reuse a current proof; require a real probe and verified
cleanup for a stale proof. Preserve draft tests and metadata-only
external/pool previews.
- Update execution semantics, capability maps and the recovery
verification recipe. Add a production-page Storybook interaction for the
normal native Test.

## Verification

- **Red:** persisted recovery states returned stale instructions; an
exact terminated native lease left shared Stop requested; the real
GitHub subscribed-message fixture left zero successors after cleanup.
The controlled baseline restored the previous production source,
reproduced the failure, then restored the fixed bytes with matching
SHA-256 hashes.
- **Green:** 382 durable-chat, native-continuation, Stop and recovery
tests pass. The real GitHub/PostgreSQL handoff matrix passes 12/12. It
covers callback, application restart, callback/sweep race, valid input
behind a deleted source, and denial for unknown stop, wrong allocation,
paused endpoint, revoked principal, deleted or changed source, changed
conversation generation and foreign scope. Repeated callbacks preserve
one receipt, its actor, one successor and the unchanged stopped
predecessor.
- **Workspace continuation red/green:** the real PostgreSQL preparation
flow created a fresh attempt and saved a marker, then rejected the next
ordinary turn with the same binding mismatch observed in deployed use.
The repaired preparation and filesystem suites pass 86/86: stable and
attempt-root reuse, saved-marker preservation, a later clean sibling,
changed current bindings, foreign company/task, closed workspace,
traversal, missing path and symlink refusal. No task row reset or
old-turn replay is used.
- **Qualification red/green:** a native saved-agent qualification
returned 422, and its normal Test skipped qualification. The repaired
path passes 224 qualification/immutable-snapshot/environment tests and
176 UI/upgrade tests. It covers revoked authority, foreign or changed
computer, current-proof reuse, failed/missing proof, draft settings,
settings changed during the probe, and external/pool previews. On exact
current source, the real local Harness / Runtime UI also qualified a
newly saved disposable Computer with missing proof through actual
Daytona, then completed the actual OpenCode/OpenRouter hello probe using
`openrouter/deepseek/deepseek-v4.1-flash-1017`. Supported availability
changed from Legacy-only to Paperclip Runner after proof persistence.
Qualification and runtime leases both completed normal release/cleanup.
The five prior task run IDs were unchanged; no task wake was created.
This is macOS source-server/UI with real Linux Daytona and provider
services, not a hosted UI claim. Test probes are archived by the
existing inspection contract; release does not claim physical deletion.
- Full workspace `pnpm -r typecheck`, `pnpm build`, token, map and diff
checks pass at `f6450f4739fc8141815b8b7c35fde22a655c5f90`. The broad
local `pnpm test:run` passed 24,899 tests and reported one existing
nested-clone test timeout at 15 seconds. The complete failing file then
passed 21/21 with the normal timeout; the exact case also passed on the
pinned earlier baseline. The broad runner stopped before its later
groups. No timeout or production workaround was added. Prior head
`f6450f4` has 53 successful checks, two conditional Storybook skips and
Greptile 5/5 with no inline threads. New workspace-reuse head
`fcb13399ec70f92f71bd8250081251dca3f48962` passes workspace typecheck,
full build, 86 scoped tests, maps and diff checks; Current-head CI has
53 successful checks and two conditional Storybook skips; Greptile is
5/5 with no inline findings. Deployed ordinary-turn reuse acceptance
passed as described below.

- **Hosted Stop proof:** the real GitHub issue-mention path used native
OpenCode, `openrouter/deepseek/deepseek-v4.1-flash-1017`, Daytona and an
exact low-trust task boundary. Normal UI Stop interrupted an active Bash
call. Native and shared acknowledgements matched the exact lease.
Automatic recovery saved exactly `STARTED\n` (8 bytes), with no finish
marker. Reload showed Stopped and saved work recovered. Only the
original cancelled run remained. Normal five-minute cleanup completed
its exact provider-destruction transition.
- **Limits:** the provider buffered command output, so the marker was
read after recovery. The approved local provider credential could not
inspect the hosted sandbox; its 404 is not deletion proof. Cleanup
success comes from the exact lease's platform destruction transition. An
earlier hosted stale instruction disappeared after rollout with
unchanged raw run/action data; that historical cause remains
unexplained. Original incident holds and publication receipts were
untouched.
- **Hosted handoff proof:** after QA deployed the combined candidate
containing `46b2e99`, startup admitted the previously saved GitHub
author reply without another comment, Retry or manual action. The new
native run used the exact original wake receipt and saved comment. It
completed once, committed an external-response wait, preserved the
stopped predecessor, emptied the queue and left the task In review. The
answer appeared in the original GitHub conversation. Workspace
finalization and the exact lease's normal destruction transition
succeeded.
- **Hosted workspace proof:** on the combined candidate containing
`fcb13399`, normal Retry preserved the original authenticated GitHub
request and completed a fresh native attempt. One later ordinary
same-head author reply then completed in the exact same workspace ID and
attempt directory, with no Retry/fresh directive. Its input tree digest
matched the Retry's finalized digest; final copyback preserved that
digest. The persisted assessment row and all five prior run records were
unchanged, exactly one new reply run completed, and the task returned to
In review with an empty queue and no live run. Both exact leases
completed normal verified destruction. This used real native OpenCode,
the exact DeepSeek/OpenRouter model and Daytona, without workspace-row
repair or a new remote marker.
- **Publication limit:** the workspace audit compares the persisted
assessment and run history. The ordinary reply exposed a separate
destination-summary fallback that changed the visible GitHub summary
despite the preserved assessment row. The publication track is repairing
that behavior; this proof does not claim the visible summary was
preserved.
- **Deployment boundary:** current-head CI/review and hosted same-source
Retry/ordinary-workspace reuse acceptance passed. The separate
visible-summary publication failure remains owned by the publication
track. Combined hosted UI confirmation of the native-agent Test path is
coordinated separately. Actual missing-proof UI/provider qualification
has passed in the isolated local instance above; prior hosted Stop and
same-input handoff proof remains separate. No merge or deployment is
performed by this pull request.

## Risks

Recovery state and termination receipts must match the exact source run
and allocation. Missing or foreign proof keeps the hold. The chat owner
must retain the original receipt and actor and recheck current
authority. Cleanup cannot grant authority or replay the stopped turn.
Existing native ownership, Stop, budget, permission and uncertain-effect
guards remain in place.

## Model Used

OpenAI GPT-6.1 Sol (`gpt-6.1-sol`) through Codex, with reasoning,
repository tools, source editing and test execution. The context-window
size is not exposed in this session.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass (affected suites and
isolated failing file pass; broad timeout retained above)
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green (current fcb has 53 successful
checks/two conditional Storybook skips)
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-10-26 22:21:58 -05:00

21 KiB
Raw Blame History

Hiring, agent configuration, and organization — agent access

Product map: Hiring, agent configuration, and organization.

Feature ID: agents.

Review date: 2026-10-12. Source commit: 58e16dbddfc9c8d0cf60867f9d9847f0feda055b. Native REST transport reconciled in this change; see the shared transport contract.

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 for format, permission checks, evidence and maintenance.

Scoped runner-default source review: 2026-10-12 at eee0534154eaf5d0d3f2bbc97c1e24d86f34a5a5, limited to creation/configuration, approval activation, built-in provisioning and import preservation described below. The original baseline commit above still governs unrelated entries; this update does not claim operation-complete review or live agent verification.

hire

Capability ID: agents/hire.

Review: baseline.

API: present — representative operation IDs:

  • POST /api/companies/{companyId}/agent-hires.
  • POST /api/companies/{companyId}/agents.

Agent access: partial — Native hire_agent; REST / CLI agent; runtime inheritance for native hires.

Creation requests can use runner: auto | paperclip | legacy; the server resolves and persists execution configuration. Claude Auto selects the native ACPX profile on qualified macOS and GNU/Linux x64/ARM64 targets; unknown environment qualification remains Legacy. Darwin SSH defaults to Legacy while preserving explicit native assets and saved execution. Saved runner/model/provider overrides survive edits and approval activation. This selection does not grant connection access or bypass hiring authorization. Source: runner resolver.

Policy: Agent creation/configuration uses action grants, resource policies and change consent; some controls require a board actor.

The early wizard record (setupId on create) and completion of that record (setupAgentId on hire) require a board actor and company-scoped creation permission. Its creator can finish their own inactive setup with that permission; changing another person's setup requires configuration permission. Creation retries reuse only records owned by the caller. Returning a completed record also requires the normal agent-read and configuration-read checks. An unfinished record keeps compatibility status paused with a setup hold and cannot receive API keys or authenticate with keys or JWTs. Its standard grants apply at hire. Authorized completion retries recover the same record and approval without changing the submitted configuration. Normal agent-authored hiring keeps its existing approval policy.

An agent-owned plugin may prepare the draft and leave its lifecycle in verifying while that setup hold remains. Only bounded Core-issued setup probes can run there. The creator's company creation permission also covers configuring and retrying their draft during preparation or stopping; other actors still require the ordinary configuration permission. This is a board wizard path, not new agent execution or probe authority. Lifecycle and component regressions cover these transitions; no permitted-agent or live-provider journey is claimed here. Companies requiring hire approval keep drafts paused and allocate no agent-owned resource before approval. Selecting an account there is pending verification, not approval or execution authority.

The creation boundary resolves the request-level runner before adapter validation and credential normalization. Omitted/automatic new Codex selection uses the qualified target's default; explicit Legacy is retained. Disabled adapters and external overrides affect new selection, while missing credentials/runtime or incompatible settings remain errors. Existing agents and reviewed pending hires retain their recorded execution. Native hire_agent explicitly inherits its caller's runtime and remains subject to permission and credential restrictions; it is not an arbitrary host-configuration or login tool. REST/CLI creation and hire runner options use the shared request contract.

Evidence: source-only — implementation at the reviewed commit above.

Scoped Evidence: source-only — creation policy, runner resolution, native hire binding, frozen approval activation and same-harness import preservation at the scoped commit. No permitted-agent journey was executed for this map update.

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.

For this scope, compare automatic and explicit Legacy creation, assert foreign company/environment and missing-grant denials, then compare pending approval configuration across restart and activation. An unrelated edit/import update must not change existing execution; a new package without a runner choice receives creation defaults. Do not count a board call or component test as agent evidence.

Gaps: Identity/persona hiring works. Operator account login and sensitive adapter/environment configuration are separate guarded actions.

The runner request does not grant new account, environment-probe or native API fallback authority; see validation access and environment administration. Full access qualification remains not run.

instructions

Capability ID: agents/instructions.

Review: baseline.

API: present — representative operation IDs:

  • GET /api/agents/{id}/instructions-bundle/file.
  • GET /api/agents/{id}/project-access and POST /api/agents/{id}/project-access are board-only. The POST requires agents:create, checks selected projects in the same company, and adds IDs under an agent row lock. It preserves existing containment, audits new grants and rejects pending-approval agents. Agent keys cannot use this route to grant themselves access; a read-only board viewer receives canManage: false. Saving never creates a run or wakeup.
  • PUT /api/agents/{id}/instructions-bundle/file.
  • PATCH /api/agents/{id} with an explicit runner: "paperclip" upgrade.
  • POST /api/agents/{id}/qualify-runner to qualify the saved effective sandbox before upgrading or testing an existing native runner.
  • PATCH /api/agents/{id} with runtimeSettings: { harness, model?, aiConnection?, expected: { model, aiConnection } } for a narrow roster edit. Each request handles one agent; the UI batches at most four writes and collects per-agent outcomes.

Agent access: available — Native read/update/history/restore instruction tools; REST / CLI.

Policy: Agent creation/configuration uses action grants, resource policies and change consent; some controls require a board actor.

The roster intent preserves unrelated settings, rejects stale model/connection previews and harness changes, and checks the full execution configuration under the lifecycle write lock. It uses the same configuration, company, credential, environment, and consent checks as other edits. It adds no agent permission or credential fallback. Pool and externally managed agents use their existing configuration surfaces. Board browser verification does not qualify agent access.

The existing-agent upgrade notice uses this configuration PATCH. It does not grant configuration, account, or environment access. The server resolves the saved settings under normal company/configuration authorization. Obsolete Claude tuning fields are removed with configurationWarnings; security incompatibilities remain errors. Unqualified sandbox upgrades first use the agent-scoped POST /api/agents/{id}/qualify-runner under the same agent_config:update authorization as saving the upgrade. The server resolves the saved computer; expectedEnvironmentId rejects stale state and cannot select another computer. Qualification checks company binding, returns only its receipt, and audits within the agent's company. General instance environment probes still require instance admin. An existing native agent's clean configuration Test uses the same saved-computer qualification before its runtime test. A current proof is reused; a missing or stale proof requires a real successful probe and verified cleanup. Draft settings and target changes do not qualify another computer. No probe runs merely on page load. Operator browser evidence does not qualify the agent permission paths for this operation.

Evidence: source-only — implementation 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: Canonical entry file, revision guard, company boundary, and protected-change policy apply.

organization

Capability ID: agents/organization.

Review: baseline.

API: present — representative operation IDs:

  • GET /api/companies/{companyId}/org.
  • PATCH /api/agents/{id}.

Agent access: available — list_agents/get_agent; native call_api for permitted configuration fields; REST / CLI.

Policy: Agent creation/configuration uses action grants, resource policies and change consent; some controls require a board actor.

Evidence: source-only — implementation 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: Reporting-line changes need configuration authorization; a title alone gives no authority.

lifecycle

Capability ID: agents/lifecycle.

Review: baseline.

API: present — representative operation IDs:

  • POST /api/agents/{id}/pause.
  • POST /api/agents/{id}/resume.
  • POST /api/agents/{id}/terminate.
  • DELETE /api/agents/{id} permanently purges an eligible terminated/rejected agent.
  • POST /api/agents/{id}/lifecycle/retry.
  • GET /api/agents/{id} returns the safe failed phase/step and action in lifecycleError.

Agent access: partial — REST / native call_api resume under agent_config:update change-grant authorization; pause and termination remain board-only.

Policy: Agent creation/configuration uses action grants, resource policies and change consent; some controls require a board actor. Permanent deletion is board-only. Retained case handoff references return 409 agent_case_history_retained before dependency cleanup; keep the agent terminated.

Evidence: source-only — implementation 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: Resume has a generic native REST path. Pause and termination remain enforced actor restrictions.

built-in

Capability ID: agents/built-in.

Review: baseline.

API: present — representative operation IDs:

  • POST /api/companies/{companyId}/built-in-agents/{key}/provision.

Agent access: partial — REST / native fallback for eligible provisioning; built-in routine controls require board.

Policy: Agent creation/configuration uses action grants, resource policies and change consent; some controls require a board actor.

Evidence: source-only — implementation 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: Provisioning checks agents:create. Enabling/running its built-in routine is not the same permission path.

Scoped source review: built-in provisioning recognizes the underlying Codex harness of a native company agent. New configured provisioning resolves the runner, while unrelated reconciliation and same-harness edits retain existing execution. Verify explicit runner changes preserve compatible saved settings; the general creation/access policy above still applies. This is source-only evidence at the scoped commit, not a live provisioning result.

primary-agent

Capability ID: agents/primary-agent.

Review: baseline.

API: present — GET and PUT /api/companies/{companyId}/primary-agent/me.

Agent access: restricted — this is the authenticated human's personal preference. Agent keys and native call_api use agent identity and are denied by the board gate; no dedicated agent selection tool is present.

Policy: Requires board user identity, company access and active membership, except implicit-local board or instance administrator. Viewers may choose their own primary. Selection requires a same-company readable, available agent and is scoped to actor user ID; the request cannot select another user's preference. Explicit null selection is rejected; leave/termination can clear an unavailable choice. Initialization stays recorded so clearing does not silently replace it.

Evidence: source-only — reviewed on 2026-10-13 at 60bc0d5fee9a6e48db08fc016521fee3d9f57d67: routes, service, provider, and route tests.

Verification: not-run — select and read the preference as two company users; assert isolation, wrong-company/unreadable targets, pending/terminated agent rejection and agent-key denial. Verify replacement confirmation and fallback precedence in the UI; inspect the cleared state after permitted leave/termination.

Gaps: No agent mutation path for another person's preference. Live human/agent access is unverified; UI fixture callbacks do not establish persistence or task and Chat default resolution.

grok-bot

Capability ID: agents/grok-bot.

Review: baseline.

API: present — POST /api/companies/{companyId}/grok-invitations, operator-owned Grok invitations and agent-scoped /grok-binding setup, routine, verify, stop, recover and disconnect endpoints. Direct HTTPS /mcp/runner uses fixed named-agent OAuth. Grok tools expose durable assignment operations and task-bound upload/download grants.

Agent access: available — paperclip_grok_* through the dedicated agent grant. First-party Paperclip operations execute through the shared Rust Runner. The Bot retains its own apps; Paperclip workspace and third-party app tools are unavailable.

Policy: company/agent/client/resource/authorizer binding; current manage-agent permission for consent and subsequent calls; normal task ownership, controller lease, governance, pause, revocation and recorded budget checks. Execution and file transfers require current task-bound sessions. Secret credentials remain in encrypted secret storage and are redacted from HTTP logs.

Evidence: source-only — routes, shared authority, routine receipts and Runner broker. Temporary actual-client OAuth and an outbound routine wake are qualified separately; they do not prove this candidate’s acceptance.

Verification: not-run — deployed acceptance pending; focused protocol/authorization and actual Rust backend tests; run fresh/saved setup, assigned and proactive tasks, duplicate calls, stale sessions, restart, ambiguous delivery, stop and recovery through the real client on the serving managed candidate.

Gaps: deployed two-way work and unattended first-time onboarding remain unqualified; remote termination, provider transcript streaming and usage accounting are unavailable.

api-keys

Capability ID: agents/api-keys.

Review: baseline.

API: present — GET /api/agents/{id}/keys; POST /api/agents/{id}/keys; DELETE /api/agents/{id}/keys/{keyId}.

Agent access: restricted — key listing and mutations require board identity and agent-management authority. The CLI token agent commands use authorized board context. Ordinary agent REST/native call_api and public assistant capabilities do not grant key-management authority.

Policy: getAccessibleAgent checks company access and agents:create through the shared access evaluator for reads as well as mutations. Creation rejects pending_approval and terminated agents. Keys retain the creating person’s responsibleUserId; only a hash is stored and token plaintext is returned on creation. Revocation checks that the key belongs to the selected agent. Authentication separately applies agent state, revocation, scope, and responsible-user membership intersections.

Evidence: source-only — reviewed at 9ef434fe79c57d976b8b03b14c5242db270b8320. Keys tab, key routes, key service, authentication, and CLI token commands.

Verification: not-run — Create a disposable key as a permitted authenticated board person, prove one harmless agent read, revoke, and retry the same bearer. Assert metadata persistence, once-only token display, activity, missing management permission, agent identity denial, cross-company/cross-agent IDs, ineligible targets, and missing responsible-user binding.

Gaps: Local implicit key creation does not by itself prove a usable responsible-user binding. No ordinary-agent self-management or assistant delegation path is established; browser creation and actual bearer use need live evidence.

managed-agent-setup

Capability ID: agents/managed-agent-setup.

Review: baseline.

API: present — GET and POST /api/companies/{companyId}/managed-agent-profiles. Provisioning separately calls Anthropic /v1/environments, /v1/agents, and /v1/agents/{id}/versions with operator provider credentials; --probe does not resolve a Paperclip client context or call the profile API.

Agent access: operator-only — provider qualification/provisioning uses the explicit operator CLI. Persisted profile reads/writes require board/company identity; viewer writes are denied. This does not authorize a company agent to provision external provider resources.

Policy: A profile uses an active same-company, company-scoped secret reference. Qualification requires the source-supported pinned model/version, no tools/MCP/skills/multiagent capability, and a locked no-network/no-packages environment with retention acknowledgement. Qualified configuration revisions are immutable; changed qualified configuration requires a new profile key. Provider API credentials and Paperclip profile authority are separate checks.

Evidence: source-only — reviewed at 9ef434fe79c57d976b8b03b14c5242db270b8320. Managed-agent CLI, profile routes, profile service, and runtime validation.

Verification: not-run — Compare provider and Paperclip state before/after probe, then inspect a permitted create/adopt and repeated resource reuse. Reject missing acknowledgement, unsafe resources, invalid model/version/secret/company, and viewer/agent mutations. Separately run a bounded useful task with the saved qualified profile before claiming runtime readiness.

Gaps: This is a provider-specific setup path, not qualification of every managed service or deployed environment. Mocked setup and source validation do not prove live retention, remote execution, or provider availability.