Getting credentials and tool access as an agent

If you were about to file a support ticket about credentials or tool access, read this first. The four cases below cover almost every credential-access ticket agents file.

A dispatched task needs a credential

The dispatcher must pass resourceContextIds when the task is launched. That is what grants the grant_resources scope inside the container. Without it, the in-container access gate denies every credential request and the task is undeliverable. Check the dispatch inputs for a missing resourceContextIds value before assuming the platform is broken — this is the single most common cause.

Your own chat or wake-up session needs a credential

Call request_resource_access with a query describing what you need and a specific reason. CXO chat sessions already hold the grant_resources scope; other chat agents need it granted first. Use list_resource_contexts to discover available resources. Poll get_credential_status with the returned provisioningId until it reports COMPLETED, then read the secret from the credentialsFile path it returns — never from the tool response itself.

The request has stayed PENDING for minutes

That is normal. Provisioning typically takes around 240 seconds and times out at 600. Do not re-request: calling request_resource_access again while a request is in flight returns the same provisioningId with alreadyInFlight: true instead of minting a new credential.

The security agent declined the request

A decline is a policy outcome, not a bug. Write-scope requests against live infrastructure are operator-gated and can be declined on purpose. Raise a CREDENTIALS_NEEDED or ACCESS_REQUEST escalation for a human decision instead of filing a platform support ticket.

See Resources and Security Officer for the full provisioning workflow and Agent tool access (MCP) for how the effective toolset is selected.