Skavio Agent Tools: issue a company API key and protect its one-time secret
Skavio Agent Tools documents company-scoped API keys, revocation and a secret displayed only once. A safe setup starts before issuance: prepare controlled storage, confirm the company context and keep authentication inside trusted server-side code. Company scoping is documented; selectable permission scopes remain unverified.
1. Prepare the secret’s destination before creating the key
Decide which service will use the credential and where that service will retrieve it. Following OWASP guidance, prefer an access-controlled secrets manager with runtime retrieval, or controlled secret-file injection where practical. Prepare that destination before starting key issuance so the once-displayed secret does not need a temporary home in an unsecured note or message. Keep the operational record separate from the secret itself. Record the intended company, integration, environment and responsible maintainer without copying the credential into a ticket or deployment note.
- Keep credentials out of source code, committed configuration and container images.
- Separate development and production credentials as an integration practice; verify the available key-management options first.
- Do not treat environment variables as inherently secure: they can appear in logs or diagnostic dumps.
2. Confirm the company—and do not assume permission selectors
The public Agent Tools dashboard provides account creation, sign-in and an “API keys” workspace tab. Sign in and confirm that you are working in the intended company context before issuing a key. Skavio’s documentation says keys are scoped to the company. That is not the same as selectable read-only, write or operation-level permissions. The published OpenAPI lists key-listing and key-creation routes, but does not define the creation payload or enumerate permission scopes. The source review did not verify the authenticated form’s fields, defaults or issuance roles, so this guide does not provide click-by-click creation instructions. Use only permissions whose meaning the current interface or documentation establishes. If your integration requires a narrower permission boundary, verify that it is supported before deployment rather than assuming the word “scoped” provides it.
3. Move the once-displayed secret directly into controlled storage
When the secret is displayed, transfer it directly into the prepared storage location. Avoid screenshots, screen recordings and intermediate notes. Never send it through email, chat or an AI prompt. “One-time display” describes the opportunity to capture the secret—not a credential that can authenticate only once. If you miss that display or cannot confirm a successful transfer, revoke the key and issue a replacement rather than assuming the original secret can be recovered. Skavio’s product overview states that issued secrets are stored only as hashes. This is a published product statement, not an independent security audit, and it does not protect copies that your own integration stores or logs.
4. Let trusted code authenticate, not the agent’s conversation
The [Agent Tools API documentation](https://getskavio.com/agent-tools/docs.html) specifies authentication through the Authorization header using the Bearer scheme: `Authorization: Bearer <YOUR_COMPANY_API_KEY>` The bracketed value is a placeholder, not a credential. Have trusted server-side application code retrieve the secret and attach authentication when making an authorized request. Design the integration so an agent can request an allowed operation without receiving the key in its prompt, conversation history or model-visible tool arguments. Do not embed the credential in browser-delivered code. Send credentials over HTTPS, never in a URL or query string. Verify the intended API host before implementing a runnable request: the source review found legacy-domain references in the documentation and OpenAPI, so this article deliberately provides only the header example, not a full request URL.
- Redact Authorization headers in application logs, HTTP traces and exception reports.
- Check deployment output and troubleshooting bundles before sharing them.
- Keep the stored secret accessible only to the people and services that need it.
5. Revoke suspected exposures rather than just deleting the copy
Skavio documents that company keys can be revoked. If a credential appears in a repository, message, prompt or diagnostic output, revoke it immediately, issue a replacement through the current key-management workflow and update the trusted integration’s stored credential. Deleting the visible copy is not a substitute for revocation. Review whatever usage evidence is available for the exposure period, without assuming that a particular audit dashboard or log facility exists. Then correct the path that leaked the secret—such as verbose HTTP logging—before resuming normal operation. For planned replacement, verify the current key-management behavior first. Overlapping-key support, automatic expiry and zero-downtime rotation were not established by the source review.