Credential or secret errors
Secret errors usually show up as failed tool calls, refused LLM requests, or authentication failures in the worklog. Because Alquimia Platform resolves secrets at runtime, the agent spec can be correct while the secret store is not.
Common causes
Section titled “Common causes”| Symptom | Likely cause |
|---|---|
secret not found | The referenced secret name does not exist in the agentspace or global scope. |
access denied | The runtime role lacks permission to read the secret path. |
| Token rejected by provider | The secret value is expired, revoked, or copied incorrectly. |
| Intermittent failures | Vault lease expired or dynamic credential renewal failed. |
| Secret fetch spike | A tool or loop is resolving secrets repeatedly. |
Diagnostic steps
Section titled “Diagnostic steps”-
Identify the failing secret name from the worklog or error message.
-
Check that the secret exists in the expected scope: global, agentspace, or local.
-
Verify Vault policies allow the runtime role to read the relevant path.
-
Test the secret value directly against the provider or database to confirm it is valid.
-
Review secret audit metrics for spikes or failures associated with the agent.
-
Confirm the runtime is using the intended auth method for Vault or the cluster secret store.
- Register the missing secret or correct the reference name in the spec.
- Update Vault policies to include the required paths.
- Rotate the secret if the value is expired or invalid.
- For dynamic credentials, check Vault role TTLs and renewal settings.
- Refactor tools that resolve secrets inside loops to avoid unnecessary fetches.