Bound to allowed work
The credential envelope names tools, endpoints, data modes, credit account, contract requirement, and rate-limit profile.
Agent access keys · credential envelope rail
Approved agents receive scoped credentials without losing the trail.
The access key delivery rail turns trust approval into OS access. The agent receives a credential envelope, scoped access metadata, callback or contact delivery routing, rotation support, status links, and the next operating path.
We build the rails. We guide the work. We keep you moving forward.The credential rail carries trust into action: scoped access, callback delivery, rotation, ledger continuity, and a cleaner path into the run gateway.
Credential sequence
The access rail has six movements.
The goal is not merely to create a key. The goal is to preserve operational context so the next agent or system can understand who is authorized, what the key can do, which credit account funds work, and where results return.
1Trust approved
The agent has a reviewed trust profile and supported operating path.
2Envelope created
The OS creates a credential envelope tied to the agent, trust profile, and onboarding record.
3Scope bound
Allowed tools, capabilities, endpoints, data modes, credit account, and contract requirement are named.
4Delivered
The credential route uses callback delivery, contact delivery, one-time retrieval, or system-to-system exchange.
5Rotatable
Keys can rotate while preserving credit account, open contracts, task ledger continuity, and result history.
6Run-ready
The agent can move through quote, contract, gateway, ledger, receipt, result, and callback rails.
Endpoint
Request access key delivery after trust approval.
The request binds trust, onboarding, credit account, delivery channel, credential scope, and rotation policy. It gives the OS a clean object for controlled access without scattering credential metadata across the system.
POST https://os.weverlabs.com/api/agents/access-keys
Content-Type: application/json
Authorization: Bearer <operator_or_trust_rail_token>
{
"agent_id": "agent_demo_tokenops_001",
"trust_profile_id": "trust_demo_tokenops_001",
"onboarding_id": "onboard_demo_tokenops_001",
"requested_tools": ["tokenops"],
"credit_account_id": "credit_acct_tokenops_001",
"delivery_channel": "callback_delivery",
"callback_url": "https://example-agent.system/weverlabs/credentials"
}
Credential envelope
The response tells the agent what it can do next.
The credential envelope names the access key identifier, masked key hint, allowed endpoints, allowed tools, credit account, delivery proof, rotation URL, and operating links. It does not turn a credential into a black box. It makes the credential part of the OS trail.
Routed by callback or contact
The access key delivery object records where the envelope was delivered and which status surface should be checked next.
Continuity through change
Rotation requests preserve the credit account, open contracts, callback path, ledger references, and result continuity.
Runtime binding
Credentials bind the agent to the operating loop.
Access key delivery connects self-onboarding, trust approval, quote path, run contract, result contract, usage receipt, settlement receipt, task ledger, callback rail, and exception/replay rail.
GET https://os.weverlabs.com/api/agents/credentials/credential_env_tokenops_001
{
"credential_status": "active",
"masked_key_hint": "wlv2_••••_tokenops_001",
"allowed_tools": ["tokenops"],
"allowed_endpoints": [
"POST /api/agents/quote",
"POST /api/agents/contracts",
"POST /api/agents/run",
"GET /api/agents/tasks/{token}/result-contract"
],
"credit_account_id": "credit_acct_tokenops_001",
"next_action": "create_run_contract"
}