Read-Only AWS Discovery: Designing for Least Privilege and Operational Trust

Cloud topology tools need enough visibility to understand resources and relationships. That requirement creates a trust question: how can a platform inspect an AWS environment without gaining unnecessary power or collecting more data than it needs?

Read-only AWS discovery is a strong starting point, but the phrase is not a complete security design. A role can be labeled read-only and still expose sensitive metadata. A broad trust policy can permit the wrong principal to assume it. Logs can retain identifiers longer than necessary. A multi-tenant service can collect safely yet isolate poorly.

This guide explains the controls around cross-account discovery: role trust, external IDs, least privilege, session constraints, credential lifecycle, data minimization, audit evidence, tenant boundaries, and separation of remediation. It also explains what read-only access cannot guarantee.

Table of contents

• What read-only discovery means
• Start with a threat model
• Cross-account role design
• External ID and confused-deputy protection
• Least-privilege permission design
• Session and credential boundaries
• Data minimization
• Logging and auditability
• Tenant isolation
• Removing access and offboarding
• Separate remediation roles
• Hypothetical onboarding
• Review checklist
• Trade-offs and limitations
• Key takeaways
• Frequently asked questions

What read-only discovery means

In StackScopes’ context, read-only discovery means calling AWS control-plane APIs to list and describe approved resource types and configuration state. The purpose is to build inventory, topology, dependency evidence, change history, and security-path context. Discovery should not intentionally create, update, delete, restart, invoke, or reconfigure production resources.

That definition requires more precision than attaching the AWS managed ReadOnlyAccess policy and moving on. AWS services have different API semantics. Some “get” operations return sensitive content; some “list” operations expose identifiers or policy documents; some discovery use cases require data events that are not control-plane configuration. New services and actions evolve. Permissions need explicit review.

Read-only does not mean consequence-free. Metadata can reveal:

• Resource names and ARNs
• Account and Region structure
• Network ranges and routes
• IAM policies and trust relationships
• Tags containing ownership or business context
• Endpoint names
• Encryption-key identifiers
• Secret names and descriptions
• Database identifiers
• Software or image versions
• Customer or tenant labels if teams place them in tags

This information can be operationally and commercially sensitive. It deserves encryption, access control, retention limits, monitoring, and deletion procedures even when no application payload is collected.

Read-only also does not guarantee that every API is harmless in every context. Security review should classify actions by actual behavior and returned fields. Permission design should be versioned and tested as the supported service set changes.

Start with a threat model

Define what the system protects, from whom, and under which failure conditions.

Assets include:

• Customer AWS account configuration
• Resource and relationship graph
• IAM and security-path evidence
• Temporal change history
• Customer and tenant mappings
• Role ARNs and external IDs
• Temporary credentials in memory
• Audit logs
• User accounts and approval records

Threats include:

• An unauthorized party assumes the customer role.
• A compromised application workload requests discovery credentials.
• One tenant accesses another tenant’s graph.
• A support operator retrieves data outside an approved case.
• Sensitive fields enter logs or AI prompts.
• Credentials persist longer than required.
• A new permission expands access unnoticed.
• Offboarding removes the UI connection but leaves role trust active.
• Discovery is confused with authority to remediate.
• Partial collection produces misleading security conclusions.

Trust boundaries include the customer account, StackScopes control plane, worker execution environment, persistence layer, operator access, and any approved telemetry sources. Diagram data flow: who initiates a scan, which principal calls STS, where temporary credentials exist, which APIs are called, what is normalized, what is discarded, and which users can query the result.

Threat modeling should include availability and integrity. Attackers are not the only risk. A collector bug might issue excessive API calls, create throttling pressure, misassociate an account, or overwrite a topology snapshot. Controls should cap concurrency, handle retries with backoff, isolate failures, and preserve provenance.

Document assumptions. If role creation is performed through a customer-reviewed template, say so. If organizations use service control policies, assume they can deny discovery. If runtime telemetry is optional, distinguish it from baseline configuration collection.

Cross-account role design

The standard cross-account pattern is:

1. The customer creates an IAM role in its AWS account.
2. The role trust policy permits a specific StackScopes-controlled AWS principal to call sts:AssumeRole.
3. Conditions constrain the trust, including an external ID where appropriate.
4. The role has a scoped discovery policy.
5. StackScopes assumes it to obtain temporary credentials.
6. Those credentials call approved APIs in the intended account and Regions.

