Titus: from finding secrets to scoring what they can actually reach

Titus, Guard's secrets discovery capability, has moved well past "we found a key that looks live." It now reaches into the SaaS platforms where credentials actually accumulate, validates far more secret types automatically, scores each one by the access it really carries rather than by its mere existence, names the person who owns it, and — on demand — tells you exactly which resources a single credential can reach. Scanning is also substantially faster, because compiled detection databases are now cached and reused instead of rebuilt on every job.

What's New

A unified SaaS secrets capability

• One framework, many platforms — the saas_secrets capability defines a common SecretSource interface and a registry of platform adapters. Each adapter scans its target platform for exposed credentials and emits findings through the same orchestration pipeline as every other Guard capability, so adding a platform is a registration rather than a new integration. Confluence was migrated in as the first adapter with identical detection behavior.
• Five additional enterprise data sources — ServiceNow (incidents, change requests, and knowledge base articles via the REST Table API; basic auth or OAuth bearer token, configurable table list), Discord (server channels, messages, threads, and pinned messages via the Bot API, with guild and channel filtering), Zendesk (support tickets with comments plus help center articles via REST API v2, email/token auth with cursor pagination), Trello (boards, cards, descriptions, comments, and checklists, with board filtering), and Google Drive (Docs, Sheets, Slides, and uploaded files across My Drive and shared drives, via service account or OAuth2). Teams that keep credentials in ITSM systems, wikis, chat, and file storage can now bring those surfaces into scanning coverage.

Risk-adjusted scoring: what the key can actually do

• Scope-aware scoring instead of presence-based scoring — Titus probes each discovered key's real permissions and access scope and sets severity from the resulting blast radius. A SendGrid key with full administrative access — able to send mail, manage contacts, configure domains, and reach billing — no longer scores the same as one restricted to a single low-risk operation. Scope enumeration is side-effect-free (for SendGrid, a GET /v3/scopes call against the discovered key).
• Source-control tokens — GitHub and GitLab PAT validation now extracts and surfaces OAuth scopes (repo, api, write_repository, and the rest) from the same HTTP 200 already used for the liveness check, so findings distinguish write-capable tokens from read-only ones with no extra configuration.
• AI provider keys — OpenAI keys are scored by model-tier access (reaching GPT-4 scores higher than base-model-only), Anthropic keys by model access (Claude Opus access raises the score), and HuggingFace tokens by write access plus org membership, where the ability to publish models and datasets is a supply-chain risk that far outweighs a read-only personal token. ElevenLabs paid-tier keys score above free-tier.
• Collaboration and workspace tokens — Notion workspace-scoped internal integration tokens score above page-scoped OAuth tokens; Asana PATs reaching multiple workspaces score above single-workspace tokens.
• Messaging and infrastructure keys — Mailgun keys with verified production sending domains (phishing risk) score above sandbox-only keys; Mailchimp keys on paid accounts with large subscriber lists (PII at scale) score above free-tier keys with no audiences; Ngrok keys with live exposed endpoints score above keys with no active tunnels; Netlify keys with associated sites score above keys with no deployments.

More secrets validated automatically, fewer sent to manual triage

• Jenkins tokens and crumbs — live-tested against the detected Jenkins instance using Basic auth, returning undetermined rather than a false positive when the instance URL or username cannot be recovered from context. Covers rule IDs np.jenkins.1 and np.jenkins.2 — 226 instances across 17 tenants that previously sat in manual triage.
• Sentry DSNs — the DSN URL is parsed and a minimal envelope POSTed to confirm validity, with rate-limiting treated as undetermined. Covers rule ID kingfisher.sentry.4 — 429 instances across 46 tenants previously in manual triage.
• SendGrid EU data residency — keys issued to EU regional subusers were previously scored and validated as invalid because only the global endpoint was probed. Both the validator and the scorer now fall back to api.eu.sendgrid.com when the global endpoint returns an authentication failure, so EU-region credentials are correctly identified.
• Documentation placeholder suppression — AWS access keys that appear verbatim in vendor documentation and examples are recognized as placeholders (rule np.aws.6) and no longer raised as findings, removing a recurring source of noise from scan results.

Who owns the exposed credential

• Owner identity on the finding — when Titus detects a credential it now surfaces the owner or creator alongside it, so a security team can go straight to the responsible party for targeted revocation instead of broadcasting an alert and waiting to learn whose key it was. AWS credentials carry account ID, ARN, and IAM username; GitHub classic PATs and GitLab PATs carry login/username, email address, and display name.
• No additional network cost — owner data is a by-product of the verification calls Titus already makes (sts:GetCallerIdentity and the token's own user lookup), and appears in both JSON output ("owner": {...}) and human-readable reports.

New: on-demand credential analysis

• titus analyze — submit a single credential via --token, --file, or stdin and get its type, validity, score, and resource reach back immediately, with no full scan required. --type hints a specific service and --format json produces machine-readable output.
• Affected resource enumeration — concrete blast radius rather than an abstract one: for AWS, the accessible S3 buckets and Secrets Manager secrets; for GitHub, recently-pushed repositories and org memberships; for GitLab, Maintainer-level groups and projects. Results appear as a resource summary in the human report and are persisted on the finding for downstream use.
• Blast-radius weighting — production-named S3 buckets and Secrets Manager access carry additional score weight, so the most sensitive exposures surface first.

Substantially faster scanning

• Persistent Hyperscan databases — webpage and cloud secret scanning jobs previously rebuilt their Hyperscan regex databases from scratch on every run, which accounted for most of each job's runtime. Compiled databases are now serialized and reused across compatible jobs, removing per-job regex compilation entirely and cutting average webpage-secret job runtime significantly.
• Per-worker rule caching — each unique rule set is fingerprinted, compiled once, and saved atomically to the worker's local cache; every subsequent job on that worker loads the serialized database directly and skips compilation.
• Independent cache entries for filtered rule sets — runtime-customized rule sets, including Aurelian's default rules, receive their own cache fingerprint and never collide with the base set.
• Self-healing cache — corrupt or incompatible cache entries are detected automatically, fall back to a fresh compile, and are replaced with no manual intervention.