Providers and Credentials

Bind provider capability for Managed Research launches without putting secrets in prompts.

providers tells Managed Research which provider capability a run may use. It is separate from agent_model.

Public example

providers=[{"provider": "openrouter"}]

This binds OpenRouter provider capability for the run. The model still comes from agent_harness and agent_model when you choose them explicitly.

Provider bindings

Provider bindings can include non-secret config and limits:

providers=[
    {
        "provider": "openrouter",
        "config": {"allowed_models": ["anthropic/claude-haiku-4-5-20251001"]},
        "limit": {"max_spend_usd": 10.0},
    }
]

Do not put API keys or raw secrets in provider config. Use supported credential setup so backend preflight can verify availability safely.

When you call the Python SDK’s provider-key setup with api_key=..., the SDK fetches the backend’s published sealed-box key and encrypts the provider key before sending it. Direct API integrations should send encrypted_key_b64 and must not place raw keys in launch requests, provider config, logs, or prompts. TLS remains required for the transport in addition to payload sealing.

Provider keys are infrastructure, not a public plan surface for launch. Managed Research plan and Beta Access checks are enforced through billing entitlements and run-start preflight.

Availability

Backend preflight is authoritative for:

• missing credentials
• provider launch availability
• budget and entitlement blockers
• unsupported provider/model combinations
• required capability gaps

If a launch fails, read Preflight and Errors.