Use a dedicated role rather than customer access keys. Long-lived IAM user keys create rotation, storage, and attribution problems. STS credentials expire and can be scoped through policy and session controls.

The trust policy should name the intended principal precisely. Avoid trusting an entire external account without understanding which principals can call the role. A provider-side role dedicated to assumption creates a cleaner boundary than using a broad application identity.

Role naming should be recognizable, but security must not rely on names. Store and verify the full ARN and expected account ID. After assumption, call sts:GetCallerIdentity to confirm the resulting account and principal context before collection. Treat mismatch as a hard error.

Use session names that support attribution without embedding sensitive data. Session tags can add context where governance allows, but tag permissions and propagation need review. Keep session duration no longer than operationally necessary and consistent with scan behavior.

Role templates should be versioned. Show customers what changed between policy versions and why. Do not silently require broader permissions. Support a review process for optional modules such as CloudTrail-derived change evidence or runtime telemetry.

If AWS Organizations context is used, preserve account boundaries. Organization-wide onboarding can reduce repetition but should not erase per-account authorization, exclusions, and collection status.

External ID and confused-deputy protection

When a third-party service assumes roles in customer accounts, an external ID helps protect against the confused deputy problem. The customer’s trust policy can require a provider-issued value in the sts:ExternalId condition, and the provider supplies that value during AssumeRole.

The external ID should:

• Be unique per customer connection or trust relationship
• Be difficult to guess
• Be generated and managed by the service
• Avoid containing secret or personal information
• Be stored with the connection record
• Be displayed to the authorized customer administrator during setup
• Be rotated through a controlled process if necessary

An external ID is not a password. It can appear in the trust policy and should not be treated as the only defense. The policy must still restrict the principal. Application authorization must ensure one customer cannot ask the service to use another customer’s role ARN and external ID.

The service should bind tenant, role ARN, expected AWS account, external ID, allowed Regions, and policy version. A discovery job receives that bound connection, not arbitrary caller-supplied role details.

After assumption, verify account identity. Record the connection, job, session name, expected account, and result. Avoid logging temporary credentials or full request payloads containing sensitive data.

If role delegation involves several hops, analyze each trust boundary and session-policy effect. Simpler trust paths are easier to audit. Do not add role chaining merely for convenience.

External IDs address a specific cross-account risk. They do not solve tenant isolation, excessive permissions, vulnerable application authorization, or leaked temporary credentials.

Least-privilege permission design

Build permissions from required data fields and supported workflows.

For each resource type, document:

• API actions required
• Configuration fields used
• Relationship evidence produced
• Regions queried
• Expected call frequency
• Pagination behavior
• Throttling characteristics
• Whether returned content may be sensitive
• Optional versus baseline status

Prefer List, Describe, and carefully reviewed Get* actions, but do not assume naming proves safety. Explicitly deny write actions where useful as a defense-in-depth statement, while recognizing that IAM evaluation and service behavior must be understood.

Scope resources in policy where AWS supports meaningful resource-level permissions for the action. Many list and describe APIs require Resource: "*". In those cases, reduce access through the action set, Regions, account boundary, and collection configuration rather than pretending ARN scoping is available.

Conditions can help:

• Requested Region
• Principal or session tags
• Organization context
• Source identity where supported
• Service-specific condition keys

Conditions need testing. An incorrect condition can block required collection or create a false sense of restriction.

Separate optional capabilities. Base topology may require EC2, ELB, RDS, Route 53, ECS, Lambda, SQS, SNS, and selected IAM metadata. Change history may require CloudTrail lookup or access to an approved trail data source. Runtime evidence may require separately configured logs or telemetry. Customers should be able to understand and approve each boundary.

Avoid access to values when references suffice. For Secrets Manager, discovering a secret’s ARN, metadata, KMS key, rotation state, and resource policy can support topology. GetSecretValue is unnecessary and should not be granted. Similarly, avoid retrieving SSM secure-string values, database records, object bodies, queue messages, function environment plaintext beyond carefully assessed configuration, or log content outside approved use.

IAM and KMS analysis is nuanced. Reading policies can expose security structure but is important for dependency and path analysis. Limit who can view that evidence in the product and consider masking sensitive conditions.

