How GhostHunter protects your AWS account

GhostHunter uses the formal AWS cross-account IAM AssumeRole pattern — the standard, modern approach approved by enterprise infrastructure reviewers for third-party orchestration.

You create an initial IAM role in your AWS account using our provided CloudFormation template. That template creates a role with an explicit trust policy that allows *only* GhostHunter's verified broker account to assume it, bounded tightly via a unique ExternalID generated for your team.

The ExternalID protects your environment from the confused deputy security challenge — ensuring that even if our broker account ID were public knowledge, an external attacker could never authenticate against your infrastructure without matching your exact organization key.

You remain the absolute owner of the integration. Access can be immediately severed at any moment by simply deleting the IAM role from your local AWS Console.

GhostHunter indexes optimization metadata about your isolated assets — raw resource IDs, region strings, and running run-rate costs — but never indexes internal storage contents.

Sensitive architecture metrics are cryptographically processed at rest using AES-256-GCM prior to hitting our data layer. Decryption tokens are isolated outside the global database network context, ensuring raw metadata strings are never visible in plaintext.

Invite records sent over corporate mail tracks are stored using SHA-256 secure hashing. The underlying connection payload resides uniquely in your temporary registration thread and is never hard-saved to database clusters.

When you transition from identifying waste to actively cleaning your perimeter, GhostHunter upgrades security safeguards to protect production environments from erratic changes.

• Intentional Stack Upgrades: Introducing write capabilities requires an explicit, separate CloudFormation stack update. You control the exact remediation boundaries.
• Simulated Dry-Runs First: Every elimination workflow runs a live mock execution loop first, allowing you to visually review the specific targets prior to confirmation.
• Narrow Mutator Scoping: Upgrade templates do not ask for structural administrative access. If you only approve purging detached EBS volumes, the policy blocks instance interaction entirely.
• Immutable Audit Feeds: Every purge query, user confirmation, or failure block is written to an immutable internal audit tracker mapped directly to individual engineer IDs.