GET /api/v1/jobs/{jobId}/invocation-permissions and replace them with a PUT containing {"destinationJobIds":["..."]}. The write requires jobs:write and accepts a browser owner session, scoped API key, or authorized OAuth client. Destinations must belong to the source job’s project; a job can include itself to opt in to explicitly requested successor runs. A run token can invoke a configured destination only while the source and destination remain in the same project. Deleting either job removes its permission edges. Revocation takes effect on the next invocation request.
Permissions are project-local. The editor searches only the source job’s project, and the API rejects cross-project permission writes. Existing cross-project permission rows are hidden from reads and cannot authorize run-token invocation. Existing lifecycle, edited, idle, schedule, and webhook triggers remain independent and do not grant manual invocation.
For each execution VM, Factorize creates an exe.dev HTTP proxy named fz-run-<run UUID>. Its credential is installed by the Factorize control plane and held by exe.dev; it is never placed in the guest environment, prompt, or files. The integration is attached only to that VM for at most 24 hours. Discover its URL through https://reflection.int.exe.xyz/integrations, using the name supplied in the run instructions. No API URL configuration or client-supplied Authorization header is needed.
The credential is bound to the source job and run, expires after 24 hours, and stops authorizing requests when that run is no longer active. Its scopes come from the job’s Run permissions setting (runScopes in the job REST/MCP contract). Existing jobs and omitted create fields default to tenant-scoped reads of projects, jobs, runs, safe integration metadata, and skills, plus invoking authorized destinations. You can select additional write/cancel scopes, remove default scopes, or choose no scopes. Write scopes do not imply read scopes, except the legacy runs:write expansion. Credentials remain outside the VM regardless of scope. Do not pass a source job or run ID: the service derives both from the credential. GET /api/v1/runtime-context (MCP get_runtime_context) returns the verified source run/job identity and effective scopes without exposing the credential. It requires an authenticated active identity, but no application-resource scope, so even a zero-scope run can verify its own identity.
Use the normal manual invocation endpoint, which is also the invoke_job MCP tool:
idempotencyKey when retrying an uncertain request. Destination run details expose invocation.source_job_id and invocation.source_run_id; human and external invocations leave these values null.
Before starting the agent, Factorize verifies the run proxy and checks the control-plane attachments of other HTTP proxies targeting the same Factorize origin. Any shared Factorize proxy attached to that VM blocks startup, regardless of its scopes. The dedicated run proxy provides the job’s configured API access. Keep shared Factorize integrations on operator-only VM attachments. A public API credential with runs:invoke still supports ordinary external clients; do not attach that credential to execution VMs. Configure any alternate Factorize hostnames with the same isolation; never attach a broader proxy through an alias.
Proxy removal is part of VM cleanup and is retried after failure. The credential’s active-run and expiry checks remain effective even if external cleanup is temporarily unavailable. Installing credentials in a proxy prevents exporting the secret from the VM; it does not prevent an agent from misusing its permitted operations while running. Keep destination permissions narrow.
Configuring privileged orchestration jobs
In a job’s editor, select Run permissions and save its configuration. API/MCP clients can supplyrunScopes when creating or updating the job. Omitting runScopes on update preserves the existing setting; an explicit empty array grants no application API scopes. Both agent and code jobs use the same per-run proxy delivery.
For example, an orchestration job that reads and repairs job configuration needs jobs:read and jobs:write. A job granted jobs:write may also change its own or other jobs’ run scopes, using the normal tenant-local job update API. This is administrative authority over future job execution; grant it only when intended. Manual invocation still needs runs:invoke and an explicitly authorized destination.
Scopes are snapshotted when the invocation is created and stored with its execution credential. Updating a job does not add or remove authority from existing queued or active runs; cancel existing runs when immediate revocation is required. Credential rotation during a launch retry preserves the original scope snapshot. Runtime context reports the effective scopes, including legacy scope expansion. Browser-only API-key management, authorized-client management, and trace replay retain their existing session requirements.