Test the policy with automated permission checks and real collection fixtures. When adding a service, review both successful and denied responses. Denial should produce a visible partial-coverage status rather than a misleading complete graph.

Session and credential boundaries

Temporary credentials reduce persistence risk, but handling still matters.

The collection worker should request credentials just in time, hold them in memory where practical, and discard them after the job. Do not write them to application logs, analytics, crash reports, queues, or persistent job payloads. Redact common credential fields centrally.

Isolate execution by tenant and job. A worker processing one connection should not retain credentials or cached data for the next. Queue messages should contain an internal connection reference, not raw secrets.

Limit session duration to the scan’s needs. Large environments may require several sessions rather than one unnecessarily long session. Refresh should reauthorize against the bound tenant connection. Retries must not broaden scope.

Network egress can be constrained so collection workers reach required AWS APIs and approved platform endpoints. Endpoint policies and private connectivity may be useful in some deployments, but they are not substitutes for application authorization.

Protect the provider-side assumption role. Restrict which workloads can use it, monitor AssumeRole, and separate production from development identities. Developers should not casually assume customer roles from laptops.

Credential errors should be safe. If STS denies assumption, mark the connection degraded and show an actionable reason without exposing policy internals to unauthorized users. Never fall back to broader credentials.

Data minimization

Collect the least data needed to answer approved product questions.

For a resource graph, useful fields often include:

• Stable identifier and type
• Account and Region
• Lifecycle state
• Network placement
• Relationship-bearing configuration
• Encryption references
• Selected policy metadata
• Tags required for environment and ownership
• Observation timestamp
• Evidence provenance

Evaluate tags carefully. Teams sometimes place email addresses, customer names, ticket content, or secrets in tags despite guidance. Allow configurable tag inclusion and masking. Do not assume all metadata is non-personal.

Separate raw evidence from normalized graph data. Raw API responses may contain unused fields. Transform promptly, retain only justified evidence, encrypt stored data, and apply retention rules. If raw snapshots are retained for temporal comparison, document their purpose and lifecycle.

Sensitive-value detectors can reduce accidental storage, but they are not perfect. Design schemas that exclude values by default. Ensure debugging and support exports follow the same minimization rules.

AI-assisted investigation requires an additional boundary. Provide only the graph facts and telemetry excerpts needed for the question, mask sensitive content, and retain evidence links. AI outputs should not become a hidden copy of the complete customer environment. Production remediation remains separately controlled.

Data minimization also improves reliability. Smaller payloads cost less to transfer and index, reduce noisy diffs, and make deletion more feasible.

Logging and auditability

Audit logs should answer:

• Who connected or changed an AWS account connection?
• Which role was assumed?
• Which tenant and expected account were involved?
• When did collection start and end?
• Which service scopes and Regions were requested?
• Which policy version applied?
• Was identity verification successful?
• Which APIs or resource categories failed?
• Who viewed sensitive security evidence?
• Who exported data?
• Who changed retention or masking configuration?
• Who initiated or approved a remediation workflow?

Do not log credentials, secret values, authorization headers, or full sensitive responses. Logs need access control, integrity protection, retention, and monitoring.

CloudTrail in the customer account provides an independent record of role assumption and AWS API activity, subject to trail configuration and event coverage. Customers should be able to identify the discovery principal and session. Provider-side logs should correlate jobs without exposing internal secrets.

Audit events should be immutable to ordinary users and timestamped consistently. Time synchronization matters when correlating customer and provider events.

Alert on suspicious patterns such as assumption from an unexpected principal, repeated account mismatch, unusual Regions, abnormal API volume, access outside scheduled policy, or support access without a case.

Auditability is not the same as certification. A well-designed log supports review and investigation; it does not justify claiming compliance without a verified program and evidence.

Tenant isolation

Multi-tenant security must be enforced at every layer.

Use a stable tenant identifier in:

• Authentication and authorization
• Connection records
• Job scheduling
• Credential retrieval
• Storage partitioning
• Graph queries
• Cache keys
• Search indexes
• Exports
• Audit logs
• AI context assembly

Do not rely on the UI to filter tenant data. Server-side authorization must constrain every request. Internal service calls should carry verifiable tenant context, not a caller-controlled string.

