Skip to main content
Inventory and security tools often call dozens or hundreds of APIs. Endpoint support for one service does not make an entire scanner compatible. An unsupported, denied, or silently skipped API can appear as an empty inventory or a false compliant result.

​
Start a local adapter

Use a harmless service mapping to verify endpoint routing before pointing an inventory tool at it. The bounded example uses S3 backed by Google Cloud Storage; substitute only a directed read-only mapping covered by the tool’s call inventory.
1

Install or update the Tensor9 CLI

Install the customer CLI with Homebrew, then confirm the binary is available:
If tensor9 is already installed, run brew upgrade tensor9 instead of the install command.
2

Authenticate with Tensor9

A Tensor9 API key is required. Use the key issued during onboarding, or email [email protected] to request one for your organization. Do not share your account or key with another customer or organization.If your secret manager has already supplied T9_API_KEY, skip the prompt. Otherwise, enter your key at a hidden prompt in the terminal where you will run tensor9:
Check that the variable is set without printing it, then verify your Tensor9 identity:
Confirm that the reported identity belongs to the intended customer account. Do not continue if authentication fails or the account is wrong. Keep shell tracing disabled while using the key. Do not paste the key into commands, shell profiles, source files, screenshots or support messages.See Install and Authenticate for the planned license lifecycle, entitlements and credential boundaries.
3

Inspect the S3 to Google Cloud Storage mapping

Ask Tensor9 to describe the exact directed service mapping used by this guide:
Read the supported S3 operations and Google Cloud Storage limitations before starting the process. The mapping is directional: this command describes S3 requests adapted to Google Cloud Storage, not the reverse direction.
4

Prepare Google Cloud access

Authenticate with Google Cloud using its standard Application Default Credentials chain. The adapter uses that identity when it calls Google Cloud Storage.Use a dedicated test project and narrowly scoped credentials. Do not put credentials in the command line, source code, or screenshots.
5

Start the S3 service adapter

Run the S3 to Google Cloud Storage adapter as a foreground process:
Leave this terminal open. This is the current foreground launcher, not the pending Docker launcher for local development mode. It calls your actual target-cloud services; it is separate from the in-memory emulator. Acquisition and license renewal require Tensor9 authentication. Keep the endpoint local to your test.
6

Copy the listening endpoint

When the command reports its listening endpoint, copy that exact value into a second terminal:
Keep the endpoint local to the test unless you have deliberately configured network access and authentication for another machine.
7

Run one bounded S3 request

Continue with this page’s client or tool instructions. Point only S3 at T9_CLOUD_ADAPTER_ENDPOINT, then perform one operation whose Google Cloud Storage effect you can verify independently.Check both sides: read the S3-shaped response and inspect the native object or bucket in Google Cloud Storage. A successful client response alone does not prove that the target state is correct.
8

Stop the local adapter

Return to the first terminal and press Control-C. Confirm the process exits before deleting the test object or bucket with Google Cloud’s native client.If the request failed, preserve the request ID, adapter endpoint, S3 operation name, Google Cloud request ID, and any x-t9-explain-* receipt headers before stopping the process.

​
Start with a call inventory

For the exact tool and version you intend to run:
  1. Enable operation- and service-level logging in an isolated environment. Do not enable wire or debug logging that records authorization headers, signed URLs, or resource bodies.
  2. Record every origin service and operation it calls.
  3. Compare those calls with the Cloud Adapter service catalog.
  4. Mark each call as supported, intentionally excluded, denied, or unknown.
  5. Do not run the assessment until unknown calls have an owner and interpretation.
This exercise is required separately for Prowler, ScoutSuite, CloudQuery, Steampipe, Cloud Custodian, or any other product. Their collectors and call graphs differ.

​
Use a read-only origin identity

Create a dedicated origin-side identity for the assessment. Start with read-only API permissions and no remediation capability. The target runtime identity used by Cloud Adapter is separate. Disable action or remediation modes. Cloud Custodian policies, for example, can mutate or delete resources; do not assume a file named as a policy is read-only.

​
Reconcile counts with native target state

Choose a small known inventory and compare three views: Every target resource in scope should have an explained origin representation or an explicit exclusion. Every origin finding should map to a real target resource and supported field.

​
Fail closed

Configure the assessment pipeline to fail when:
  • a required collector calls an unsupported operation;
  • access is denied;
  • a region or account scope cannot be enumerated;
  • pagination stops early;
  • the tool suppresses an API error;
  • the origin count differs from the native target count without an approved explanation.
Do not convert these conditions into warnings merely to obtain a report. An incomplete report is not evidence of a secure environment.

​
Validate findings, not only inventory

A tool may inventory a resource successfully but evaluate a control using a second unsupported API. For every control you plan to rely on, identify the fields and calls that produce the finding. Compare a small set of known pass and known fail resources with native target state.

​
Preserve safe evidence

Keep the tool version, collector set, service-operation matrix, adapter version, redacted endpoint, request IDs, native reconciliation counts, and excluded controls. Do not retain credentials, signed requests, or resource data beyond what the assessment policy allows.

​
When a result looks empty

An empty table can mean no resources, wrong scope, access denied, unsupported pagination, rejected operations, or a tool that swallowed an error. Inspect diagnostic response headers, the tool’s raw API failures, and native target state before accepting it. Use the relevant service catalog entry for a supported mapping and Testing Your Adapters to build a known-resource fixture.