Credential Security
Astonish provides a secure credential store that keeps API keys, tokens, and other secrets encrypted at rest and invisible to the LLM at runtime. A multi-layer redaction pipeline ensures that secrets never leak into model context, logs, or responses.
Credential Store
Credentials are stored encrypted using envelope encryption and scoped to either a user (personal) or a team:
| Scope | Visibility | Use Case |
|---|---|---|
| Personal | Only the owning user | Dev/testing API keys |
| Team | All team members | Shared production credentials |
Credential Types
| Type | Description |
|---|---|
api_key | Custom header + value for API authentication |
bearer | Authorization: Bearer token |
basic | HTTP Basic Auth (username + password) |
password | Username + password for SSH, FTP, SMTP, databases |
oauth_client_credentials | OAuth2 client credentials with automatic token refresh |
oauth_authorization_code | User-authorized OAuth2 with refresh token |
Output Redaction
Astonish applies multiple independent redaction layers to guarantee secrets never reach the LLM context:
| Layer | Stage | Mechanism |
|---|---|---|
| 1 | Injection | Secrets are injected into tool call environments via placeholders, never into the prompt |
| 2 | Tool output filtering | Tool stdout/stderr is scanned; matching values are replaced with [REDACTED] |
| 3 | Context assembly | The context builder verifies no known secret values appear in assembled messages |
| 4 | Channel output | Outbound messages to channels (Telegram, Slack, etc.) are scanned against active credentials |
| 5 | Audit and logs | All logging pipelines strip secret values before writing |
Each layer operates independently. If one layer fails, the remaining layers still prevent exposure.
How Secrets Reach Tools
When an agent invokes a tool that requires credentials:
- The credential is resolved (personal-first, team fallback).
- The encrypted ciphertext is decrypted in memory using the org's DEK.
- The plaintext is injected as an environment variable into the sandbox container.
- The tool reads the credential from its environment.
- After execution, the environment is destroyed with the container.
At no point does the LLM see the credential value. The model only knows that a credential named (e.g.) GITHUB_TOKEN is available — never its contents.
Managing Credentials
In Studio
Studio provides a credential manager under Settings → Credentials where you can add, view metadata, test, and remove credentials through a visual interface.
Via CLI
# Add a credential
astonish credential add
# List credentials (values are never displayed)
astonish credential list
# Show credential metadata
astonish credential show <name>
# Test a credential (validates it works)
astonish credential test <name>
# Remove a credential
astonish credential remove <name>
# Set or manage the master key
astonish credential master-keyCredential values are never echoed back in any command output. The list and show commands display names, types, scopes, and metadata only.
See Also
- Envelope Encryption — how credentials are encrypted at rest
- Sandboxes — the isolated execution environment where credentials are consumed
- Audit Logging — all credential access is recorded