Skip to main content

​
Overview

Cross account access builds up over time. Vendors, SaaS tools, partners, contractors, old integrations, and internal automation all leave behind roles that can be assumed from other AWS accounts. Most teams have no clear picture of who can access what, or which external accounts sit outside their AWS Organization. For engineers, this means potential security blind spots where unauthorized or forgotten access could pose significant risk to production systems.

​
Objective

I automate the mapping and analysis of cross-account access relationships by acting as your virtual security analyst. I review IAM trust relationships, identify internal vs external accounts, highlight vendor and third party access, and surface stale or risky paths that may need cleanup. I help engineers gain clear visibility into their access landscape and make informed decisions about which external relationships to maintain, modify, or remove.

​
Prompt

Third party access
Hey Pleri, I need to understand what third-party access exists in my AWS accounts.

Please help me distinguish between:

Cross-account access that is WITHIN my AWS Organization (internal)

Cross-account access that is OUTSIDE my AWS Organization (external third-party)

For the analysis, please:

Identify all IAM users and roles that allow cross-account access

Examine trust relationships to determine which AWS account IDs are external

Compare against our list of integrated AWS accounts to identify what's internal vs external

Categorize findings into:

External third-party SaaS tools (e.g., security vendors, monitoring services)

External vendor users (e.g., contractors, partners)

Internal cross-account roles (within our AWS Org)

Service account users

For each external access point, provide:

Role/user name

External AWS account ID

Which of our accounts have this access

Purpose/vendor name (if identifiable)

Last used date and current status

Risk assessment

Finally, provide actionable recommendations for:

Reviewing and documenting external access

Cleaning up stale or unused access

Implementing least privilege

Enabling monitoring and alerts

Governance improvements

Make the output clean, structured, and engineer-friendly.

​
Customization

Restrict the scope: I can look only at production, only at sensitive accounts, or only at roles that have not been used recently. Vendor identification help: Provide a known vendor list so I can label accounts clearly. Stale access thresholds: Tell me what counts as stale - unused for 60 or 90 days. Output options: I can send the report into Slack or open a Jira ticket with the findings. Strict or relaxed risk rules: I can treat unknown external accounts as high risk, or only flag them if they have powerful permissions.

​
Required inputs

I need the following pre-requisites to execute this playbook:
  • List of AWS accounts connected to Plerion
  • IAM roles, users and trust policy data
  • Last used timestamps for IAM roles and users
  • Environment tags (prod, non-prod, sandbox, etc.)
  • Known vendor account IDs (optional but helpful)

​
Workflow

Here’s what I do: