Titus: Secrets Discovery

Your environments just got a powerful new line of defense. Titus, Praetorian's purpose-built secret scanner, is now running natively inside the Praetorian Guard platform — and we've open-sourced the entire thing at github.com/praetorian-inc/titus.

That means you get automated, continuous secret scanning across your assets with full transparency into exactly how it works. No black boxes.

What Titus Does For You

Titus hunts down hardcoded secrets across your environment with 459 detection rules covering credentials for AWS, GCP, Azure, GitHub, Slack, MongoDB, PostgreSQL, Jenkins, GitLab, and hundreds more services. Every scan surfaces secrets that would otherwise sit silently in your codebase, configuration files, and repositories — waiting to be exploited.

But finding secrets is only half the battle. The real question is: are they still live?

Validation That Proves What's Real

Titus doesn't just flag potential secrets — it can validate whether credentials are still active. This means your team spends zero time chasing expired tokens or revoked keys. When Titus marks a credential as Confirmed, you know it's a real, exploitable exposure that needs immediate remediation. When it's marked Denied, you can deprioritize with confidence.

This validation dramatically cuts through false positive noise and lets your security team focus on what actually matters.

Credential Owner Identification

When Titus detects and validates a credential, it now surfaces the identity of the owner or creator alongside the finding. Security teams can immediately identify the responsible party and initiate targeted revocation — rather than broadcasting a broad alert and waiting to determine whose key it was.

Owner information is returned with no additional network calls beyond the verification step Titus already performs.

Supported credential types

Where owner information appears

• JSON output — owner details are included in the "owner": {...} object on the relevant finding.
• Human-readable reports — owner fields appear inline with the finding, alongside other credential metadata.

No configuration changes are required. Owner identification is active automatically for supported credential types whenever validation is performed.

On-Demand Credential Analysis

The titus analyze subcommand lets security teams submit a single credential for immediate triage — without running a full scan. Given a credential, Titus auto-detects its type, validates it against the source API, runs full dynamic analysis including scoring, and enumerates the specific resources that credential can reach.

This transforms Titus from a scan-time tool into an interactive triage surface, making it practical to assess a credential the moment it is discovered through any channel.

Basic usage

titus analyze --token <credential>
titus analyze --file <path-to-credential-file>
echo "<credential>" | titus analyze

Add --format json for machine-readable output suitable for piping into other tools or ingesting into downstream systems.

Use --type to hint a specific service when auto-detection is ambiguous:

titus analyze --token <credential> --type github

Affected resource enumeration

For credentials that validate successfully, Titus enumerates the specific resources accessible to that credential and includes them in the analysis output. The scope of enumeration depends on the credential type:

Resource results appear in the human-readable report as a resource summary and are persisted on findings for downstream use.

Blast-radius scoring

Titus applies additional score weight to exposures that carry elevated risk. For AWS credentials, production-named S3 buckets and any Secrets Manager access are weighted more heavily, surfacing the most sensitive exposures first in prioritized output.

Safe By Design

We know what you're thinking: "You're testing my credentials?" Here's why validation is safe:

• Read-only checks. Validation only confirms whether a credential authenticates — it never executes commands, modifies data, or accesses resources beyond the authentication handshake.
• Off by default. Validation is an opt-in capability, giving your team full control over when and how it runs.
• No lateral movement. Titus makes a single, minimal API call per credential to check validity. It doesn't enumerate permissions, access data, or perform any action beyond confirming the credential is live.

This is the same approach used in professional penetration testing engagements — verify the risk without creating new ones.

Native to Guard — Zero Setup Required

Titus runs natively inside the Praetorian Guard platform, working automatically against every attack vector Guard has access to. The more integrations you connect — source code repositories, cloud environments, CI/CD pipelines — the more ground Titus covers. Exposed secrets surface as findings right alongside your other risks, fully integrated into your existing remediation workflows. No new tools to learn. No separate dashboards. Just actionable intelligence delivered where you already work.

Open Source — Inspect Every Rule, Contribute Your Own

Titus is fully open source under github.com/praetorian-inc/titus. You can inspect every one of its 459 detection rules, understand exactly what it's scanning for, and even contribute custom rules for your organization's specific secret patterns. It's powered by a high-performance regex engine with optional Hyperscan/Vectorscan acceleration for blazing-fast pattern matching, and it's been battle-tested across Praetorian's offensive security engagements before being deployed into Guard.

Transparency isn't a feature — it's how we build trust.

Read the full deep-dive on our blog →

Supported Enumerators

Titus provides enumerators for a range of enterprise data sources where credentials are commonly stored or shared. Each enumerator is invoked as a subcommand and accepts authentication credentials via flags or environment variables.

Source Code & Repositories

Covered through Guard's existing source code repository integrations.

ITSM & Support Systems

Collaboration & Messaging

File Storage

Usage

Each enumerator follows the same pattern:

titus enum <source> [flags]

For example:

titus enum servicenow --instance <instance> --username <user> --password <pass>
titus enum discord --token <bot-token> --guild-id <guild-id>
titus enum zendesk --subdomain <subdomain> --email <email> --token <api-token>
titus enum trello --api-key <key> --token <token>
titus enum gdrive --credentials <path-to-credentials.json>

Run titus enum <source> --help to see all available flags and environment variable equivalents for a given enumerator.

Performance: Hyperscan Rule Caching

Titus fingerprint scans now cache compiled Hyperscan rule databases on each worker. This eliminates redundant recompilation across jobs and reduces scan startup time, particularly in environments where the same rule set is used repeatedly.

How it works:

• First execution on a fresh worker — the rule set is fingerprinted, compiled, and saved atomically to the worker's local cache.
• Subsequent executions — jobs using the same rule set load the serialized database directly, skipping compilation entirely.
• Runtime-customized rule sets — rule sets that are filtered or modified at runtime (including Aurelian's default rules) receive their own cache fingerprint and are stored as independent cache entries, separate from the base set.
• Corrupt or incompatible entries — are detected automatically. The affected entry is recompiled and replaced with no manual intervention required.

This behavior is automatic and requires no configuration changes. Scans that previously recompiled rule databases on every job will benefit from faster execution without any action on your part.