Bind AWS account connections to tenants and define rules for legitimate account reuse or transfer. One account should not silently attach to two tenants. Transfer needs explicit verification and audit.

Test isolation with negative cases: cross-tenant identifiers, stale sessions, guessed object IDs, export jobs, background tasks, cache collisions, support tooling, and error messages. A “not found” response can avoid confirming another tenant’s object exists.

Encryption can add boundaries, but key architecture must match threat goals. Per-tenant logical separation with strong authorization may be appropriate; some requirements call for more isolated storage or keys. Do not advertise deployment or residency options that are not actually available.

Support access is a high-risk path. Require explicit role authorization, reason, time bounds, and audit. Prefer customer-visible or customer-approved access where product operations permit.

Deletion should traverse all tenant data stores, derived indexes, caches, and backups according to policy. Document backup expiration rather than promising immediate physical deletion where systems do not support it.

Removing access and offboarding

Customers must be able to revoke discovery access.

The most direct control is deleting the cross-account role or removing the provider principal from its trust policy. StackScopes should also support disconnecting the account so scheduled jobs stop and stored connection metadata enters the defined deletion or retention workflow.

Offboarding should:

1. Disable new collection jobs.
2. Revoke or delete active connection credentials and references.
3. Confirm no running job can refresh credentials.
4. Guide the customer to remove role trust.
5. Record the revocation.
6. Apply data export and deletion choices under policy.
7. Expire caches and derived artifacts.
8. Retain only required audit or legal records under documented rules.

Temporary STS credentials already issued remain valid until expiration unless other controls deny their use. Short session duration reduces this window. Do not claim instant revocation without accounting for active sessions.

Role-policy updates can break collection accidentally. Surface last successful collection, denial categories, and affected coverage. Never keep displaying stale topology without a freshness warning.

Reonboarding should create or verify a new explicit trust relationship rather than silently restoring an old connection.

Separate remediation roles

Discovery and remediation have fundamentally different risk.

The discovery role should not mutate production. If StackScopes supports controlled remediation, use a separate execution role with:

• Explicitly approved actions
• Narrow resource scope where possible
• Short-lived sessions
• Policy-bound tools
• Human approval
• Target and parameter validation
• Idempotency where supported
• Precondition checks
• Audit logging
• Post-action verification
• Emergency stop and revocation

Do not allow analysis findings to trigger unrestricted action automatically. An AI recommendation should show evidence and remain subject to policy and approval.

Separating roles lets customers use discovery without enabling remediation. It also reduces consequences if the discovery path is compromised. Different provider-side workloads should assume the two roles.

Some remediation actions need service-specific safeguards. Restarting a task differs from changing a key policy or deleting a resource. Start with reversible, bounded operations and expand only after threat modeling and testing.

The website and onboarding interface should state the separation clearly. “Read-only by design” must not obscure an optional, separately authorized execution path.

Hypothetical onboarding example

This scenario is hypothetical and uses illustrative account identifiers.

A platform team wants to connect three AWS accounts: development, staging, and production.

StackScopes generates a unique external ID for each connection and presents a versioned role template. The template trusts a dedicated StackScopes assumption principal and requires the corresponding external ID. The production role allows only the approved discovery actions and Regions selected by the customer.

An authorized customer administrator reviews and deploys the template. During connection verification, StackScopes assumes the role, calls GetCallerIdentity, and compares the returned account with the expected production account. It runs a small permission test and reports that Route 53 access is denied because zones are managed in a separate networking account.

The platform does not mark topology complete. It shows production compute and database coverage, identifies the DNS gap, and offers a separate connection procedure for the networking account. The customer chooses to add it later.

Collection workers obtain short-lived credentials per job. Secret values are not requested. Selected policy documents and relationship metadata are normalized into the tenant-bound graph. Raw unused fields are discarded according to the collection design. The audit log records role assumption, policy version, Regions, resource categories, denied calls, and completion.

Months later, the customer disconnects staging. New jobs stop, the customer removes role trust, and stored staging data follows the documented deletion and retention workflow. Production remains unaffected because connections and external IDs are distinct.

This workflow is not secure merely because the permission names begin with “Describe.” It is secure only to the extent that trust, authorization, data handling, isolation, monitoring, and revocation work together.

Review checklist

