Authentication and secrets in monitoring
This page explains how Intello handles credentials for chat alerts, email, PagerDuty, and spec fetch—and what you should never put in URLs.
Signing in
Browser users sign in to Intello normally; you don’t manage API tokens by hand for day-to-day use.
Automation against /api/* uses a Bearer token from your auth provider—see Authentication. Intello’s own workers use separate internal keys you never need as a customer.
Encrypted at rest
The following categories are stored encrypted at rest in Intello’s database (AES-GCM envelope):
- OAuth tokens / refresh tokens for chat providers (where applicable)
- Chat webhook URLs (Slack/Teams) when stored as secrets
- PagerDuty routing keys and similar alert destinations
Application APIs still accept and return plaintext JSON for these fields—encryption is transparent at the persistence layer.
Operational guidance: rotate webhooks and routing keys if you suspect exposure; revoke OAuth apps from the vendor console if tokens leak.
Spec URLs and query-string secrets
Avoid:
https://vendor.example.com/openapi.yaml?token=SECRET
Problems:
- Tokens appear in dependency configuration visible to org members.
- Logs and support tooling may need to redact URLs aggressively.
- Rotating the token requires editing the dependency; easy to miss.
Prefer:
- Stable public spec endpoints, or
- A first-party proxy that injects auth server-side, exposing a clean HTTPS URL to Intello.
auth_config on dependencies
When Intello must authenticate to fetch a spec, use structured auth_config rather than baking secrets into spec_url—exact keys depend on your deployment’s supported fetch auth. If unsupported, host the spec on a signed URL with long-lived stability or proxy it.
Email safety
Headers derived from user input (display names, subjects) pass through header injection defenses. Do not attempt CRLF injection via invitation or alert display names—controls strip dangerous sequences.