Security and Credentials

Ambient credentials only

Terraback authenticates using each provider's normal ambient credential chain — it does not accept credentials as tool arguments. Configure credentials the same way you would for the Terraback CLI or any other tool built on the provider SDKs, in the environment the MCP server process runs in:

• AWS: environment variables, ~/.aws/config, a named profile passed via the optional profile argument, or an instance/role credential provider.
• Azure: az login, a service principal via environment variables, or workload identity. See Troubleshooting for the ARM_SUBSCRIPTION_ID note — MCP clients spawn servers with a limited environment by default, so Azure subscription context is not always inherited automatically.
• GCP: gcloud auth application-default login, a service account key via GOOGLE_APPLICATION_CREDENTIALS, or workload identity.

None of the six MCP tools mutate cloud infrastructure or import resources into Terraform state — they are read-only or code-generation-only. Because an MCP agent may be granted broad autonomy by its host application, use credentials scoped to read-only access rather than the credentials you'd use for terraform apply.

Read-only roles per provider

Provider	Role / policy	Notes
AWS	ReadOnlyAccess (AWS managed policy)	arn:aws:iam::aws:policy/ReadOnlyAccess
AWS	SecurityAudit (AWS managed policy), additionally	arn:aws:iam::aws:policy/SecurityAudit — needed for IAM and security-group visibility
Azure	Reader (built-in role)	Assign on the subscription, or the narrowest resource group scope that covers what you want scanned
GCP	roles/viewer	Grant on the project
GCP	roles/iam.securityReviewer, additionally	Only if you also want IAM policy visibility

Avoid credentials that also carry write access to the account being scanned. Attach only the roles above to the identity the MCP server process runs as.

verify_plan is a partial exception: it runs terraform init and terraform plan locally against a directory you already generated, so it needs no cloud credentials beyond what a normal terraform plan would — provider authentication is still required for the plan itself, since Terraform re-reads live resource state as part of planning.

Local-first, stdio transport

The Terraback MCP server speaks MCP over stdio: the MCP client launches terraback mcp as a local subprocess and communicates over its standard input and output streams. There is no network hop between the agent and the server process, and credentials configured for that process never leave the machine it runs on.

No telemetry. The MCP server does not send scan results, resource inventories, or usage data to Terraback or any third party.

Secret handling

• Tool arguments never include cloud credentials, connection strings, or secret values — only structural inputs like provider, scope, types, and file paths.
• Generated Terraform HCL reflects the configuration of live resources; if a scanned resource itself references a secret (e.g. a Secrets Manager ARN or Key Vault reference), Terraback emits the reference, not the underlying secret value.
• MCP's stdio transport requires stdout to carry only the JSON-RPC protocol stream. Terraback's scanning code normally prints a lot of human-readable progress; when running under terraback mcp, all of that is redirected to stderr instead, so it cannot leak into or corrupt the protocol stream. See Troubleshooting for how to capture that diagnostic output while debugging.

Related pages

• Tool Reference: confirms which tools are read-only and which touch cloud APIs at all.
• Agent Workflow: prerequisites section lists the exact roles to configure before running the import loop.
• Troubleshooting: fixes for credential and environment issues specific to MCP client process spawning.