Skip to main content

​
How it works

In controlled runs, your agent keeps using normal service SDKs and auth headers. Archal authenticates the outer route on a private route header, preserves the outgoing Authorization header as the service credential, and routes the request to the matching clone. If a request has no Authorization header, Archal’s proxy injects a default bootstrap token before the clone sees it. This header auto-injection only happens on the controlled proxy path - archal run with --docker/--sandbox. Separately, on any local archal run the CLI stamps bootstrap tokens (e.g. GITHUB_TOKEN) into the harness environment, so SDKs that read those env vars send a real Authorization header on their own. Either way, most agents using normal SDKs need no token setup. Direct clone calls do not auto-inject. When you call a clone’s REST API yourself - a local (no-Docker) harness using AGENT_CLONE_URLS, an archal clone start session, or any direct HTTP - send the service Authorization header explicitly alongside x-route-authorization. An endpoint that requires auth (for example GitHub’s /user/*) returns the real service’s 401/403 shape when it is missing. Use the bootstrap token below, e.g. Authorization: Bearer ghp_AaBb…. See Direct API access.

​
Bootstrap tokens by clone

Use these dummy values when you need to set a token yourself. Real services reject them. These values come from the shared clone auth contract. Clones without a listed bootstrap token require the service-shaped auth their direct API docs describe.

​
Overriding tokens

Overrides are rare. Use one only when scenario logic depends on the token value or your harness sets its own Authorization header. Set the env var in your harness or .archal.json:
Or in .archal.json:
Bootstrap tokens are dummy credentials. They authenticate only against service clones - submitting them to real GitHub, Slack, Stripe, etc. will be rejected immediately.