Trust and identity

• Is the trusted principal precise and controlled?
• Is a unique external ID required?
• Is tenant-to-role binding enforced?
• Is the assumed account verified?
• Are session names attributable?
• Is session duration limited?

Permissions

• Is every action tied to a documented field or workflow?
• Are secret and payload retrieval excluded?
• Are optional capabilities separate?
• Are resource and condition scopes used where supported?
• Are policy changes versioned and reviewed?
• Are denials surfaced as coverage gaps?

Credential handling

• Are temporary credentials fetched just in time?
• Are they excluded from logs and persistent messages?
• Are workers isolated between tenants?
• Is provider-side assumption access restricted?
• Is abnormal STS activity monitored?

Data protection

• Are only necessary fields collected?
• Are tags and policy content assessed for sensitivity?
• Are raw responses minimized?
• Are data encrypted in transit and at rest?
• Are retention and deletion defined?
• Is AI context minimized and masked?

Isolation and operations

• Is authorization server-side at every data path?
• Are cache and export boundaries tested?
• Is support access time-bound and audited?
• Can customers revoke access?
• Are active-session limitations explained?
• Is remediation separately authorized?

Trade-offs and limitations

Tighter permissions can reduce discovery coverage. Some AWS APIs do not support fine-grained resource scoping. Policy design must honestly balance data needs with least privilege and show gaps.

Cross-account collection depends on AWS control-plane availability, throttling, and customer policies. Retries should use backoff and bounded concurrency. A partial scan must not overwrite a complete baseline as if resources disappeared.

Configuration metadata can still be sensitive. Read-only does not eliminate breach impact. Strong application security, isolation, encryption, monitoring, and operational discipline remain necessary.

No permission policy stays least-privilege automatically. AWS adds services and actions; product capabilities change. Review and version it continuously.

Customers may require deployment, residency, or key controls beyond the available architecture. Those options should be assessed explicitly, not implied.

Finally, discovery proves visibility only for granted scope and observed time. It cannot guarantee complete knowledge of external APIs, application semantics, or inaccessible accounts.

Key takeaways

• Read-only is an access mode, not a complete security claim.
• Use customer-created cross-account roles and short-lived STS credentials instead of long-lived keys.
• Combine a precise trusted principal with a unique external ID.
• Derive permissions from required fields and separate optional modules.
• Do not retrieve secret values or workload payloads for topology.
• Bind every credential, job, record, and query to a tenant.
• Make partial coverage and freshness visible.
• Support revocation and documented deletion.
• Keep remediation in a separate, human-approved execution boundary.

Frequently asked questions

Why is an external ID needed?

It helps prevent a confused-deputy scenario by binding role assumption to a provider-issued customer connection. It complements, but does not replace, a precise trust policy and provider-side authorization.

Does StackScopes need AWS access keys?

The recommended cross-account pattern uses a customer-created IAM role and temporary STS credentials. It avoids issuing long-lived IAM user keys to the service.

Does read-only discovery collect secret values?

It should not. Secret references, metadata, key identifiers, rotation state, and policies can establish dependencies without retrieving secret values.

Can read-only APIs expose sensitive information?

Yes. Resource names, network structure, tags, IAM policies, endpoints, and configuration can be sensitive. They require data minimization, encryption, authorization, retention, and auditing.

How is remediation handled?

Any controlled remediation should use a separate, narrowly scoped role and workflow with human approval, target validation, audit logging, and post-action verification.

Conclusion

Operational trust comes from aligned boundaries: the customer controls role creation, the trusted principal is precise, external IDs bind connections, permissions reflect actual data needs, temporary credentials are contained, tenant authorization is enforced, and revocation works.

Read-only AWS discovery reduces risk by separating understanding from action. It does not remove the need for a threat model or careful data governance. StackScopes is designed around evidence-backed discovery and a separate controlled-remediation boundary. That architecture lets teams build useful cloud topology while keeping access explainable, reviewable, and proportionate to the task.

Official references

• AWS IAM cross-account roles
• AWS external IDs for third-party access
• AWS STS AssumeRole
• AWS IAM policy evaluation logic
• AWS CloudTrail user identity element

Related StackScopes reading

• Security
• Trust Center
• Security-First Read-Only Collection Model
• Security Paths
• AWS